W 2.5D używasz zasobów 2D / technik renderowania, aby dać wrażenie środowiska 3D.
Teraz, z tą definicją, w następującym potencjalnie niejednoznacznym scenariuszu wymagane jest pewne opracowanie:
Gra A
Używając grafiki 3D, GPU przyspieszone i wszystkie (obiekty gry to siatki, a nie obrazy), ze stałym kątem kamery. Zróbmy jeszcze gorzej, rzut jest ortograficzny, klasyczny 63,43 stopnia. Jedynym sposobem, aby zauważyć na pierwszy rzut oka, że grafika nie jest 2D, jest to, że 3DGC, z wyjątkiem tego, że renderujesz je z niezwykłą starannością, łatwo można odróżnić od sprite'ów do rysowania ręcznego, niezależnie od projekcji użytej do ich renderowania. Możesz eksperymentować z różnymi technikami renderowania, parametrami, modułami cieniującymi itp., A będziesz miał trudności z ukryciem faktu, że są to siatki 3D.
Gra B
Port w grze A, ale ukierunkowany na platformy, o których wiadomo, że mają sprzęt, który nie radzi sobie zbyt dobrze z grafiką 3D lub wcale go nie obsługuje. Następnie port zastępuje siatki spritami. Nadal używa na przykład 3D Bounding Boxes do kolizji, a obiekty mają właściwość position z wartościami x, y i z, ponieważ logika gry w większości nie została dotknięta lub w ogóle nie została dotknięta, tylko kod renderowania został zmieniony.
Ponieważ duszki w grze B są renderami zasobów 3D gry A, a dla uproszczenia gry gra A nie robi niczego, co wymaga skomplikowanych shaderów, w 99% wszystkich procesorów graficznych nie można odróżnić ramki od gry B kadru z gry A.
W 2.5D interakcja między obiektami gry jest ograniczona do zestawu sytuacji, w których iluzja 3D nie może zostać naruszona. Na przykład, aby reprezentować przytulanie się dwóch znaków, musisz utworzyć pojedynczy plik obrazu z interakcją dwóch znaków, ponieważ próba przedstawienia operacji przytulania tylko przy użyciu jednego obrazu na znak byłaby zbyt trudna lub niemożliwa. Może możesz przyjść z postacią podzieloną na części i narysować je we właściwej kolejności. W 3D problem ten nie istnieje (istnieje inny, polegający na prawidłowym ułożeniu dwóch znaków, aby nie przenikały przez siatkę drugiego znaku).
Teraz, aby to zwizualizować, wyobraź sobie, że w grze A i B występuje błąd, który w niektórych sytuacjach pozwala postaci gracza przejść przez inny obiekt gry, umożliwiając nam łatwe rozróżnienie między 2.5D a 3D.
Gra B, 2.5D Renderowanie, duszki są uporządkowane według wartości z wektora położenia. W tym przykładzie dodatnie z jest w dół, a ujemne z jest w górę. oś z i oś y są równoległe, ale z jest skalowane o współczynnik 0,5 y. Więc jeśli widoczny obszar wynosi od 10 do 10 lat, w tym samym obszarze mamy od 20 do 20 z. Obiekty z większym z zostaną narysowane jako ostatnie, więc będą postrzegane jako znajdujące się przed obiektami o niższym z. Cień postaci gracza wygląda dziwnie, ponieważ cienie są w wyższej warstwie niż podłoga, ale w gorszej warstwie niż wszystkie inne obiekty, więc cień postaci gracza nigdy nie znajduje się na kostce.
Gra A, renderowanie 3D. Bufor głębokości (znany również jako bufor Z) służy do testowania głębokości z precyzją pikseli. Zatem obiekt nie musi całkowicie zamykać innego, nawet trójkąt nie musi całkowicie zamykać innego, mamy test głębokości precyzji pikseli. Możemy obracać obiekty gry w dowolny sposób i nadal uzyskiwać realistyczne wyniki, gdy wchodzą w interakcje.
W CV: w wersji 2.5D duszek znajduje się przed lub za innym duchem. W 3D siatka składa się z trójkątów, ale trójkąt nie jest minimalną jednostką podczas testowania głębokości, możesz mieć precyzję pikseli. Oczywiście obrót kamery w 2.5D jest niemożliwy, ponieważ zasoby zostały utworzone dla stałego kąta kamery, podczas gdy w 3D jest naturalne, jeśli kąty kamery są ograniczone przez projekt w grze 3D to inny temat.
Istnieją różne triki, które dają wrażenie bycia w świecie 3D, gdy można tylko renderować grafikę 2D, przedstawiłem tylko szybko spreparowany przykład z wykorzystaniem niektórych zasobów mojego opuszczonego projektu.
Dlaczego nie zawsze używać 3D i zapomnieć o 2.5D?
Cóż, mogę pomyśleć w kilku przykładach, dlaczego deweloper może preferować podejście 2.5D:
- Być może nie znają lub nie lubią interfejsów API 3D (Direct3D, OpenGL, są inne).
- Być może platforma docelowa nie obsługuje dobrze grafiki 3D (stare komputery stacjonarne, konsole 2D).
- Twój zespół może robić niesamowite duszki, ale nie modele 3D.
Jak bardzo możesz przybliżać wyniki grafiki 3D za pomocą 2.5D?
Istnieje horyzont wydajności i złożoności programowania. Gdy zbliżysz się do tego horyzontu, zaczniesz wątpić, czy Twój projekt jest naprawdę możliwy w 2.5D, czy też musisz przejść do pełnego 3D. Na przykład możesz użyć buforowania Z w wersji 2.5D (teoretycznie), ale czy możesz zapłacić koszt pamięci wideo (stary komputer stacjonarny z wbudowaną grafiką, a nie wydajne urządzenia mobilne)? Czy chcesz zapłacić koszt przechowywania dodatkowego obrazu, aby zapisać maskę Z każdego duszka?
Dobrymi kandydatami do 2.5D są gry RPG, myślcie, że Baldur's Gate lub RTS uważa Age of Empires 1 i 2 (AoE 3 jest w pełni 3D i łatwo je odróżnić).
Przydatne referencje:
Buforowanie Z: http://en.wikipedia.org/wiki/Z-buffering
Rzuty ortograficzne: http://glasnost.itcarlow.ie/~powerk/GeneralGraphicsNotes/projection/orthographicprojection.html