játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5468
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2524

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2193
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] > 7 < [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [82]
syam - Törzstag | 1491 hsz       Online status #203942   2014.06.30 18:33 GMT+1 óra  
Igen, végre értelmes újdonságok kerülnek bele. A D3D12 párjának szánják.

Egyelőre csak tippelik milyen extensionök kerülnek be a coreba.
alias aalberik
   
Elodin - Tag | 180 hsz       Online status #203941   2014.06.30 18:07 GMT+1 óra  
Hol?

   
Geri - Törzstag | 2193 hsz       Online status #203940   2014.06.30 17:46 GMT+1 óra  
micsoda hiánypótló ._.'

   
syam - Törzstag | 1491 hsz       Online status #203939   2014.06.30 16:36 GMT+1 óra  
Jön az OpenGL 5 !
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #203042   2014.05.24 07:24 GMT+1 óra  
Ennek az emberkének a tapasztalatai azt mondják, hogy az általában nvidia kártyán gyorsabb (wtf?). Bár, ezzel csökkenne a CPU-oldali terheltség (nem kell ténylegesen áttranszformálni a vertexeket, csak kiszámolni a pozíciókat), illetve nem kellene dinamikus VBO sem.

Bár a paper alapján nem teljesen értem, hogy mennyivel jobb, mint uniformként átadni, mert per instance kellene rajzolni, amivel nem tudom mennyire vagyok előrébb...

Harmadik megoldásként esetleg: statikus VBO, a vertexdata állna továbbá egy ID-ból is, és a mátrixokat / pozíciókat uniform array-ként passzolnám át a shadernek. Az az adott vertexnél megindexeli a tömböt az ID alapján. Persze ennek vannak korlátai, például, hogy egy teljes arrayt kell átpaszírozni a GPU-nak, illetve ez a mennyiség limitált (ha jól rémlik nagyjából 60 mátrix mehet át egyszerre).

Ezt a hozzászólást Pretender módosította (2014.05.24 07:32 GMT+1 óra, ---)

   
syam - Törzstag | 1491 hsz       Online status #203041   2014.05.24 01:24 GMT+1 óra  
Persze. Pseudo-instancing.
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #203040   2014.05.23 22:53 GMT+1 óra  
Köszi! Ja-ja, nem egy nagy munka. Statikus tömb (vertexek), dinamikus vbo, és vertexek pozíciójának tologatásánál van jobb módszer is?

   
syam - Törzstag | 1491 hsz       Online status #203039   2014.05.23 21:17 GMT+1 óra  
Csakis batch.
A point mérete maximalizálva van és pixelben van megadva.

A vertex shader használatának egyik mintapéldája billboardot rajzolni
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #203037   2014.05.23 17:53 GMT+1 óra  
Point sprite-ot hogy érdemes megoldani? GL_POINTS-al rajzolni, és a "beépített" point-sprite-ot használni, vagy kézzel batchelni a kis négyzeteket?

szerk.:
Ahogy így olvasgattam kicsit, néhányan panaszkodtak rá, hogy itt-ott máshogy működik. Hát, nem tudom, igazából nem egy túl nagy meló megcsinálni a batchelést.

Ezt a hozzászólást Pretender módosította (2014.05.23 18:19 GMT+1 óra, ---)

   
glezmen - Törzstag | 381 hsz       Online status #203023   2014.05.22 15:51 GMT+1 óra  
Idézet
Pretender :
A cikk fele arról szólt, hogy azért kell más megoldást használni (lowlevel szint, direktben a kártyát csesztetni, API nélkül), mert nem működik rendesen az Ogl4 + Intel páros.


igy van, de ez nem az OpenGL hibaja (vagyis nem "nem tud Intelen mukodni" hanem az Intele, mert nem kepes egy normalis OpenGL drivert csinalni a vackaihoz
gondolom ebbol mar egyenesen kovetkezett, hogy ha nem kepes o maga OpenGL drivert irni a kartyaihoz, akkor legalabb alacsony szintu hozzaferest biztositson, hogy a (nem DX-es) fejlesztok tudjanak kezdeni valamit a hardware-rel
   
Geri - Törzstag | 2193 hsz       Online status #203021   2014.05.22 13:26 GMT+1 óra  
szerintem úgyis a szoftveres renderelés a jövő, ahhoz meg nem kell api

   
Pretender - Törzstag | 2498 hsz       Online status #203020   2014.05.22 12:58 GMT+1 óra  
A cikk fele arról szólt, hogy azért kell más megoldást használni (lowlevel szint, direktben a kártyát csesztetni, API nélkül), mert nem működik rendesen az Ogl4 + Intel páros. Na és akkor mi legyen a megoldás? Hát hagyjuk ki az Ogl-t. Oké, nyilván ez csak egy része az egésznek, de simán benne van (legalábbis nekem). Értem én, hogy nem (feltétlen) ez a fő mondanivaló, de akkor is az OpenGL tűnik "hibásnak", mert azt akarják kihagyni, és helyette valami mást használni. Aminek persze lennének egyéb előnyei (sebesség?) is valószínűleg, de akkor is.

szerk.:
Idézet
Ha kiindulunk abból, hogy az Epic tapasztalt programozóinak nagyjából másfél évre van szükségük ahhoz, hogy tényleg gyorsra és stabilra összerakják a modern OpenGL-t a legújabb Intel hardverekhez, akkor felmerül a kérdés, hogy gyorsabb lenne-e hagyni az OpenGL-t, és szimplán direkten leprogramozni az IGP-kre egy-egy leképzőt.

Persze az is más dolog, hogy ezt a játékfejlesztő cégek tehetnék meg, az Intel drivereket viszont nem tudják átírni. A fene vigye el az Intelt!

   
glezmen - Törzstag | 381 hsz       Online status #203019   2014.05.22 10:59 GMT+1 óra  
Idézet
Pretender :
Azért érdekes, hogy a cikk szavaiból az jön le, hogy az OpenGL egy hulladék, mert "nem megy" Intel kártyákon... értem én, hogy sok Intel van, de ha a többi driverrel működik, akkor nem lehet, hogy fordítva kellene a problémát megközelíteni, és az Inteleseket csesztetni, h tanuljanak meg programozni és szabványt betartani?



nem tudom ezt hogy sikerult leszurni belole, szerintem nagyon masrol szol a cikk
ha mar mindenaron opengl-intel vonalra akarod szukiteni, akkor inkabb annyi a mondanivalo, hogy az intel szarik az opengl-re, ezert a fejlesztok szopnak
   
Pretender - Törzstag | 2498 hsz       Online status #203018   2014.05.22 10:37 GMT+1 óra  
Azért érdekes, hogy a cikk szavaiból az jön le, hogy az OpenGL egy hulladék, mert "nem megy" Intel kártyákon... értem én, hogy sok Intel van, de ha a többi driverrel működik, akkor nem lehet, hogy fordítva kellene a problémát megközelíteni, és az Inteleseket csesztetni, h tanuljanak meg programozni és szabványt betartani?

   
glezmen - Törzstag | 381 hsz       Online status #203017   2014.05.22 09:44 GMT+1 óra  
Geri - Törzstag | 2193 hsz       Online status #203015   2014.05.22 02:30 GMT+1 óra  
Idézet
Pretender :
Valami halvány emlékem mintha lenne arról, hogy háromszögenként renderelni a legoptimálisabb bizonyos driverek esetében, de simán lehet, hogy nem így van. Nagyon régről rémlik valami, és nagyon homályosan.



erről én írtam cikket még 2006-ban, és védtem erősen ezt az álláspontot. feltehetően ez ma is így van.

   
Pretender - Törzstag | 2498 hsz       Online status #202969   2014.05.17 16:18 GMT+1 óra  
Igen, mindig újra be kell állítani.

Ha nem adsz meg indexbuffert, akkor a vertex bufferbe való feltöltés sorrendjét veszi kirajzoláskor. Az meg, hogy milyen primitívnek tekinti, te adod meg rajzoláskor. (GL_TRIANGLES, stb.)

szerk.:
Viszont, ha háromszögenként renderelsz quadot, akkor van vertex ismétlődés. Miért nem jó az indexbuffer?

Valami halvány emlékem mintha lenne arról, hogy háromszögenként renderelni a legoptimálisabb bizonyos driverek esetében, de simán lehet, hogy nem így van. Nagyon régről rémlik valami, és nagyon homályosan.

   
Elodin - Tag | 180 hsz       Online status #202967   2014.05.17 14:54 GMT+1 óra  
Kösz!
Utólag belegondolva még ha csak egy stringből rész-stringet keresne is fölösleges hülyeség, nem volt vmi. értelmes kérdés


A másik még mindig áll: ha felváltva használok különböző shaderprogikat, akkor a uniformok értéke váltások után marad, vagy mindig újra kell tölteni? (Ha marad, akkor csak változáskor állítanám át, ha nem, akkor nyilván minden rajzolás előtt).

Még egy kérdés:

Quadokat hogy érdemes rajzolni? Biztos, hogy nincs vertex ismétlődés... ilyenkor is index buffer, vertexbuffer, vagy van vmi mód, hogy indexbuffer nélkül simán 0,1,2,3 sorrendben nézze a vertexeket?

Háromszögekben érdemes gondolkodni, vagy ha átállítok vmi opengl beállítást, akkor lehet négyszögként is értelmezni a vertexeket saját shader esetén is?

   
Geri - Törzstag | 2193 hsz       Online status #202965   2014.05.17 13:54 GMT+1 óra  
bármely opengl függvény basztatása legjobb esetben is kb 100x annyi órajel nagyságrendjét tekintve, mint kiolvasni egy egyszerű változót a memóriából.

   
Elodin - Tag | 180 hsz       Online status #202964   2014.05.17 13:36 GMT+1 óra  
A uniform változók értékét mindig be kell állítani, ha közben más shaderprogramot használtam, vagy az marad, ha egyszer már beállítottam?

A uniform location lekérése mennyire költséges? Érdemes egyszer lekérni, és megjegyezni, vagy mehet minden hívásnál?

   
Pretender - Törzstag | 2498 hsz       Online status #202590   2014.04.15 07:04 GMT+1 óra  
Mármint az ibo bindelés hiánya volt a hiba? Ha igen, az úgy elég kemény, mert általában furábban szokott ilyenkor kinézni a modell.

   
syam - Törzstag | 1491 hsz       Online status #202584   2014.04.14 22:28 GMT+1 óra  
Ez olyan facepalm-OS, nem?
alias aalberik
   
Elodin - Tag | 180 hsz       Online status #202577   2014.04.14 21:19 GMT+1 óra  
Egyébként illene. Olyannyira, hogy az volt a hiba

Azért nézegettem egy darabig az assimp-os részeket, meg az assimp flag-ekkel is játszadoztam, nem gondoltam volna, hogy itt lesz a gond.

Amúgy ott volt az, csak véletlenül kommentbe került egy jelenleg még használaton kívüli kódrészlettel együtt.

   
Pretender - Törzstag | 2498 hsz       Online status #202546   2014.04.14 16:22 GMT+1 óra  
Egyébként rajzoláskor nem kell az indexbuffert is bindolni? Mármint ez nem lehet a probléma, mert akkor más sem lenne igazán jó, csak kérdezem.

   
syam - Törzstag | 1491 hsz       Online status #202541   2014.04.14 16:03 GMT+1 óra  
Gondolom az IBO mindenhol rendesen be van kötve csak lemaradt az idézetből
Még meg lehetne nézni a Blender oldali mesh statisztikát és azt amit renderelsz.
Háromszög-szám ill. vertex-szám.
Gyanús, h assimp csinál vmit furcsán. Esetleg csinál vertex cache optim.-t?

Esetleg csontanimálva van a modell?
alias aalberik
   
Elodin - Tag | 180 hsz       Online status #202540   2014.04.14 15:57 GMT+1 óra  
Külön.

Kód:
class ShadedMesh
{
private:
    std::vector<Mesh> mMeshes;
...

class Mesh
{
private:
    GLuint mVB;
    GLuint mIB;
    unsigned int mNumIndices;
...

   
syam - Törzstag | 1491 hsz       Online status #202538   2014.04.14 15:53 GMT+1 óra  
Egy közös VBO + IBO-ba töltöd fel a mesheket vagy minden meshnek külön VBO + IBO-ja van?
alias aalberik
   
Elodin - Tag | 180 hsz       Online status #202533   2014.04.14 15:23 GMT+1 óra  
Biztos, hogy nincs túlcsordulás. Több mesh-ből áll a modell, és 5000 körüli a legnagyobb indexszám is.

Bufferek létrehozása egy mesh-re:

Kód:
void Mesh::init(const std::vector<Vertex>& vertices,
                 const std::vector<unsigned int>& indices)
{
    mNumIndices = indices.size();
    glGenBuffers(1, &mVB);
    glBindBuffer(GL_ARRAY_BUFFER, mVB);
    glBufferData(GL_ARRAY_BUFFER, sizeof(Vertex)* vertices.size(),
                 &vertices[0], GL_STATIC_DRAW);

    glGenBuffers(1, &mIB);
    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, mIB);
    glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(unsigned int)* mNumIndices,
                 &indices[0], GL_STATIC_DRAW);
}


Vertex és index listák kiszedése az importerből:

Kód:
ShadedMesh::ShadedMesh(std::string name, const aiScene* scene)
{
    mName = name;
    mMeshes.resize(scene->mNumMeshes);

    for (unsigned int i = 0; i < mMeshes.size(); i++)
    {
        const aiMesh* mesh = scene->mMeshes[i];

        std::vector<Vertex> vertices;
        std::vector<unsigned int> indices;

        for (unsigned int i = 0; i < mesh->mNumVertices; i++)
        {
            const aiVector3D* pPos = &(mesh->mVertices[i]);
            const aiVector3D* pNormal = &(mesh->mNormals[i]);
       

            Vertex v(Math::float3(pPos->x, pPos->y, pPos->z),
                Math::float3(pNormal->x, pNormal->y, pNormal->z));

            vertices.push_back(v);
        }
        for (unsigned int i = 0; i < mesh->mNumFaces; i++)
        {
            const aiFace& Face = mesh->mFaces[i];
            assert(Face.mNumIndices == 3);
            indices.push_back(Face.mIndices[0]);
            indices.push_back(Face.mIndices[1]);
            indices.push_back(Face.mIndices[2]);
        }

        mMeshes[i].init(vertices, indices);
    } //meshes iteration

} //Model construktor


Egy mesh kirajzolása:

Kód:
glBindBuffer(GL_ARRAY_BUFFER, mVB);
    glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE,
        sizeof(Vertex), 0);
   
    glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE,
        sizeof(Vertex), (const GLvoid*)sizeof(Math::float3));

    glDrawElements(GL_TRIANGLES, mNumIndices, GL_UNSIGNED_INT, 0);

   
