Do wykresu sceny czy nie do wykresu sceny?

Zmagam się z decyzją, czy zaimplementować wykres sceny w mojej grze. Mam kilka przypadków użycia, które wymagają takiego narzędzia, ale nie byłem w stanie przejść przez niektóre szczegóły implementacji.

Trochę tła: piszę kosmiczną strzelankę przeznaczoną na platformę mobilną (głównie Android), a mój kod to prawie całkowicie C ++. Nie używam żadnego oprogramowania pośredniego; w szczególności silniki renderowania i fizyki są moimi własnymi dziełami. Mój silnik fizyki aktualizuje lokalizacje obiektów na podstawie sił i impulsów. Nie mam jeszcze systemu animacji, ale w pewnym momencie mogę go odwiedzić (co może, ale nie musi mieć nic wspólnego z tą dyskusją).

Najpierw opiszę dobry przypadek użycia. Chciałbym mieć bossa, który składa się z kilku dyskretnych części, z których każda może zostać uszkodzona / zniszczona niezależnie. Na przykład, mogę mieć bossa, który ma ramię, które może otrzymywać obrażenia niezależnie od reszty bossa. Kiedy ramię zostanie zniszczone, efekt cząsteczki ognia znajdujący się na ramieniu bossów może wskazywać, że ramię zostało zniszczone.

W tej chwili postanowiłem spróbować rozwiązać takie problemy z ograniczeniami w moim silniku fizyki, aby utrzymać takie złożone obiekty razem. Jedno takie ograniczenie zapewnia 0 stopni swobody i jest zasadniczo matrycą transformacji. Jest to naprawdę próba obejścia problemu, który ostatecznie mnie wyłączył z wykresów scen, przede wszystkim opisanych poniżej.

Głównym powodem, dla którego zrezygnowałem z używania wykresu scen, jest to, że nie mogłem znaleźć skutecznego sposobu na utrzymanie zagnieżdżonych obiektów (obiektów dziedziczących transformację od ich rodzica) zarówno w świecie fizyki, jak i na scenie renderowania. Świat fizyki potrzebuje obiektów w przestrzeni świata (lub przynajmniej w tej samej przestrzeni), podczas gdy scena renderowania potrzebuje obiektów w przestrzeni rodzica. Śledzenie lokalizacji w obu przestrzeniach może pomóc (i być nieuniknione), ale budzi własne wątpliwości, z których przynajmniej dotyczy wydajności.

Jednak biorąc pod uwagę przypadki użycia takie jak ten opisany powyżej, myślę, że zdolność do „pracy” w przestrzeni nadrzędnej stanie się bardzo ważna, a próba zmuszenia mojego silnika fizyki do utrzymania tych relacji za pomocą ograniczeń stanie się problematyczna.

Biorąc pod uwagę opisany powyżej przypadek użycia i sytuację, czy powinienem używać struktury wykresu do przekazywania transformacji z jednego obiektu do drugiego? Jeśli tak, to w jaki sposób mój silnik fizyki powinien obliczyć nowe lokalizacje i przeprowadzić testy przecięcia obiektów w różnych przestrzeniach?

Czy rzeczywiście wypróbowałeś hierarchiczny wykres i zmierzyłeś wydajność?

Czy badałeś proste silniki fizyki, aby zobaczyć, jak radzą sobie z tym problemem, nawet silnik 2D, który ma powiązanie między obiektami, pomógłby poprowadzić cię w sprawdzonym kierunku.

Nie próbowałbym prowadzić twojej fizyki w wielu przestrzeniach, złożoność byłaby zniechęcająca. Uruchom fizykę w przestrzeni świata i dodaj funkcjonalność, aby utworzyć transformacje swojej hierarchii, aby przenieść obiekty przestrzeni lokalnej do przestrzeni świata iz powrotem. Twoje ograniczenia z konieczności muszą znajdować się w przestrzeni lokalnej względem obiektu nadrzędnego.

Na marginesie, nawet czysty układ obiektów jest „grafem scen”, po prostu bardzo prostym. Nie bój się organizować danych w taki sposób, aby rozwiązać problemy, a zwłaszcza nie decyduj, że wydajność tej organizacji danych jest czynnikiem, nawet nie mierząc tej wydajności.