Steps3d - oktató - teszi a vertex buffer OpenGL

Mint ismeretes, az adatok átvitelét a CPU a GPU egy meglehetősen költséges művelet, ezért kívánatos, hogy minél kevesebb ilyen transzferek.

Azonban sok esetben szükség van a folyamatos átviteli nagy GPU vertex tömböket. Ez a helyzet akkor, ha van egy túl bonyolult törvény átalakítására adatok csúcsot (amely akár nem valósítható meg egy vertex shader, vagy nagyon drága, mind a sebesség), vagy ha van egy változás a topológia az objektum (változó csomópontok száma, a szervezetük a primitívek stb.)

Ilyen esetekben ez rendkívül kényelmes képes kialakítani az ilyen vertex tömbök közvetlenül a GPU. Akkor nem lenne szükség drága küld adatokat a CPU a GPU és az összes műveletet, melynek csúcsai végezni teljes egészében a GPU és a GPU.

Sajnos GPU (nem vesszük figyelembe SM4) lehet építeni maguknak csak a textúra - ez elég ahhoz, hogy az állományok kiterjesztése EXT_framebuffer_object. amely lehetővé teszi a megjelenítést közvetlenül a textúra. Ennek eredményeként tudjuk építeni közvetlenül a GPU textúra minden méret és formátum (támogatott GPU adatait, természetesen).

Azonban, ha jobban megnézed, nyilvánvalóvá válik, hogy a textúra eltér a vertex array egyetlen módja, hogy használja - és a textúra és vertex array tömb vektorok (1-4 dimenziós) egy adott típusú (beleértve a float).

Szóval csak azt kapja, amit meg kell, ha hozzá a képessége, hogy egyszerűen lemásolják a textúra (vagy annak egy részét) a vertex array (és lesz másolva a GPU memória, ami történik, nagyon nagy sebességgel).

Ez ezt a lehetőséget, és kiterjesztés és EXT_pixel_buffer_object ARB_pixel_buffer_object.

Ennek eredményeként az építési végezhetjük egy speciális textúra fragmens shader (textúra renderingeket, kívánatos ebben az esetben használható textúra -alkatrészek lebegőpontos), majd az így kapott adatokat egyszerűen másolja közvetlenül a vertex tömb.

Az ilyen módszer az úgynevezett a vertex tömb rendering (render-to-vertex-puffer).

Épület egy terep magassága térkép

Ennek első példaként vegyük konvertáló textúra, amely egy magassági térkép, egy sor csúcsok, ahol minden egyes texel textúra fog megfelelni egy csúcsot, z koordinátája, amely arányos a fényerő a pixel.

Ebben az esetben a töredék shader textúra alatt tartalmazni fog egy tömb csúcsok a táj által meghatározott eredeti magasságának térképen. Az építőiparban a táj, akkor át kell másolni az adatokat a textúra a megfelelő csúcstömbök és végrehajtja a megjelenítő.

Ennek eredményeként, a GPU közvetlenül minden egyes keret van kialakítva egy sor 256 2 csúcsok és elhagyása nélkül a korlátokat a GPU vertex tömb azonnal megjelenik.

Az alábbiakban egy kódrészlet épít egy sor csúcsok és az azt követő indexszel (a teljes kódot elérhető link végén a cikk).

Az egyszerűség kedvéért, továbbá a osztályok és framebuffer GlslProgram is használják VertexBuffer osztályban. leírása és megvalósítása, amelyek az alábbiakban adjuk meg.

Az alábbi ábra egy példa a kép (szín jelzésére használt pontok magasságát, hogy a mentesség jobban észrevehetőek).

1. ábra: A táj, melyek a magasságban a térkép.

Az alábbiakban fragment shader tételére textúra és teszi a kapott csúcstömbök.

Animált teszi a felületet

Egy másik példa, a használata render-to-texture rendering animált pillantást a vizet. Ahelyett, hogy a hagyományos használatát bump mapping „, és mi lesz a pályán építeni animált tömb csúcsok és merőlegesek a turbulencia (turbulencia), mint élő funkciót.

Nagyon kényelmes, hogy a lehetőséget, hogy teheti egyszer két textúrák (MRT, Multiple Render Targets) - egyetlen textúra csúcsainak koordinátáit mutatja, és egy másik - a normál vektor ezeken csúcsot.

Plus használata vertex buffer rendering ebben az esetben az a lehetőség, hogy működjön együtt a textúrák a számítás csúcsok (nem mindegyik támogatja a fellebbezést a GPU vertex textúra, és akkor is, ha ő támogatása általában normális szűrési mód nem áll rendelkezésre).