Pretender - Törzstag | 2498 hsz       Online status #202506   2014.04.13 23:23 GMT+1 óra  
Bár elég valószínűtlen, de nem lehetséges, hogy több, mint 2^16 = 65536 vertex van, amit meg kell indexelni? Mert ha igen, és netán GL_UNSIGNED_SHORT (vagy nem is tudom hirtelen fejből a nevét) típusú indexeket használsz, akkor az a baj. Ha viszont nem így van, akkor lehet, hogy az importer a rossz. Esetleg a draw-nál nem jó elemszám van megadva, ezért csak egy részét rajzolja ki. Esetleg egy VBO feltöltés + rajzolás (+ esetleg importálás) kódot, ha feltöltesz, lehet, hogy elbújt ott valami huncutság...

szerk.:
Áh, látom, syam megelőzött...

   
syam - Törzstag | 1491 hsz       Online status #202505   2014.04.13 23:21 GMT+1 óra  
Vertex indexelési problémának tűnik.
Importkor lehet, hogy uint16-ban indexel viszont túl sok hozzá a vertex.
alias aalberik
   
Elodin - Tag | 180 hsz       Online status #202504   2014.04.13 22:25 GMT+1 óra  
Blenderben így néz ki egy modell, amit megpróbálok beimportálni Assimp segítségével.

