Generowanie terenu na GPU

9

W moim silniku tworzę nieskończony teren z wykorzystaniem algorytmu szumu Perlina obliczonego na procesorze.

Tworzenie terenu przebiega następująco:

  • Jeśli kamera znajduje się w pobliżu rozładowanej łatki, utwórz ją
  • Oblicz tablicę szumów 513 x 513 z podanymi granicami
  • Obliczanie normalnych, stycznych, dwumianowych, indeksów
  • Przekaż dane do vbo

Plusy:

  • Trzeba je renderować tylko w razie potrzeby
  • Łatwa do zderzenia

Kon

  • Powolne 64 łatki 513x513 są tworzone w 3,1s (jeden wątek). Dla każdej płytki ~ 20ms wytwarzanie szumu, ~ 25ms wierzchołki, normalne, styczna, bitangent, indeksy. Gdy kamera porusza się szybko, użytkownik może zauważyć ładowanie płytek.
  • pamięć zużywa ???

Teraz zastanawiałem się, jak to przyspieszyć, generując teren całkowicie na GPU. Istnieją jednak pewne wątpliwości:

  • Jeśli moduły cieniujące działają w każdej ramce, to czy ta moc obliczeniowa nie jest marnowana na obliczanie hałasu w kółko? Można tego uniknąć, zapisując wynik do tekstury RBGA i wykorzystując go później w module cieniującym wierzchołki do przemieszczania, ale zwiększając zużycie pamięci. Z drugiej strony, jeśli stworzenie byłoby super szybkie, tylko widoczne kafelki powinny pozostać w pamięci. Jednak odłączenie bufora powoduje synchronizację gpu-cpu, co może spowolnić aplikację (mam rację?)
  • Jeśli teren jest tylko płaską siatką przesuniętą przez moduł cieniujący wierzchołki, należy wykonać tę samą pracę na CPU, aby obliczyć wysokość i normalne w danym punkcie kolizji.
  • To tylko koncepcja, ale aby przyspieszyć wszystko, myślałem o rzutowaniu siatki na rzutnię, tak aby używana była tylko minimalna liczba wierzchołków. Myślisz, że to zadziała?

Moje ostatnie pytanie brzmi:

Jaka jest najlepsza / najszybsza / szeroko stosowana technika tworzenia nieskończonego terenu na GPU?

terrain użytkownik1075940
źródło
8
Należy pamiętać, że utworzenie terenu na GPU utrudni wykrywanie kolizji, wykrywanie wyborów lub prawie dowolną interakcję z terenem.
MichaelHouse
1
Moduł obliczający (DX10 lub 11) może być użyty do wygenerowania terenu na GPU. Ale jak stwierdził Byte56, będziesz musiał wyciągnąć wartości z GPU, aby móc z nim współdziałać. msdn.microsoft.com/en-us/library/windows/desktop/…
UnderscoreZero
tworzenie terenu na GPU wydaje mi się złym pomysłem. Może to działać, ale myślę, że prawdopodobnie działałoby to trochę lepiej, jeśli po prostu wygenerujesz teren po stronie procesora i wyślesz standardowe elementy rysunkowe do GPU.
Benjamin Danger Johnson
Tylko moje doświadczenie; Zrobiłem to właśnie za pomocą aparapi i udało mi się uruchomić to cholerstwo; ale w rzeczywistości okazało się, że jest wolniejszy niż procesor. Myślę, że z powodu narzutu związanego z wysyłaniem danych do / z GPU. Jeśli dobrze pamiętam, gpu naprawdę działa tylko wtedy, gdy obliczenia są duże w porównaniu do wielkości danych (a także duże w wartościach bezwzględnych)
Richard Tingle,
Ten artykuł może dać ci kilka pomysłów http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html
Jeremiah Leslie

Odpowiedzi:

2

Cóż, gdybym miał do tego celu użyć GPU, myślę, że wybrałbym compute / opencl / cuda.

Jednak bez względu na użycie procesora graficznego lub procesora (co tak naprawdę robię) zrobiłbym to w sposób asynchroniczny, uznając, że potrzebujesz trochę nowego terenu dla bieżącej klatki, jest prawdopodobnie zbyt późno (np. Rozważ 1000ms / 60 = 16,666ms, i cała rama chce się do tego zmieścić).

Rozpocznij generowanie (lub ładowanie ze skompresowanych plików) terenu w wątku roboczym i udostępnianie go pozostałej części gry oraz renderowanie po zakończeniu tego procesu roboczego, na ogół będzie to następna klatka, a może później klatka, więc użytkownik tak naprawdę nie zauważy różnicy, ale dzięki temu wszystko będzie gładsze.

Będzie
źródło