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)

Prezentacja na temat: "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)"— Zapis prezentacji:

1

2 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) punktów-wierzchołków (vertices). 2.Rendering modelu odbywa się poprzez skierowanie do potoku graficznego sekwencji 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, (na ogół) NIE wykorzystuje się w tym celu – implementowanego we wcześniejszych (poniżej wersji 3.0) wersjach OpenGLa – trybu bezpośredniego:

3 1.Wierzchołki 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). 2.Jednakże, w odróżnieniu od wierzchołków matematycznych, oprócz położenia, wierzchołki graficzne 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. 3.Składowe tworzące wierzchołki graficzne określane są jako atrybuty wierzchołków (vertex attributes). 4.Każdy z wierzchołków danej sekwencji tworzącej model (lub jego część) zdefiniowany jest przez te same atrybuty, np.:

4 Sekwencja wierzchołków może być zorganizowana w pamięci (RAM, Video RAM, dysk twardy,...) na kilka sposobów: wszystkie dane (atrybuty) wierzchołków sekwencji umiejscowione są w jednym buforze (strumieniu) wierzchołków: dane każdego z rodzajów atrybutów wierzchołkó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. dla 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).

5 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 wierzchołków definiujących trójkąty skutkowałoby zatem (często wielokrotnym) powielaniem wierzchołków (i 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 wierzchołków pomiędzy CPU i GPU. W celu poradzenia sobie z problemem redundancji wierzchołków wykorzystuje się bufory indeksów:

6 Przekazywane do potoku graficznego sekwencje danych, które reprezentują wartości atrybutów kolejnych wierzchołków modelu, są strumieniami bajtów. Deklaracja wierzchołka (vertex declaration, vertex layout) jest wymaganym przez dane API, formalnym sposobem poinformowanie potoku o semantyce poszczególnych wartości atrybutów, ich typie oraz ich organizacji. W zależności od API, deklaracja wierzchołka dokonywana jest: albo w sposób jawny przy użyciu odpowiednich funkcji API dedykowanych temu celowi, albo 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, podczas gdy w OpenGL deklaracja wierzchołka uwikłana jest w przygotowanie procesu przesłania danych do karty graficznej.

7 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:

8 W OpenGL organizacja atrybutów wierzchołków deklarowana jest podczas przygotowywania procesu przesyłania danych do karty graficznej. W wersji OpenGL 3.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.1 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 (i następnie funkcji kojarzących dany atrybut z odpowiednią zmienną w shaderze wierzchołków – wykłady 8-9)

9 OpenGL w wersjach 1.12.x (OpenGL ES 1.x) udostępnia funkcjonalność indeksowanych tablic wierzchołków: gdzie przesyła strumień wierzchołkó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.

10 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).

11 W celu renderowania geometrii: bufory wierzchołków należy skojarzyć z odpowiednimi strumieniami określonymi w deklaracji wierzchołka (w D3X9 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 D3X9 metoda SetVertexDeclaration, w D3DX 10 i 11 IASetInputLayout ) wywołać polecenie przesłania wierzchołków do potoku graficznego (w D3DX9 metoda DrawIndexedPrimitive, w D3DX 10 i 11 DrawIndexed poprzedzona metodą IASetPrimitiveTopology )

12 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.

13 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 (oraz m.in. glEnableVertexAttribArray ). Dodatkowo wprowadzono nowy typ obiektu wspomagającego wykorzystywanie VBO, noszącego nazwę Vertex Array Object (VAO).

14 W przypadku wieloplatformowego 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ą 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 cache (cache 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)

15

16

17

18

19 1.zbuduj drzewo czwórkowe na podstawie prostopadłościanów AABB siatek składowych 2.dokonaj wstępnej selekcji siatek składowych względem bieżącej bryły widzenia wykorzystując utworzoną hierarchię

20

21

22