Wykład 5. Rendering (2) Geometria
1. Z ogólnego, niezależnego od implementacji punktu widzenia, dane stanowiące opis geometrii modelu zorganizowane są w skończoną sekwencję (lub grupę sekwencji), którego elementami są wierzchołki (vertices). 2. Wizualizacja (rendering) modelu odbywa się poprzez skierowanie do potoku graficznego sekwnecji wierzchołków reprezentujących model. 3. W aplikacjach graficznych czasu rzeczywistego (np. grach) dąży się do przekazywania danych geometrycznych do potoku graficznego w jak największych paczkach (batches), przy użyciu jak najmniejszej liczby wywołań funkcji API. 4. W szczególności, NIE wykorzystuje się w tym celu implementowanego we wcześniejszych wersjach OpenGLa trybu bezpośredniego:
1. W celu odróżnienia od wierzchołków w sensie matematycznym, wierzchołki definiujące geometrię dla celów renderingu będziemy nazywali wierzchołkami graficznymi lub werteksami. 2. Werteksy są przede wszystkim nośnikami informacji o położeniu tworzących model punktów (zwykle rozważanych właśnie jako wierzchołki siatki trójkątów tworzących powierzchnię modelu, często w układzie współrzędnych modelu). 3. Jednakże, w odróżnieniu od wierzchołków matematycznych, oprócz położenia, werteksy zawierają zwykle dodatkową informację wykorzystywaną przez potok graficzny np. kolor punktu, wektor normalny w punkcie, współrzędne tekstur definiujące odwzorowanie tekstury (lub tekstur) na powierzchnię modelu, etc. 4. Składowe tworzące wierzchołki graficzne określane są jako atrybuty wierzchołków (vertex attributes). 5. Każdy z werteksów danej sekwencji tworzącej model (lub jego część) zdefiniowany jest przez te same atrybuty, np.:
Sekwencja werteksów może być zorganizowana w pamięci (RAM, Video RAM, dysk twardy,...) na kilka sposobów: wszystkie dane (atrybuty) werteksów sekwencji umiejscowione są w jednym buforze (strumieniu) wierzchołków: dane każdego z rodzajów atrybutów werteksów znajdują się w odrębnym buforze (strumieniu): reprezentacje pośrednie (dane poszczególnych atrybutów rozdzielone są pomiędzy 2 lub więcej buforów) Sposób zorganizowania ma znaczenie m.in. w zagadnieniu wydajności operacji odczytu i zapisu danych z/do bufora wierzchołków dokonywanych przez CPU, gdy bufor przechowywany jest w pamięci karty graficznej (Video RAM).
W siatkach trójkątów większość wierzchołków jest współdzielonych przez 2 lub więcej trójkątów: Reprezentowanie siatki trójkątów wyłącznie za pomocą ciągu trójek werteksów definiujących trójkąty skutkowałoby zatem (często wielokrotnym) powielaniem werteksów (a więc wartości ich atrybutów). To, z kolei, pociągałoby nie tylko marnowanie zasobów pamięciowych (w szczególności VRAM), ale także marnowanie przepustowości łącza podczas przesyłania werteksów pomiędzy CPU i GPU. W celu poradzenia sobie z w/w problemem redundancji werteksów wykorzystuje się bufory indeksów:
Przekazywane do potoku graficznego sekwencje danych, które reprezentują wartości atrybutów kolejnych werteksów modelu, są strumieniami bajtów. Deklaracja wierzchołka (vertex declaration, vertex layout) jest wymaganym przez dane API, formalnym sposobem poinformowanie potoku o semantyce (znaczeniu w sensie rodzaju atrybutu) poszczególnych wartości, ich typie oraz ich organizacji. W zależności od API, deklaracja wierzchołka dokonywana jest: albo explicite (w sposób jawny) przy użyciu odpowiednich funkcji API dedykowanych temu celowi, albo implicite (niejawnie) w trakcie formatowania operacji przesłania atrybutów werteksów do karty graficznej. W DirectX mamy do czynienia z jawnym sposobem deklarowania wierzchołka (deklaracja explicite), podczas gdy OpenGL deklaracja wierzchołka uwikłana jest w przygotowanie procesu przesłania danych do karty graficznej (deklaracja implicite).
W D3DX 9 (w D3DX 10 i 11 analogicznie) każdy z atrybutów opisany jest strukturą: Np. deklaracja wierzchołka może mieć postać: Utworzenie interfejsu deklaracji wierzchołka oraz poinformowanie potoku o aktualnej deklaracji odbywa się poprzez wywołanie metod:
W OpenGL organizacja atrybutów werteksów deklarowana jest niejawnie podczas przygotowywania procesu przesyłania danych do karty graficznej. W wersji OpenGL 2.0 (i wcześniejszych) oraz OpenGL ES 1.x wykorzystuje się w tym celu m.in. funkcje glvertexpointer, glcolorpointer, glnormalpointer, gltexcoordpointer, np.: łącznie z funkcjami glenableclientstate(glenum array) aktywującymi odpowiednie tablice (strumienie) atrybutów, np: Począwszy od wersji OpenGL 3.0 oraz OpenGL ES 2.0, w których usunięto stały potok graficzny, odpowiednia deklaracja atrybutów wierzchołków odbywa przy użyciu funkcji glvertexattribpointer.
OpenGL w wersjach 1.1 2.x (OpenGL ES 1.x) udostępnia funkcjonalność indeksowanych tablic wierzchołków: gdzie przesyła strumień werteksów do potoku graficznego. Wadą tablic wierzchołków jest to, że są przechowywane po stronie CPU i w celu renderingu za każdym razem muszą być przesyłane do karty graficznej.
Bufory wierzchołków i indeksów stosowane w DirectX nie posiadają wskazanej wady tablic wierzchołków OpenGL, bowiem bufory te mogą egzystować bezpośrednio w pamięci VRAM karty graficznej. 1. W D3DX 9 (podobnie w D3DX 10 i 11) bufory wierzchołków tworzy się za pomocą metody: Analogicznie, bufory indeksów tworzy się przy wykorzystaniu metody CreateIndexBuffer o podobnych parametrach. 2. W celu wypełnienia bufora danymi (ew. odczytu danych) należy otrzymać do niego wskaźnik wywołując metodę Lock (odpowiednio Map w D3DX 10 i 11), a następnie po wypełnieniu bufor odblokować wywołując metodę Unlock (odpowiednio Unmap w D3DX 10 i 11).
W celu renderowania geometrii: bufory wierzchołków (a dokładniej: atrybutów) należy skojarzyć z odpowiednimi strumieniami określonymi w deklaracji wierzchołka (w DX 9 metoda SetStreamSource, w D3DX 10 i 11 metoda IASetVertexBuffers) skojarzyć z potokiem bufor indeksów (w D3DX 9 metoda SetIndices, w D3DX 10 i 11 SetIndexBuffer) poinformować potok o bieżącej deklaracji wierzchołka (w DX 9 metoda SetVertexDeclaration, w D3DX 10 i 11 IASetInputLayout) wywołać polecenie przesłania werteksów do potoku graficznego (w DX 9 metoda DrawIndexedPrimitive, w D3DX 10 i 11 DrawIndexed poprzedzona metodą IASetPrimitiveTopolgy)
W celu realizowania funkcjonalności analogicznej do buforów wierzchołków DirectX, w OpenGL w wersji 1.5 wprowadzono obiekty buforowe (object buffers) umożliwiające przechowywanie tablic wierzchołków i indeksów bezpośrednio w pamięci karty graficznej (Video RAM). tworzenie obiektu buforowego indeksowanej tablicy wierzchołków w celu zmiany zawartości (ew. odczytu) utworzonego obiektu buforowego należy (podobnie jak w DirectX) otrzymać do niego wskaźnik (funkcja glmapbuffer), a następnie bufor odblokować (glunmapbuffer). Funkcja glbuffersubdata pozwala zapisać dane do dowiązanego bufora bez odwzorowywania go w RAM.
Począwszy od wersji OpenGL 3.0 (OpenGL ES 2.0) zrezygnowano z obiektów buforowych tablic wierzchołków znanych z poprzednich wersji i w ich miejsce wprowadzono po prostu obiekty buforów wierzchołków (vertex buffer object - VBO). Obiekty te używa się w niemalże identyczny sposób. Jedna z głównych różnic to ta, że w miejsce wywołań wycofanych funkcji: glenableclientstate i deklaracji atrybutów wierzchołka glvertexpointer, glnormalpointer, etc., wykorzystuje się funkcję ogólną glvertexattribpointer. Dodatkowo wprowadzono nowy typ obiektu wspomagającego wykorzystwanie VBO, noszącego nazwę Vertex Array Object (VAO).
W przypadku multi-platformowego silnika graficznego należy: 1. stworzyć, niezależną od API graficznego, klasę (być może szablonową) reprezentujący bufory wierzchołków/indeksów i działania na nich, której 2. metody interfejsu obudowują (wrapping) implementacje stosowane w konkretnych API graficznych 3. same zaś implementacje dla danego API należy dostarczyć w pliku implementacyjnym Nadto: 4. mając na uwadze wydajność kodu, należy starać się unikać stosowania funkcji wirtualnych (szczególnie wywoływania takich funkcji w wykonywanych wielokrotnie pętlach); koszt wywołania funkcji wirtualnej jest często dużo większy od wywołania zwykłej funkcji z powodu zjawiska chybiania w cash (cash misses) 5. należy pamiętać o tym, że pomimo, iż na danej platformie mogą działać różne API graficzne (np. na PC), to jednak wersja release gry będzie wykorzystywała tylko jedno z nich (dlatego m.in. nie ma sensu aby kod wynikowy zawierał implementacje dla API niewykorzystywanych)