Dzięki VBO generalnie masz dwie główne zalety.
Zaleta 1 dotyczy danych w pełni statycznych i wynika z możliwości przechowywania danych wierzchołków w pamięci, która jest bardziej optymalna dla GPU.
Zaleta 2 dotyczy danych dynamicznych i wynika z możliwości określenia danych wierzchołków w dowolnym momencie przed użyciem ich do renderowania, co może lepiej potokować.
Trzecia korzyść wynika z grupowania połączeń losowanych, ale jest również dzielona z oldschoolowymi tablicami wierzchołków, więc nie nazywam tego specjalnie dla VBO. Wysyłanie danych do GPU (lub używanie danych już na GPU) jest pod wieloma względami podobne do dyskowych operacji we / wy i ruchu sieciowego - jeśli masz kilka dużych partii, jest to bardziej wydajne niż wiele małych partii.
Dobra (nie w 100% dokładna, ale wystarczająca, aby pomóc Ci zrozumieć) analogia jest taka, jeśli jesteś kierowcą autobusu, który musi przewozić 50 osób z jednego miasta do drugiego. Możesz je ładować pojedynczo i wykonywać 50 osobnych podróży - to glBegin / glEnd. Alternatywnie możesz umieścić wszystkie 50 z nich w autobusie i zrobić tylko jedną podróż - to wsadowe z tablicami wierzchołków lub VBO (w przypadku VBO 50 osób już by było w autobusie;)).
Ma to jednak swoją cenę, a tutaj cena polega na tym, że tracisz możliwość określania danych wierzchołków, kiedy i kiedy ich potrzebujesz. Cóż, OK, możesz to zrobić (przy dodatkowej pracy), ale nie uzyskasz pełnej wydajności kodu. Zamiast tego musisz pomyśleć więcej o swoich danych wierzchołków, sposobie ich wykorzystania, sposobie (i jeśli) należy je zaktualizować, czy animacje można wykonać w module cieniującym (dzięki czemu dane pozostają statyczne - VBO naprawdę potrzebują shaderów do wiele przypadków animacji, aby działały dobrze) lub czy trzeba ponownie określać dane wierzchołków w każdej ramce, wydajne strategie aktualizacji, jeśli ta ostatnia itp. Jeśli tego nie zrobisz i po prostu wdrożysz naiwną konwersję, masz bardzo duże ryzyko wprowadzenia w dużo pracy tylko po to, by efekt końcowy działał wolniej!
To może wydawać się okropnie dużo pracy, kiedy ją spotkasz, ale tak naprawdę nie jest. Gdy przejdziesz do takiego sposobu myślenia, w rzeczywistości przekonasz się, że jest to niezwykle łatwe i prawie przychodzi naturalnie. Ale możesz zepsuć kilka pierwszych prób i nie powinieneś się zniechęcać, jeśli tak - zepsucie to okazja, aby dowiedzieć się z tego, co popełniłeś źle.
Kilka ostatnich myśli.
Posiadanie danych modelu w formacie, który można łatwo załadować do VBO, może znacznie ułatwić ci cały proces. Oznacza to, że powinieneś unikać bardziej złożonych lub egzotycznych formatów, przynajmniej na początku (i dopóki nie poczujesz się bardziej komfortowo z tym procesem); staraj się zachować jak najprostszą i podstawową wiedzę podczas nauki, a będzie mniej rzeczy do zrobienia i mniej miejsc do szukania błędów, jeśli (lub kiedy!) coś pójdzie nie tak.
Ludzie są czasem zniechęcani, jeśli widzą implementację VBO używającą więcej pamięci niż zoptymalizowana / skompresowana implementacja glBegin / glEnd (mogą nawet nazywać to „marnotrawstwem”). Nie bądź taki. Z wyjątkiem skrajnych przypadkach zużycie pamięci nie jest to , że ważne. Jest to wyraźny kompromis - akceptujesz potencjalnie wyższe wykorzystanie pamięci w zamian za znacznie wyższą wydajność. Pomaga również rozwinąć sposób myślenia, że pamięć jest tanim i bogatym zasobem, który można wykorzystać; wydajność nie jest.
I wreszcie stary kasztan - jeśli jest już wystarczająco szybki, to twoja praca jest skończona. Jeśli osiągasz docelową liczbę klatek na sekundę, jeśli masz dość miejsca na przejściowe warunki, jest to wystarczająco dobre i możesz przejść do następnego kroku. Możesz zmarnować dużo czasu i energii, wyciskając dodatkowe 10% z czegoś, czego tak naprawdę nie potrzebuje (byłeś tam, zrobiłem to, wciąż wpadam w pułapkę), więc zawsze zastanów się, jakie jest najbardziej optymalne wykorzystanie twojego czasu. - ponieważ czas programisty jest jeszcze mniej tani i mniej obfity niż wydajność!