Ez az eredmény.

Másik modellt probléma nélkül betölt. Bármi ötlet, hogy hol lehet a gond?

   
Pretender - Törzstag | 2498 hsz       Online status #202425   2014.04.10 20:35 GMT+1 óra  
Nahát, erre még igazából nem is gondoltam, pedig nem rossz ötlet. Eddig csak specifikus shadereket írtam meg, legfeljebb a statikus / animált vertex shaderek voltak egyben és define-okkal megoldva.

Ezt a dolgot akár úgy is meg lehet oldani, hogy van egy übershaderje az embernek, tele ifdefekkel, így a bejövő paraméterek függvényében készül el runtime a shaderkód, amit aztán lefordít.

   
syam - Törzstag | 1491 hsz       Online status #202422   2014.04.10 20:27 GMT+1 óra  
Mindenképp kell vmiféle shader-rendszer.
Legjobb ha "surface shadert" készítesz, ami úgy is tudsz paraméterezni, hogy "érdes, kék, fém".
De ha simán modulárisan, pipeline-szerűen építed fel az is nyerő nagyon.
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #202419   2014.04.10 20:12 GMT+1 óra  
Hát ez pedig ilyen. Nem egy nagy effort. Először nekem is kicsit fura volt, dx-ben anno teljesen manuálisan csináltam. Beállítottam a vertex shadert meg a pixel shadert külön-külön, így nem volt mindig muszáj váltani. Viszont hidd el, ha van egy jó kis rendszer rá, akkor sokkal követhetőbb így a dolog. Ráadásul nem olyan nagy effort shadert váltani.

