Dlaczego nowoczesne gry wykorzystują podejście renderowania do tekstury w przypadku kopii lustrzanych?

Patrząc na stare gry, takie jak Mario64 lub DukeNukem3D, wszystkie lustra w grze są w zasadzie dziurami w ścianie z umieszczoną za nimi lustrzaną kopią geometrii przed lustrem. W przypadku DukeNukem3D można nawet aktywować brak klipu i wejść do tego lustrzanego pokoju.

W przeciwieństwie do współczesnych gier, w przypadku mirrorów stosuje się podejście renderowania do tekstury. Prowadzi to do zauważalnego pikselowania zwierciadeł podczas zbliżania się do nich. Jedną z pierwszych gier, w których zauważyłem takie podejście, była Rezydencja Luigiego, ale wydaje się, że jest stosowana w prawie wszystkich współczesnych grach.

Jaka zmiana w sprzęcie lub silnikach sprawiła, że ​​drugie podejście stało się obecnie tak dominujące i jakie są z tego korzyści? Pod względem czystej grafiki pierwsze podejście wydaje się lepsze, ponieważ nie ma problemów z pikselacją.

1. Zastosowanie RTT (renderowanie do tekstury) pozwala łatwo skalować jakość renderowania (rozdzielczość, LOD, złożoność oświetlenia) w celu dostosowania wydajności. RTT ułatwia także zastąpienie powierzchni mapą sześcienną w pewnej odległości, w której trudno dokładnie zobaczyć odbicie.
2. Ponieważ wyjście jest teksturą, istnieje więcej opcji dotyczących tego, co można z nim zrobić później (oświetlenie, cieniowanie, mieszanie, zniekształcenie itp.).
3. Jeśli lustrzana wersja geometrii zostanie umieszczona na scenie, wymagałoby to bardziej skomplikowanego wyrównywania, gdy przecina się z rzeczywistą geometrią i można ją zobaczyć za rogiem. W starszych grach poziomy zostały zaprojektowane, aby tego uniknąć. Nie wspominając już o tym, że ktoś musi wykonać rzeczywiste kopiowanie.
4. Jeśli geometria nie jest ręcznie odbijana, renderowanie należy wykonać, zmieniając matrycę widoku i tryb wyrównywania (w celu skompensowania odwrócenia przestrzeni w macierzy) i używając bufora szablonu do wycięcia lustra. Nowoczesne silniki wolą wcześniej tworzyć wszystkie stany renderowania, więc pojawiłby się drobny problem z tworzeniem kopii każdego stanu renderowania sceny z wymaganymi zmianami renderowania lustrzanego.

Zasadniczo korzystanie z RTT daje każdemu większą swobodę.

Nie, mylisz się - nie tak w ogóle działały lustra Duke Nukem 3D.

DN3D użył silnika portalu . Połączenie dowolnych dwóch sektorów było do pewnego stopnia arbitralne, a gdy silnik renderujący trafił na portal, wiedział, że musi zacząć renderować inny sektor w tym sektorze. Sektor za lustrem był w zasadzie miejscem, w którym można było poradzić sobie z dziwactwem w silniku - jedynym punktem tego sektora było bycie większym niż cokolwiek, co trzeba „odbić”. Nie zawierał żadnej prawdziwej geometrii. W rzeczywistości działał on prawie tak samo, jak „portale” działają w portalu - z tym wyjątkiem, że portal (sam oparty na silniku portalu) tworzy portale w czasie wykonywania i ma limit liczby powtórzeń portali (np. A -> B -> A -> B -> A ...), podczas gdy kompilacja (DN3D) po prostu się zawiesi, ponieważ jego stos zostanie przepełniony, jeśli skierujesz lustro na inne lustro.

