Koncepcja
Zasadniczo wykres sceny to nic innego jak dwukierunkowy wykres acykliczny, który służy do przedstawienia hierarchicznie ustrukturyzowanego zestawu relacji przestrzennych.
Jak zauważono, silniki na wolności zawierają inne dodatki na wykresie sceny. To, czy widzisz to jako mięso czy krowę, prawdopodobnie zależy od twojego doświadczenia z silnikami i bibliotekami.
Lekkość
Opowiadam się za stylem Unity3D polegającym na tym, że węzeł wykresu sceny (którego sednem jest raczej struktura topologiczna niż struktura przestrzenna / topograficzna) z natury obejmuje parametry przestrzenne i funkcjonalność. W moim silniku moje węzły są jeszcze lżejsze niż Unity3D, gdzie dziedziczą wielu niepotrzebnych niepotrzebnych członków z superklas / zaimplementowanych interfejsów: Oto co mam - mniej więcej tak lekkie, jak tylko możesz:
- członkowie wskaźnika rodzic / dziecko.
- wstępnie przetworzone elementy parametrów przestrzennych: pozycja xyz, skok, odchylenie i przechylenie.
- macierz transformacji; macierze w hierarchicznym łańcuchu można bardzo szybko i łatwo pomnożyć, przechodząc rekurencyjnie w górę / w dół drzewa, dając hierarchiczne przekształcenia przestrzenne, które są główną cechą wykresu scen;
updateLocal()metoda, która aktualizuje tylko ten węzeł jest przekształcić matryceupdateAll()metoda, która aktualizuje to i wszystkie podrzędne węzły transformacji macierzy
... W mojej klasie węzłów uwzględniam także logikę równań ruchu, a zatem elementy prędkości / przyspieszenia (liniowe i kątowe). Możesz zrezygnować z tego i zamiast tego obsłużyć go w głównym kontrolerze. Ale o to chodzi - naprawdę bardzo lekki. Pamiętaj, że możesz mieć je na tysiącach bytów. Tak jak zasugerowałeś, zachowaj światło.
Konstruowanie hierarchii
Co powiesz o wykresie scen odnoszącym się do innych wykresów scen ... Czekam na poncz? Oczywiście, że tak. To ich główne zastosowanie. Możesz dodać dowolny węzeł do dowolnego innego węzła, a transformacje powinny odbywać się automatycznie w przestrzeni lokalnej nowej transformacji. Wszystko, co robisz, to zmiana wskaźnika, to nie tak, że kopiujesz dane! Zmieniając wskaźnik, masz głębszy wykres sceny. Jeśli korzystanie z serwerów proxy powoduje, że wszystko jest bardziej wydajne, to nigdy nie widziałem takiej potrzeby.
Unikaj logiki związanej z renderowaniem
Zapomnij o renderowaniu, gdy piszesz klasę węzłów grafu scen, bo inaczej pomylisz rzeczy. Liczy się tylko to, że masz model danych - niezależnie od tego, czy jest to wykres sceny, czy nie - i że jakiś renderer będzie sprawdzał ten model danych i odpowiednio renderował obiekty na świecie, bez względu na to, czy jest to 1, 2 , 3 lub 7 wymiarów. Chodzi mi o to: nie zanieczyszczaj grafu sceny logiką renderowania. Wykres sceny dotyczy topologii i topografii - tj. Połączeń i cech przestrzennych. Są to prawdziwy stan symulacji i istnieją nawet przy braku renderowania (który może przybierać dowolną formę pod słońcem od widoku pierwszej osoby do wykresu statystycznego do opisu tekstowego). Węzły nie wskazują obiektów związanych z renderowaniem - jednak może być odwrotnie. Weź również pod uwagę to: Nie każdy węzeł wykresu sceny w całym drzewie będzie renderowany. Wiele będzie tylko pojemnikami. Po co więc alokować pamięć dla wskaźnika do renderowania-obiektu? Nawet wskaźnik, który nigdy nie jest używany, nadal zajmuje pamięć. Więc odwróć kierunek wskaźnika: instancja związana z renderowaniem odwołuje się do modelu danych (który może być lub zawierać węzeł wykresu sceny), NIE odwrotnie. A jeśli chcesz w łatwy sposób przeprowadzić przeglądanie listy kontrolerów, a jednocześnie uzyskać dostęp do powiązanego widoku, skorzystaj ze słownika / tablicy skrótów, która zbliża się do czasu dostępu do odczytu O (1). W ten sposób nie ma zanieczyszczenia, a logika symulacji nie dba o to, jakie rendery są na miejscu, co sprawia, że twoje dni i noce kodowania Po co więc alokować pamięć dla wskaźnika do renderowania-obiektu? Nawet wskaźnik, który nigdy nie jest używany, nadal zajmuje pamięć. Więc odwróć kierunek wskaźnika: instancja związana z renderowaniem odwołuje się do modelu danych (który może być lub zawierać węzeł wykresu sceny), NIE odwrotnie. A jeśli chcesz w łatwy sposób przeprowadzić przeglądanie listy kontrolerów, a jednocześnie uzyskać dostęp do powiązanego widoku, skorzystaj ze słownika / tablicy skrótów, która zbliża się do czasu dostępu do odczytu O (1). W ten sposób nie ma zanieczyszczenia, a logika symulacji nie dba o to, jakie rendery są na miejscu, co sprawia, że twoje dni i noce kodowania Po co więc alokować pamięć dla wskaźnika do renderowania-obiektu? Nawet wskaźnik, który nigdy nie jest używany, nadal zajmuje pamięć. Więc odwróć kierunek wskaźnika: instancja związana z renderowaniem odwołuje się do modelu danych (który może być lub zawierać węzeł wykresu sceny), NIE odwrotnie. A jeśli chcesz w łatwy sposób przeprowadzić przeglądanie listy kontrolerów, a jednocześnie uzyskać dostęp do powiązanego widoku, skorzystaj ze słownika / tablicy skrótów, która zbliża się do czasu dostępu do odczytu O (1). W ten sposób nie ma zanieczyszczenia, a logika symulacji nie dba o to, jakie rendery są na miejscu, co sprawia, że twoje dni i noce kodowania A jeśli chcesz w łatwy sposób przeprowadzić przeglądanie listy kontrolerów, a jednocześnie uzyskać dostęp do powiązanego widoku, skorzystaj ze słownika / tablicy skrótów, która zbliża się do czasu dostępu do odczytu O (1). W ten sposób nie ma zanieczyszczenia, a logika symulacji nie dba o to, jakie rendery są na miejscu, co sprawia, że twoje dni i noce kodowania A jeśli chcesz w łatwy sposób przeprowadzić przeglądanie listy kontrolerów, a jednocześnie uzyskać dostęp do powiązanego widoku, skorzystaj ze słownika / tablicy skrótów, która zbliża się do czasu dostępu do odczytu O (1). W ten sposób nie ma zanieczyszczenia, a logika symulacji nie dba o to, jakie rendery są na miejscu, co sprawia, że twoje dni i noce kodowaniaświaty łatwiejsze.
Jeśli chodzi o ubijanie, powróć do powyższego. Ubojnie obszaru zainteresowania to koncepcja logiki symulacyjnej. Oznacza to, że świat nie jest przetwarzany poza tym obszarem (zwykle pudełkowym, okrągłym lub sferycznym). Odbywa się to w głównej pętli kontrolera / gry, zanim nastąpi renderowanie. Z drugiej strony, wybijanie frustum jest ściśle związane z renderowaniem. Więc zapomnij o ubijaniu już teraz. Nie ma to nic wspólnego z wykresami scen, a skupiając się na nim, zaciemnisz prawdziwy cel tego, co próbujesz osiągnąć.
Ostatnia uwaga ...
Mam wrażenie, że pochodzisz z Flasha (szczególnie AS3), biorąc pod uwagę wszystkie szczegóły dotyczące renderowania zawarte tutaj. Tak, paradygmat Flash Stage / DisplayObject obejmuje całą logikę renderowania jako część scenegrafu. Ale Flash przyjmuje wiele założeń, których niekoniecznie chcesz poczynić. W przypadku pełnoprawnego silnika gry lepiej nie mieszać tych dwóch elementów ze względu na wydajność, wygodę i kontrolę złożoności kodu poprzez odpowiednie SoC .