Czy powinienem nadać każdej postaci osobne VBO, czy powinienem podzielić je na pojedyncze VBO?

Robię grę 3D w pierwszej osobie. Czy powinienem nadać każdej postaci osobne VBO, czy też mogę spakować wszystkie postacie w jedno VBO? Jakie są zalety / wady?

opengl vbo

— Xavier
źródło

To jest duplikat pytania. Czego nie jestem zbyt pewien, ale to oszustwo.

— DeadMG

Jest podobny do tego , ale nie wierzę, że jest to duplikat per se, na początek jest to Open-GL (nie jestem pewien, czy są jakieś specyficzne różnice), podczas gdy inne pytanie dotyczy deformowalności w DirectX11 (prawdopodobnie wykorzystujący teselację, która zmienia rzeczy).

— Thomas Russell

To naprawdę wybór między wydajnością a elastycznością, ale wymienię moje opinie na ten temat.

Jeden pojedynczy VBO

Pozytywne strony to:

Tylko jedno losowanie, aby narysować scenę. To zwiększa wydajność. Chociaż twoja aplikacja może wymagać wielu wywołań losowania, nadal możesz mieć jedno VBO i pozwolić, aby liczba i przesunięcie zadecydowały o twoim losowaniu.
Nie wymaga zmian stanu między twoimi obiektami. To zwiększa wydajność.

a negatywne strony to:

Trudne do zarządzania, choć zależy to od tego, jak piszesz kod, czy jest odpowiednio zaprojektowany itp.
Mówiąc „ trudno zarządzać” mam na myśli takie rzeczy, jak aktualizacja VBO, ustawienie prawidłowego przesunięcia dla każdego obiektu itp.

Indywidualne VBO: s

Pozytywne strony to:

Łatwy do wdrożenia.
Łatwiejsze zarządzanie od samego początku.

a negatywne strony to:

Wiele zmian stanu. To zmniejsza wydajność.
Wiele losowań. Spowoduje to zmniejszenie wydajności.

Podsumowanie

Polecam profilowanie twojej aplikacji; uzyskaj prawdziwe wąskie gardło w danych, które możesz zobaczyć. Przedwczesna optymalizacja może zostać pokazana (w tym przypadku) jako niepotrzebna. Biorąc to jednak pod uwagę, jeśli odkryjesz prawdziwą utratę wydajności w swojej aplikacji, biorąc pod uwagę scenariusz indywidualnego VBO , możesz rozpocząć wdrażanie pojedynczego VBO.

Jednak, dopóki nie jest to konieczne (liczba obiektów jest niska, ogólnie niewiele zmian stanu itp.) Polecam korzystanie z poszczególnych VBO: s, chyba że widzisz, że to nie zadziała.

Edytować

Zapomniałem wspomnieć, że przy wielu losowaniach byłoby dobrze. Najważniejszą rzeczą w czasach krytycznych dla wydajności jest ograniczenie zmian stanu do minimum. Możesz po prostu ustawić liczbę indeksów do przetworzenia i przesunięcie dla każdego połączenia losowania, i to jest w porządku. Jednak utrzymuj zmiany stanu na jak najniższym poziomie i wykonuj jak najmniej połączeń losujących, to wielka cześć tej odpowiedzi, a przynajmniej to, co próbowałem powiedzieć.

— Wroclai
źródło

Jeśli wykonujesz tylko 1 call draw, to przekręca cię dla zmian stanu siatki (nie wierzchołka) (mundury itp.). Wymusza także wszystko lub nic do rysowania wszystkiego. Jasne, że możesz to rozbić, aby było tylko 1 wielokrotne wywołanie VBO, ale co, jeśli chcesz dodać nową siatkę?

— spowolniłaviar

@Daniel: Nowa siatka powinna być po prostu zaktualizowana / dodana do VBO. Zapomniałem wspomnieć, że przy wielu losowaniach byłoby dobrze. Najważniejszą rzeczą w czasach krytycznych dla wydajności jest ograniczenie zmian stanu do minimum. Możesz po prostu ustawić liczbę indeksów do przetworzenia i przesunięcie dla każdego połączenia losowania, i to jest w porządku. Jednak utrzymuj zmiany stanu na jak najniższym poziomie i wykonuj jak najmniej połączeń losujących, to wielka cześć tej odpowiedzi, a przynajmniej to, co próbowałem powiedzieć. :-)

— Wrocław

Batch, batch, batch w 2005 roku doszedł do wniosku, że możesz sobie pozwolić na od 10 do 25 000 partii na procesorze 1 GHz, zanim całkowicie związasz procesor z samym przetwarzaniem wywołań losowania. Jak to przekłada się na kilkuset partii na 60Hz ramka, shoehorning wszystko w jednym VB nie jest konieczne, ale na pewno pomaga, jeśli wiązka geometria, która ma podobne cechy (trwania, częstotliwość aktualizacji, atrybuty) do tego samego VB.

— Lars Viklund,

Myślę, że powinieneś również wziąć pod uwagę ubijanie frustum.

— Tara