Nálam pl. így néz ki egy shaderes rajzolás:
Kód:
shader->begin();
shader->setXY(locXY, value);
draw();
shader->end();


Sokkal zavaróbb tud lenni, hogy egyáltalán semmi helper funkció nincs a shaderekhez. Azaz a define-olást és include-olást is kézzel kell megírnod. Persze nem egy nagy dolog, string-beszúrás az egész, de akkor is...

   
Elodin - Tag | 180 hsz       Online status #202417   2014.04.10 20:05 GMT+1 óra  
Hát igen. Mondjuk amíg nem kell a scale, addig nem lehet probléma.
Ha eljutok odáig, lemérem a teljesítménykülönbséget, és lehet kiszedem én is

Ha más nem, ha vminek kell scale, akkor külön írok rá shader-t

Mondjuk már most is bosszant, hogy a shadereket egybe kell fordítani.
Amit tervezek, annál pl. az van, hogy sok vertexshaderhez két különböző pixelshader is tartozni fog. Mindegyik külön program

   
Pretender - Törzstag | 2498 hsz       Online status #202415   2014.04.10 19:43 GMT+1 óra  

Az a lényeg, hogy megvan. Egyébként lehet, hogy ezzel jól meg fogom szívni egyszer, mert én a mai napig a "sima" world mátrixot használom. Nem igazán tartom szerencsésnek mindig kiszámolni az összes inverzét, az animált modellekről nem is beszélve... Minden egyes animált modell minden egyes csontjához tartozó mátrix inverzét számolgatni / frame...

   
Elodin - Tag | 180 hsz       Online status #202414   2014.04.10 19:22 GMT+1 óra  
Kösz a segítséget!

