@
SLVPRO
Obecnie brak odbić w większości gier (spoza zwykłym SSR - Screen Space Reflection) to kwestia nie lenistwa deweloperów, czy zmowy z nVidia, a głównie sprawa... wydajności.
Otóż wcześniej odbicia w wodzie były realizowane na podstawie Cubemap Reflections, a owe lustra były tworzono zwyczajnie kreując kolejną (identyczną) scenę za obszarem "odbicia".
Oba powyższe rozwiązania miały swoje wady (i często dodatkowy czas oraz wysiłek potrzebny do ich zaimplementowania).
Cubemap Reflections - to nic innego jak zwykła bitmapa będąca "zdjęciem" obszaru, który się odbija. Sam możesz sobie wyobrazić jakie niesie to ze sobą ograniczenia.
Po pierwsze owe "zdjęcie" nie może być "dynamiczne" (nawet jeśli sama tekstura "odbicia" będzie animowana - nie wiem czy takie przypadki się zdarzały?), tak więc gdy coś się zmieni na scenie (dajmy na to oświetlenie, czy też jakiś efekt/obiekt, które nie były wcześniej "odbite" w "zdjęciu") wówczas nie będzie tego widać.
Druga wada powyższego rozwiązania to konieczność (i co za tym idzie trudność) dopasowania owego odbicia do skraju obiektów odbijanych (przypominam, że "odbicie" to płaska i niedynamiczna tekstura) co w praktyce jest niemożliwe w 100% do wykonania poprawnie.
Cubemap Reflections było głównie stosowane do wody (na ogół większych powierzchni) lub mniejszych przedmiotów, które miały coś "odbijać".
Dawne lustra i odbicia poprzez renderowanie kolejnego (identycznego) planu za lustrem miały również kilka podstawowych wad.
Po pierwsze gra w tych obszarach musiała wyrenderować praktycznie dwa razy bardziej złożoną scenę, więc wymagania znacznie wzrastały w tych poszczególnych scenach. Trudno wówczas podciągać wymagania i optymalizację gry dla tych kilku obszarów.
Druga sprawa to (podobnie jak powyżej) kwestia dynamicznych obiektów, które teraz były możliwe ale wiązały się z kolejnymi ograniczeniami odnośnie mocy obliczeniowej (trzeba było zaimplementować efekty bądź dynamiczne efekty dla dwóch scen równolegle), stąd też owe sceny zwykle były również dość statyczne (poza postacią gracza). Dopasowanie odbić można było jednak lepiej dostosować.
Jednak cała powyższa operacja z implementacją tej techniki odbić wiązało się ze sporym nakładem dodatkowej pracy.
Tak spopularyzowany obecnie SSR robił wszystko niejako automatycznie (przez odpowiednie biblioteki) - czyli praktycznie odbijał wszystko - ale miał podstawowe wady.
Głowna wada polegała na tym, że odbijał tylko to co w danej chwili "widziała" kamera. Stąd wszystko poza tym obszarem znikało (np. góry odbite w wodzie, gdy owe szczyty znajdowały się ponad kamerą) i tyczyło się to też obiektów, które przysłaniały daną scenę (czyli dajmy na to postać gracza - czy każdy inny obiekt, który jest pomiędzy naszą kamerą, a odbiciem - na tle jeziora).
RT symuluje zachowanie rzeczywiste światła (nie tylko odbicia, ale też cienie) w tym jego dyfuzję.
A robi to niejako bez dodatkowej pracy i ingerencji twórców (częściej część z tych efektów była "udawana" co dawało często dyskusyjne efekty oraz wymagało sporego nakładu pracy) po zaimplementowaniu odpowiednich bibliotek do silnika gry. RT rozwiązuje nie tylko sprawę poprawnych odbić (mogą być one w 100% dynamiczne, łącznie z odbiciem cząsteczek i zmiennych efektów świetlnych) ale też poprawnych fizycznie cieni i rozpraszania się świateł (co wcześniej było robione ręcznie oraz dość pracochłonne i przede wszystkim statyczne).
RT to nie bajer mający na celu tylko wyciągnięcie kasy od graczy, a rozwiązanie przybliżające nas do wizualnego realizmu. Główny problem polega na tym, że jest to niezwykle kosztowna (pod względem zapotrzebowania na moc obliczeniową) technika, więc obecnie stosuje się masę sztuczek, aby ten koszt zmniejszyć (daje się mniej promieni "śledzących" scenę czy odbicia, zmniejsza się rozdzielczość i zasięg tych odbić, itp.).