Ta terminologia jest zakorzeniona w historii OpenGL. Ważne jest, aby pamiętać, że dla większości wersji GL, które są tutaj istotne, OpenGL ewoluował stopniowo i poprzez dodanie nowej funkcjonalności do już istniejącego API zamiast zmiany API.
Pierwsza wersja OpenGL nie miała żadnego z tych typów obiektów. Rysowanie zostało osiągnięte poprzez wydanie wielu wywołań glBegin / glEnd, a jednym problemem z tym modelem było to, że był on bardzo nieefektywny pod względem narzutu wywołania funkcji.
OpenGL 1.1 podjął pierwsze kroki, aby rozwiązać ten problem, wprowadzając tablice wierzchołków. Zamiast bezpośrednio określać dane wierzchołków, możesz je teraz pozyskiwać z tablic C / C ++ - stąd nazwa. Tak więc tablica wierzchołków jest właśnie taka - tablica wierzchołków i stan GL wymagany do ich określenia.
Kolejna ważna ewolucja przyszła z GL 1.5 i pozwoliła na przechowywanie danych tablicy wierzchołków w pamięci GPU, a nie w pamięci systemowej („po stronie klienta”). Słabością specyfikacji tablicy wierzchołków GL 1.1 było to, że pełny zestaw danych wierzchołków musiał być przesyłany do GPU za każdym razem, gdy chciałeś z niego korzystać; jeśli był już na GPU, można tego transferu uniknąć i osiągnąć potencjalny wzrost wydajności.
Tak więc utworzono nowy typ obiektu GL, aby umożliwić przechowywanie tych danych na GPU. Podobnie jak obiekt tekstury służy do przechowywania danych tekstury, obiekt bufora wierzchołków przechowuje dane wierzchołków. W rzeczywistości jest to tylko szczególny przypadek bardziej ogólnego typu obiektu bufora, który może przechowywać nieswoiste dane.
Interfejs API do używania obiektów bufora wierzchołków został oparty na istniejącym już interfejsie API tablic wierzchołków, dlatego widzisz takie dziwne rzeczy, jak konwertowanie przesunięć bajtów na wskaźniki. Mamy teraz interfejs API tablic wierzchołków, który po prostu przechowuje stan, przy czym dane pochodzą z obiektów buforowych, a nie z tablic w pamięci.
To prowadzi nas prawie do końca naszej historii. Wynikowy interfejs API był dość gadatliwy, jeśli chodzi o określanie stanu tablicy wierzchołków, więc inną drogą optymalizacji było stworzenie nowego typu obiektu, który zgromadziłby cały ten stan razem, pozwolił na wiele zmian stanu tablicy wierzchołków w jednym wywołaniu API i pozwolił na GPU potencjalnie przeprowadzić optymalizacje ze względu na to, że z góry wiadomo, jaki stan będzie wykorzystany.
Wprowadź obiekt tablicy wierzchołków, który zbiera to wszystko razem.
Podsumowując, tablica wierzchołków rozpoczęła życie jako zbiór stanów i danych (przechowywanych w tablicy) do rysowania. Bufor wierzchołek zastępuje pamięci tablicy w pamięci z obiektów typu GL pozostawiając szereg wierzchołków prostu stanem. Obiekt tablicy wierzchołków jest po prostu obiektem kontenerowym dla tego stanu, umożliwiając jego łatwiejszą zmianę i mniej wywołań API.
char* buffer = socketRead();
(pseudokod). Z drugiej strony dziennik przechodzi przez cały cykl życia aplikacji. Więc gdzieś tworzysz tablicę i zaczynasz odczytywać gniazdo, za każdym razem, gdy dostajesz dane, które zapisujesz do tej porcji, dając ci uporządkowaną listę wszystkich otrzymanych danych.