Ilyenkor érzem nagy szerencsétlennek magam

Totál más volt a hiba: a hátsólapeldobásból elsőlapeldobás lett.

   
Pretender - Törzstag | 2498 hsz       Online status #202411   2014.04.10 18:49 GMT+1 óra  
Én is "directx-es" mátrixokat használok opengl renderelővel, ahogy tapasztaltad is annyi a megoldás, hogy matrix * vertpos (hlsl-ben pedig mul(vertpos, matrix)) lesz a sorrend.

Normáloknál pedig a world inverse transpose-al kell szorozni. Viszont, ha jól rémlik, a transzponáltról annyit kell tudni, hogy:
A * v = v * AT
(ahol AT az A mátrix transzponáltja).

A sorrendet ennek figyelembe vételével határozd meg. Azaz ha csak sima inverzed van, akkor cseréld meg a szorzás sorrendjét, hogy jó legyen. Egyébként meg gyorsan ki tudod deríteni, ha a fragment shaderben kiíratod a normalt, mint színt.

Egyébként első körben megpróbálhatod a (world * normal)-t, és azzal számolni. Csak bizonyos transzformációknál okozhat ez a számítás hibát (tipikusan a nem egységes skálázáskor). Ha azzal sem jó a megvilágítás, akkor máshol van a gond.