Az alábbi felsorolás olyan fragmens shader hogy használják, hogy megépíteni a csúcsokat, és merőlegesek a velük.

Tételére a felszíni vizet alkalmazunk következő fragmentum shader.

Miután egy kód-fragmenst, amely használt konstrukció tömbök csúcsok és merőlegesek, és kiadására a keletkező vizet.

Az alábbi ábrán az eredményül kapott vizet képet.

2. ábra Az a víz felszínén.

csontváz animáció

Egy másik példa, úgy a végrehajtása csontváz animáció modellek a játék Doom III révén teszi a vertex buffer.

Bár a legegyszerűbb esetekben, csontváz animáció is valósítható vertex programok ilyen végrehajtás csak akkor hatásos, egy nagyon kis számú csontok (ízületek beállítva), hogy a felső (1-2).

Ez annak a ténynek köszönhető, hogy minden csont meg kell adnia egy meglehetősen nagy mennyiségű adat. Bár ezek az adatok kerülnek a standard OpenGL vertex attribútumok már jól.

Azonban, amikor az összeg a csont, hogy a tetején 5 vagy több (és a modellek DooM III használjuk fel a tetejére 10 csont) továbbított minden egyes csúcsa adat nem kerül a OpenGL szabvány attribútumokat, és meg kell használni az általános formája vertex attribútumok (glVertexAttrib *).

Számuk is korlátozott, és ami még fontosabb, általában működik, standard OpenGL vertex attribútumok hatékonyabban (lásd a cikket az oldalon developer.nvidia.com pseudoinstancing OpenGL).

A nagy számú csúcsok a vertex program használatra csontváz animáció is vezet egy nagy terhelés vertex processzorok míg a feldolgozók fragmenst általában tovább optimalizált (és több).

Ezért a rendering a vertex buffer is sokkal kényelmesebb - minden vertex adatokat lehet elhelyezni a textúrák, a pozíciók kiszámításához a csúcsok által használt fragment processzorok és a csúcsok száma a modellben már nem túl nagy befolyása a teljesítmény (az csontváz animáció természetesen).

Először is, úgy, hogy milyen textúrákat van szükség, és milyen adatokat kell helyezni őket.

Először is, szükségünk van egy textúra, hogy tárolja az összes információt csontváz csontjai (jointsMap). Minden csontváz csontjai, meg kell emlékezni a tájolás (kvaterniócsoport, vagyis négydimenziós vektor), a pozíció (háromdimenziós vektor) és az index (száma), a szülő csont.

Könnyen belátható, hogy ez, ha használja a RGBA-textúrák lebegőpontos alkatrészek meg kell csak két texel a csont.

Mivel a csontok a váz általában egy kicsit, hogy könnyebb használni GL_TEXTURE_RECTANGLE_ARB típusú textúra (valamint minden egyéb textúrák kiszámításához használt csontrendszert animáció) 2-es méret * numJoints 1 texel.

Ebben az esetben a tartalmát a textúra változik az egyes frame animáció.

Is, mi kell két textúrák dolgozni csúcsot. Ezek közül az első (weightsMap) minden egyes tömeg fogja az eltolás (POS), a hozzájárulást a tömeg (súly), és az index a megfelelő csont (jointIndex).

Itt is szükség van két texel (az RGBA formátumban) per súly:

Mivel a méret a textúra is kényelmesen használható GL_TEXTURE_RECTANGLE_ARB, de mivel a súlyok száma is elég nagy, akkor jobb, ha meg egy kellően nagy textúra érték szélessége (például 512), és ki kell számítani a magassága a textúra röptében alapján az összes súlyokat a modellben.

Végül, meg kell egy textúra (vertexWeightsMap), amely minden egyes csomóponthoz tárolja két érték - száma az első súly (weightIndex) és az egymást követő súlyok (weightCount).

Itt kell csak egy texel a csúcsra.

Megjegyzendő, hogy a legtöbb modell DooM III tevődik össze több al-modellek (rendszerint társított kell használni a különböző árnyékolók különböző részein a modell).

A mi végrehajtása lesz nagyon kényelmes minden almodellek építeni egy közös adatok (azaz, textúra), és egy menetben animálni minden almodellek egyszerre. Elvileg egy ilyen megközelítés lehet továbbfejleszteni animált egy menetben egyszerre egy nagy csoport a modellek.

Az alábbi egy fragmens shader, amely végrehajtja csontváz animáció. Mivel GLSL nincs beépített támogatása négyes két alapműveleteket őket - a két kvaternió szorzás és forgatás a vektor segítségével kvaternió - készült két különálló feladat.

lehet letölteni a teljes forráskódot itt. Azt is letölthető a lefordított verziót M $ Windows-t. Linux és Mac OS X