Jak włączyć fizykę do generowanego proceduralnie świata z modułu cieniującego geometrię?

Zasadniczo chcę wyeliminować potrzebę generowania spójnego szumu z procesora do GPU. Stamtąd chcę również wygenerować teren dla trójwymiarowego świata, używając tego hałasu jako gęstości w punktach wokseli. Następnie chcę wziąć te gęstości i poligonizować (generować wierzchołki) je reprezentując teren świata.

W porządku. Ale chcę też dynamicznie deformować świat w czasie rzeczywistym. Gdy dojdę do tego punktu, mam problem z próbą przywrócenia wierzchołków z powrotem do procesora, aby wykonać takie czynności, jak wykrywanie kolizji i wszystkie obliczenia w grach, które chcę brać pod uwagę na procesorze, a nie na GPU.

Pytanie brzmi: w jaki sposób mogę uzyskać podzbiór wierzchołków z powrotem do procesora, aby między innymi poradzić sobie z kolizjami?

I jeszcze jedno pytanie: czy istnieje prosty sposób na pobranie zestawu wierzchołków i wygenerowanie z nich indeksów na GPU?

Jestem zdezorientowany, a także tego, jakiego rodzaju shaderów powinienem używać do tych różnych rzeczy. Słyszę o ludziach, którzy używają modułu cieniującego piksele do zbierania gęstości, a następnie używają modułu cieniującego geometrię do radzenia sobie z generowaniem terenu z wierzchołków, a następnie w jakiś sposób włączają moduł cieniujący wierzchołek do wykonywania deformacji dynamicznych.

Używam C # 4.0, .NET 4.0 i XNA Game Studio 4.0.

c# xna shaders

— Michael J. Gray
źródło

Mówisz, że używasz modułu cieniującego geometrię w tytule, ale mówisz także, że używasz XNA4.0, o ile wiem, że XNA 4.0 wymaga DirectX 10 (aby ułatwić tworzenie bardziej jednolitej platformy), ale obsługuje tylko funkcje SM3.0, więc nie ma modułu cieniującego geometrię. forums.create.msdn.com/forums/p/31369/178924.aspx

— Roy T.

A teraz nie będę już używać XNA ani przerabiać mojego projektu. Dzięki za zwrócenie na to uwagi. Patrzyłem na to i nie zdawałem sobie sprawy z tego ograniczenia (brak SM 4). Podejrzewam jednak, że wciąż pozostaje to pytanie, bez uwzględnienia XNA, więc z perspektywy tylko DirectX, czy jest sposób na to, co chcę? A może z shaderem wierzchołków w XNA?

Cóż, XNA jest nadal w użyciu, chyba że masz sprawdzony przypadek testowy, w którym deformacje i generowanie jest zbyt wolne. I udowodniłeś w innym przypadku testowym, że procesor GPU deformuje + generuje, a następnie odzyskuje dane do procesora jest szybszy :)

— Roy T.,

W rzeczy samej. Odkryliśmy, że użycie XNA i utrzymanie wszystkiego na CPU dało nam około 1 miliona wierzchołków w około trzy minuty na Core i7 z 8 rdzeniami i 8 wątkami równolegle do wielu odcinków terenu na wątek. Próbując to zrobić w czasie rzeczywistym i mając nadzieję, że renderujemy teren, zanim gracz go zobaczy, osiągnęliśmy około 20 klatek na sekundę. Tak więc przypadek testowy jest zdecydowanie zgodny z każdą z metod.

— Michael J. Gray

Ponieważ XNA nie obsługuje shaderów geometrii, odpowiem tak, jakbyś używał DX 10. Zasadniczo masz trzy opcje.

Shadery geometrii Shadery geometrii mogą faktycznie modyfikować i dodawać wierzchołki do bufora wierzchołków. Możesz to odczytać z powrotem do procesora. Nie zagłębiłem się w to, ale jest to na pewno możliwe.

Po prostu użyj procesora Po drugie, dlaczego po prostu nie obliczasz tego na procesorze? Fakt, że działa on na GPU w modułach cieniujących, sugeruje, że twój algorytm deformacji jest zlokalizowany, tj. Możesz łatwo wygenerować tylko części zapasowe do kontroli kolizji.

Na przykład jakiś czas temu stworzyłem grę żeglarską. Ocean użył shaderów wierzchołków i geometrii do deformowania wody za pomocą fal. Użyłem tego samego algorytmu obliczonego na procesorze tylko w kilku punktach pod łodzią do ruchu łodzi na falach. Jestem pewien, że możesz zrobić coś podobnego dla swojej mapy wokseli.

Shadery pikseli Ostatnia opcja, o której wspomniałeś w swoim pytaniu: wygeneruj gęstość w module cieniującym i zapisz go do tekstury 3D. Możesz uzyskać do niego dostęp z procesora i shaderów dość nieszkodliwie. Moduł cieniujący pikseli jest idealny do tego zadania, ale ta metoda ma wiele narzutów. Renderowanie tekstury objętości, a także próbkowanie z wewnątrz wierzchołka i geo. shadery i konieczność odczytywania tekstury na procesorze.

Nie znam specyfiki twojego projektu, ale zawsze używałbym do tego CPU. Z całą pewnością oblicz również gęstości shaderów, ale trzymaj się karty graficznej do renderowania.

— Hannesh
źródło

Głównym problemem, jaki mieliśmy, była bariera procesora GPU. W tym sensie, jak po wygenerowaniu i renderowaniu terenu na GPU, jak dowiedzieć się, jak wygląda teren po stronie procesora, aby wykonywać kolizje i inne rzeczy. Podejrzewam, że twoja myśl o utrzymaniu go na CPU jest prawidłowa. Mam na myśli, że prawdopodobnie możemy całkiem zoptymalizować nasz algorytm i wygenerować mniej terenu. Oznaczę twoją odpowiedź jako rozwiązanie za dzień lub dwa, aby sprawdzić, czy ktoś inny ma odpowiedź. Dzięki za sprowokowanie alternatywnych myśli.

— Michael J. Gray

Na przykładzie żeglarstwa nie byłbyś w stanie łatwo połączyć wyniku fali przechodzącej przez falę z falami do GPU, prawda?

— spowolniłaviar

Możesz zachować ten sam system renderowania, tj. Generować i renderować teren na GPU, ale odzwierciedlać części terenu, których potrzebujesz na CPU. Korzystając z tego samego algorytmu i tych samych parametrów, uzyskasz taki sam teren na procesorze, jak widzisz na ekranie.

— Hannesh

@Daniel Nie z algorytmem falowym bezpośrednio, ale możliwe jest odkształcenie siatki wodnej zgodnie z wybuchem łodzi z teksturą przesunięcia, którą każda łódź „ciągnie” za nią.

— Hannesh

Ach! To jest świetny pomysł :). Ale prawdopodobnie nie obsługuje zbyt wielu jednostek pływających.

— spowolniłaviar