Konkrét kód esetén többet lehet mondani.

   
Elodin - Tag | 180 hsz       Online status #202409   2014.04.10 18:34 GMT+1 óra  
Adottak voltak egy kicsi és jó matek és kamera "könyvtár" forrásfájljai egy directx-es projectből, király makrókkal, meg minden segédfüggvénnyel, ami a 3d-s grafhoz csak kellhet.

Aztán miután megdöbbenve tapasztaltam, hogy bizonyos irányú mozgatás helyett forog a kép, és nagyon furán nyúlik a betöltött modell... mint kiderült, arra nem gondoltam, hogy az opengl és a directx különböző koordinátarendszerei ennyire bekavarnak.
Végül segítséggel azt a megoldást választottam, hogy a shaderben a vertex poziciójának számításakor felcseréltem a sorrendet:
pos = vektor * transmatrix helyett pos = transmatrix * vektor formába.
Ez megoldotta a gondot.

A normálvektorokat is úgy próbáltam meghatározni: amikor az inverzmátrix-al szorzom őket, ott felcseréltem az inverzmátrixot és a normálvektort. Viszont a színekből ítélve a normálok nem úgy vannak, ahogy lenniük kéne. Okozhatja ez a hibát, vagy máshol keressem?

Biztos ki tudnám matekozni igazából, csak sajnálom rá az időt
Ha valaki vágja a témát, és tud válaszolni a kérdésre, azt megköszönném!

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #202214   2014.03.27 10:08 GMT+1 óra  
Idézet
Eldor :
A glValidateProgram(..) nem a shader helyességét ellenőrzi, hanem azt, hogy helyesen vannak-e beállítva az állapotok (pl.: uniformok, attribútomok) az adott környezetben.

Jogos Kicsit fáradt voltam már, bekavartam a dolgot
Dare to imagine!
http://www.insaneidea.hu
   
Eldor - Tag | 163 hsz       Online status #202190   2014.03.26 08:02 GMT+1 óra  
Idézet
MaNiAc :
Idézet
Eldor :
Szia!

A glValidateProgram(..) függvénnyel is megnézted? Nálam már volt rá példa, hogy fordult és minden jónak tűnt, mégis a validate hibát jelzett.

Azt írta, hogy az alap triangle-re működött a shader, szóval a shaderes rész kizárható. Szerintem a VAO-val/VBO-val lesz a bibi...



A glValidateProgram(..) nem a shader helyességét ellenőrzi, hanem azt, hogy helyesen vannak-e beállítva az állapotok (pl.: uniformok, attribútomok) az adott környezetben.

   
Elodin - Tag | 180 hsz       Online status #202189   2014.03.25 23:25 GMT+1 óra  
Műkszik mostmár királyul.
GlBindAttribLocation mindjárt pótlásra kerül.
Úgyis most szórakozok kicsit a shaderekkel: uniform változók, mvp mátrix, vmi alap árnyalás, miegymás.

   
syam - Törzstag | 1491 hsz       Online status #202188   2014.03.25 23:04 GMT+1 óra  
Az attrib location kezelés hiánya elég veszélyes.
Ati driverek szokták azt csinálni, hogy nem a generikus sorrendben várják az attribokat így pl. a pozíciót nem a 0. csatornán várja, hanem mondjuk a normál csatornáján. Ilyenkor lesz minden meshből gömb és az embernek pedig wtf érzése
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #202187   2014.03.25 22:38 GMT+1 óra  
Idézet
Elodin :
GlBindAttribLocation nincs, de ez a háromszögnél sem okozott problémát...


Erre nem érdemes hagyatkozni Legyen.
Egyébként most akkor jó, vagy nem? Kicsit nehezen követem. Ha nem jó, esetleg a cull mode NONE-on? Lehet, hogy a háromszöget kézzel CW-ben adtad meg, de a modell CCW-ben van.

   
Elodin - Tag | 180 hsz       Online status #202186   2014.03.25 22:04 GMT+1 óra  
Enable volt, csak kimaradt egy köztes függvény, bocs.