Oczywiste jest, jak łatwo można w ten sposób zaimplementować lustro - stworzyć portal prowadzący z powrotem do pokoju. Oznaczało to, że renderowanie lustra kosztowałoby dokładnie tyle samo, co renderowanie samego pokoju, zapewniając doskonałą wydajność i spójność. Tak długo, jak nie skierowałeś lustra na inne lustro. Jeśli przejrzysz kod źródłowy silnika kompilacji, zobaczysz, że w ogóle nie ma lusterek obsługujących kod - nie musi być jeden, ponieważ tak działają portale UWAGA: w rzeczywistości istnieje kod do odwrócenia renderowanych pikseli - to po prostu nie odwraca geometrii i wszystkich różnych duszków i efektów. Redaktor musiał jednak stworzyć te „fałszywe” portale - patrząc na siebie. Jeśli chcesz dowiedzieć się więcej o dość inteligentnym silniku kompilacji, zapoznaj się ze świetną analizą Fabiena Sanglarda z jego kompilacji . Cały silnik został również otwarty i przeniesiony na nowoczesne platformy, chociaż stary nadal działa bezbłędnie na Windows 10 (przetestowany dla Ciebie: P). Wiele gier opartych na Build zostało również udostępnionych i / lub przerobionych.

Dlaczego nie jest już używany? Cóż, niektóre silniki już nie preferują portali. Trudno jest zastosować wiele poprawek graficznych i optymalizacji - nie mogę wskazać niczego konkretnego, ale wiele późniejszych przeróbek zależy od hacków, które nie działałyby w prawdziwym silniku portalu (przyjmują wiele założeń, że już nie trzymaj). Jest to w zasadzie ten sam problem, jaki mają te gry ze zdjęciami stereoskopowymi - hacki już nie działają.

Co najważniejsze, lustra stały się bardziej skomplikowane. Mogą mieć złożone kształty, tekstury, mogą znajdować się na ziemi (znane również jako „woda”) itp. Podczas gdy wszystkie te problemy można rozwiązać w silniku portalu, RTT staje się w pewnym momencie prostszym wyborem, a procesory graficzne są wystarczająco szybkie sobie z tym poradzić.

Jednak mimo to istnieje wiele gier ze sprzętowym przyspieszeniem 3D, które robią rzeczy „prawdziwe”. Na przykład ze starszych gier, Quake 3 lub Alien vs. Predator. O ile mi wiadomo, gry silnika Source nadal używają „prawdziwych” mirrorów. Jeśli oczekujesz, że ludzie zbliżą się do lustra, i możesz zagwarantować, że jednocześnie nie ma zbyt wielu powierzchni odbijających światło (np. Dzięki projektowaniu poziomemu), lustra portalowe są nadal bardzo atrakcyjne.

RTT byłby użyty, gdyby było to możliwe, ale sprzętowy potok renderowania był jednym ze sposobów.

Starszy sprzęt miał również ograniczenia, które uniemożliwiały renderowanie tekstur. Zapis do pamięci RAM oznacza, że ​​nie można jej odczytać w tym samym czasie. Aby poprawić wydajność renderowania, bufor docelowy został zablokowany tylko do zapisu, tylko sprzęt wyświetlający mógł z niego odczytać. Możesz poprosić o odczyt, ale to zablokowało pamięć RAM i render musiał poczekać, aż blokada zostanie wyczyszczona, zanim rozpocznie kolejną ramkę. RTT spowodowałoby poważne wąskie gardło w rurociągu, dlatego zastosowano inne rozwiązania.

Przekonasz się, że przed sprzętowymi potokami renderującymi były używane RTT, ponieważ zapewniało to sposób zmniejszenia obciążenia renderowania. 3D renderowane do duszków w celu zapewnienia pseudo-treści 3D. Renderowanie tekstur było wtedy zbyt kosztowne (CPU), aby można było z niego korzystać, poza specjalistycznymi maszynami, które znajdowały się poza ogólnym rynkiem konsumenckim.

Duke Nukem radzi sobie z tym, że poprzez ponowne renderowanie geometrii za lustrem pozostałe odpowiedzi są częściowo poprawne. Istnieją obszary za lustrami, które w rzeczywistości nie zawierają geometrii (w plikach danych gry), geometria jest renderowana ponownie w czasie rzeczywistym, dlatego te obszary istnieją, aby uniknąć przypadkowego umieszczenia tam poziomu podczas edycji poziomu :

ponieważ jest tam obszar oznaczony, nie przypadkowo umieścisz w nim żadnej geometrii.