Wykres sceny w osobnym wątku


12

Opracowuję własny silnik gry dla zabawy (ale nie zysku). Mam renderowanie w jednym wątku, a moje aktualizacje scen (prędkość itp.) W innym. Kiedy nadchodzi czas renderowania, wątek renderujący dodaje widoczne węzły do ​​nowego bufora liniowego i przechodzi przez nie.

Bardziej szczegółowo, mój wykres sceny jest trzykrotnie buforowany. Każdy węzeł na moim wykresie sceny ma trzy kopie swoich względnych i absolutnych macierzy transformacji (4x4). W dowolnym momencie wątek wykresu zapisuje jedną kopię, jedna kopia jest odczytywana przez renderer, a trzecia istnieje, aby czytelnik lub pisarz mógł przejść do następnej bez oczekiwania na drugą. Zapobiega to pisaniu na czymś podczas renderowania i renderowaniu częściowo zaktualizowanego wykresu sceny. W jakiś sposób mam również czwartą kopię każdej matrycy, z którą użytkownik może pracować, aby nie kolidować z wątkiem aktualizacji. Wydaje się, że działa to dobrze, unikając konieczności ciągłej synchronizacji.

Jest to jednak bałagan.

Oto moje ostateczne cele dla systemu:

  • Renderowanie i aktualizacja wykresu sceny pozostają w osobnych wątkach.
  • Zminimalizuj, ile te wątki muszą na siebie czekać.
  • Nie renderuj sceny, która została w połowie zaktualizowana przez wątek aktualizacji. Jest to szczególnie widoczne, jeśli kamera porusza się szybko, a czasami jest renderowana przed aktualizacją lub po niej.
  • Zmniejszone zużycie pamięci. Mam o wiele za dużo macierzy na węzeł. Zastanawiam się również nad przejściem do wektorów dla pozycji / obrotu / skali z powodu zwiększonego dryftu zmiennoprzecinkowego za pomocą macierzy.
  • Możliwość obsługi dziesiątek tysięcy węzłów. Obecny system robi to dość dobrze.

Mam również nadzieję, że w przyszłości zastosuję Bullet (silnik fizyki) i tworzenie sieci, o których nie zastanawiałem się długo.

Jakie są podejścia do uzyskania lepszego wykresu sceny?

Odpowiedzi:


4

Czy czytałeś tezę Johannesa Spohra na temat „Tempa” i jego renderera? Opisuje tak zwany mechanizm renderujący równoległy „silnik przesyłania” * i może dać ci kilka pomysłów.

Oto strona podsumowania (w języku niemieckim), a tutaj jest bezpośredni link do pliku PDF w języku angielskim.

( *: ten link prowadzi również do artykułu, w którym pierwotnie słyszałem o pracy magisterskiej).

EDYCJA: Przeglądałem to tylko wcześniej i po prostu spojrzałem na to ponownie ... i zdałem sobie sprawę, że to naprawdę błyszczy na szczegółach wykresu sceny. Chyba nie zdawałem sobie sprawy z tego, jak ortogonalny był jego projekt. Przepraszamy, jeśli nie jest to szczególnie pomocne.


1
Jeden kawałek tego artykułu wciąż mi się przydał: „Idealnie, aplikacja w ogóle nie wiedziałaby, że jest wykres sceny, powinna być świadoma tylko komponentu widoku, który musi informować o zmianach w modelu danych”. To zainspirowało mnie do nowego sposobu myślenia o tym: nie muszę trzykrotnie buforować całej sceny, tylko to, co jest widoczne przez obecny aparat. Mogę przenieść culling z wątku renderowania do wątku wykresu sceny (gdy napotka on kamerę), aw dowolnym momencie jeden z tych trzech buforów może być przez niego zapisany, a drugi odczytany przez renderer.
EricP

1
Możesz także zapoznać się z artykułem „Konstrukcja silnika skoncentrowanego na kamerze dla renderowania wielowątkowego” w Game Engine Gems 1 oraz powiązanym „Praktycznym równoległym renderowaniem z DirectX 9 i DirectX 10” - microsoft.com/downloads/en/…
Neverender

1
Wygląda na to, że Game Engine Gems 1 jest dostępny bezpłatnie online: books.google.com/…
EricP
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.