Kód:
void Model::render()
{
    glEnableVertexAttribArray(0);
    glEnableVertexAttribArray(1);
    glEnableVertexAttribArray(2);
    for (unsigned int i = 0; i < mMeshes.size(); i++)
    {
        mMeshes[i].render();
    }
    glDisableVertexAttribArray(0);
    glDisableVertexAttribArray(1);
    glDisableVertexAttribArray(2);
}



Szerk.:

glVertexAttribPointer() átírását vhogy nem sikerült mentenem, vagy nem tudom
Azóta egykét dolgot még kijavítottam, és nézem, hogy ez megint rossz. Ismét kijavítottam, és ezúttal megy a dolog.

Kösz a segítséget, a progit meg különösen... szerintem nagy hasznomra lesz még.

GlBindAttribLocation nincs, de ez a háromszögnél sem okozott problémát...

Ezt a hozzászólást Elodin módosította (2014.03.25 22:25 GMT+1 óra, ---)

   
syam - Törzstag | 1491 hsz       Online status #202185   2014.03.25 21:36 GMT+1 óra  
glEnableVertexAttribArray merre van?
Shader-kezeléskor van glbindattriblocation?
alias aalberik
   
Elodin - Tag | 180 hsz       Online status #202184   2014.03.25 20:31 GMT+1 óra  
Kösz!

Első körben én is a VBO-ra gyanakodtam, aztán ellenőriztem az általad ajánlott programmal.
Szerinte rendbe vannak: az index és a vertex buffer is pont úgy néz ki, mint kéne neki.

A kirajzolás kódja így néz ki jelenleg:

Kód:
glClearColor(0.1f, 0.2f, 0.3f, 1.0f);
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

   GraphEn::graphEn.getTechnique("basic")->enable();

   Model* m = GraphEn::graphEn.getModelByName("giraffe");
   if (m) m->render();

    glutSwapBuffers();


A meghívott render függvény:

Kód:
   
glBindBuffer(GL_ARRAY_BUFFER, mVB);
    glVertexAttribPointer(0, sizeof(Math::float3), GL_FLOAT, GL_FALSE,
        sizeof(Vertex), 0);

    glVertexAttribPointer(1, sizeof(Math::float2), GL_FLOAT, GL_FALSE,
        sizeof(Vertex), (const GLvoid*)sizeof(Math::float3));
    glVertexAttribPointer(2, sizeof(Math::float3), GL_FLOAT, GL_FALSE,
        sizeof(Vertex),
        (const GLvoid*) (sizeof(Math::float3) + sizeof(Math::float2)));
    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, mIB);
    glDrawElements(GL_TRIANGLES, mNumIndices, GL_UNSIGNED_INT, 0);


Sehol nincs error, minden fv meghívódik, aminek meg kell. A kép a clearert szín.

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #202183   2014.03.25 20:00 GMT+1 óra  
Idézet
Eldor :
Szia!

A glValidateProgram(..) függvénnyel is megnézted? Nálam már volt rá példa, hogy fordult és minden jónak tűnt, mégis a validate hibát jelzett.

Azt írta, hogy az alap triangle-re működött a shader, szóval a shaderes rész kizárható. Szerintem a VAO-val/VBO-val lesz a bibi...
Dare to imagine!
http://www.insaneidea.hu
   
Eldor - Tag | 163 hsz       Online status #202181   2014.03.25 19:57 GMT+1 óra  
Szia!

A glValidateProgram(..) függvénnyel is megnézted? Nálam már volt rá példa, hogy fordult és minden jónak tűnt, mégis a validate hibát jelzett.

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #202180   2014.03.25 19:50 GMT+1 óra  
gDebugger nevű progi nekem bejött, ha ilyesmire gondoltál.

Esetleg ha gondolod, dobd be ide a VAO tartalmát megjelenítő kódot, aztán ránézünk.
Dare to imagine!
http://www.insaneidea.hu
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] > 7 < [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [82]