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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2188
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
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]
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 | 2188 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 | 173 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 | 2188 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 | 173 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 | 173 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 | 173 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 | 173 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 | 173 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 | 173 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 | 173 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 | 173 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 | 173 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 | 173 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 | 173 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
   
Elodin - Tag | 173 hsz       Online status #202179   2014.03.25 19:21 GMT+1 óra  
Van vmi trükk/tool opengl debuggolásra?

Egyszerűen annyit csinálok, hogy betöltök egy modellt, annak a koordinátái a (-1,1) intervallumba esnek, és megpróbálom kirajzolni minden extra nélkül. Saját shadert használok, ami jelenleg nem csinál semmit gyakorlatilag (bemenetet továbbadja a vertex shader, a pixel shader meg konstans színt ad, háromszögre működött is). Amennyire c++ oldalról látom, minden rendben van... viszont nem rajzolódik semmi.


Szerk.: közben sikerült kicsit javítanom a dolgon. glGetError() segítségével rájöttem, hogy rosszul paramétereztem a glVertexAttribPointer() fv-t. Ezt ki is javítottam, most már nem is kapok errort... de ugyanúgy nem rajzol semmit ; (

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

   
Geri - Törzstag | 2188 hsz       Online status #202151   2014.03.23 00:27 GMT+1 óra  
a webgl úgyis randomra elszáll alóluk pár frame után, mert a webfejlesztők szerencsére ezt sem bírták rendesen megoldani.

   
Parallax - Tag | 581 hsz       Online status #202144   2014.03.22 05:18 GMT+1 óra  
Idézet
versio :
en csak azert emlitettem meg, mert en is agyfaszt kaptam a forditasi idoktol windows metrora programozva, soha nem ternek vissza se windowsra se c++-ra, nem ment el az eszem


Ha nálad az a fejlesztés, hogy átírsz valamit, aztán lefordítod, a fordító kidobja a módosításból adódó esetleges hibákat és így tovább, akkor nem a C++ a hibás. Egyébként meg az /MP kapcsoló csodákra képes.

A másik, hogy manapság zömében annyira egyszerű játékok vannak és a fejlesztői eszközök, annyira modernek, hogy nincs is értelme egy nagy és bonyolult engine és a hozzá tartozó infrastruktúra használatát hónapokig tanulni. Egyszerűbb pár nap/hét alatt öszerkani a játékot OpenGL-el és a megfelelő platform specifikus részeket a platformokhoz tartozó SDK-val. Erre már rájöttek az engine fejlesztő cégek is és már szinte ingyen csinálhat az engine-el bárki bármit, ha ágyúval akar hangyára lőni.

Az a kevés cég, aki AAA-ra játszik pedig van annyira pro, hogy nem más kreálmányával heggeszt contenteket, hanem szintén megírja a motort magának.

Utolsó kapaszkodójuk az engine gyárosoknak a webfejlesztők, hátha bekajálják a motorjukat és a C++ ból generált js-el majd összegányolnak valamit, amire maguktól nem képesek.

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #202141   2014.03.21 18:52 GMT+1 óra  
Idézet
versio :
en csak azert emlitettem meg, mert en is agyfaszt kaptam a forditasi idoktol windows metrora programozva, soha nem ternek vissza se windowsra se c++-ra, nem ment el az eszem

Ez mindössze azért ciki, mert egy tetves szó sem volt a fordítási időkről...

Btw aki OpenGL-t akar programozni, az nyílván azért teszi, mert nem egy meglévő enginehez akar contentet csinálni, hanem mert OpenGL-t akar programozni.
Dare to imagine!
http://www.insaneidea.hu
   
versio - Tag | 659 hsz       Online status #202138   2014.03.21 18:06 GMT+1 óra  
en csak azert emlitettem meg, mert en is agyfaszt kaptam a forditasi idoktol windows metrora programozva, soha nem ternek vissza se windowsra se c++-ra, nem ment el az eszem
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #202123   2014.03.21 07:12 GMT+1 óra  
El se kezdjétek ezt a baromságot - ez nem a Unity topic!
Dare to imagine!
http://www.insaneidea.hu
   
Geri - Törzstag | 2188 hsz       Online status #202121   2014.03.21 03:05 GMT+1 óra  
hát hogyne

   
versio - Tag | 659 hsz       Online status #202118   2014.03.21 00:50 GMT+1 óra  
bolyzsolt: a megoldas az unity
   
Pretender - Törzstag | 2498 hsz       Online status #202113   2014.03.20 22:41 GMT+1 óra  
Arra esetleg megpróbálhatsz egy köztes dolgot: lehet, hogy az a kód, amit használsz egy csomó minden checket csinál, ha bizonyos dolgok definiálva vannak (amik debug esetén). Csinálsz egy custom targetet, aminek lecopyzod a release beállításait, csak kikapcsolod a kódoptiamlizálást,, debug infókat bekapcsolsz, stb.

Én arra gyanakszok, hogy debug módban a memóriát is nagyon figyeli (kiindexelés tömbből, ilyesmik), és az foghatja meg. Na de oda TODO-ztam, hogy release-re majd uncomment.

   
bolyzsolt - Törzstag | 607 hsz       Online status #202112   2014.03.20 22:07 GMT+1 óra  
Idézet
Pretender :
szerk. 2:
Aha, újabb tapasztalatok azt mutatják, hogy csak vs-ből indítva debuggerrel csinálja. Ha az elkészült exe-t indítom, akkor nincs akadás. Érdekes.


VS tud csinálni érdekes dolgokat... Én most egy meglévő (nem általam írt) kódalapra fejlesztek játékot, ami debug módban 2-3 FPS-t tud, releaseben 55-60-at. Azaz release módban tudok csak rendesen tesztelni, viszont ekkor a végső linkelés több, mint egy percig tart. :sóhaj

   
Pretender - Törzstag | 2498 hsz       Online status #202110   2014.03.20 19:45 GMT+1 óra  
VBO update:
Több helyen is azt olvastam, hogy jó, ha a glBufferSubData előtt hívunk egy glBufferData-t null pointerrel, és ezzel xy dolgot jelzünk a drivernek. Így is tettem, és csak pislogtam, hogy mi a fene van, mert periodikusan néhány mp-enként megakadt az egész kb. fél mp-re. Ha kiszedem a glBufferData-s dolgot, akkor meg jól működik. Ez mennyire általános? Teljesen driver-függő legalább?

Így jó:
Kód:
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferSubData(GL_ARRAY_BUFFER, 0, numVertices * vertexSize, _vertices);


Így nem:
Kód:
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferData(GL_ARRAY_BUFFER, numVertices * vertexSize, 0, usageTypes[dynamic]);
glBufferSubData(GL_ARRAY_BUFFER, 0, numVertices * vertexSize, _vertices);


Annyi megjegyzéssel, hogy a numVertices * vertexSize állandó, a buffer létrehozásakor számolom csak ki, azaz mindig a teljes buffer tartalmát lecserélem.

szerk.:
Ja igen, ATI/AMD kártyám és driverem van, lehet az a baj

szerk. 2:
Aha, újabb tapasztalatok azt mutatják, hogy csak vs-ből indítva debuggerrel csinálja. Ha az elkészült exe-t indítom, akkor nincs akadás. Érdekes.

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

   
Seeting - Törzstag | 2306 hsz       Online status #201973   2014.03.12 11:59 GMT+1 óra  
Idézet
syam :
Idézet
__z :
Idézet
syam :
Én itt nem látok vbot csak vertex arrayt.


A lényeg, hogy működik...





Viszont ha kliens memóriából töltöd fel az adatot minden frameben, akkor tud számítani a felesleges méret. Persze kis méretnél ill. amíg 60 fps a sebesség addig nincs gond



Ha vbo-t használ akkor is kliensből tölti fel minden frameben (ha dinamikus változik). Sőt, ha glBufferData-t vagy glBufferSubData-t használ akkor úgy néz ki, hogy kliens->pinned (kliens) -> device. Míg mapbuffer esetében csak kliens -> device. Ha a driver el tudja kerülni a másolást, akkor el fogja.
   
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]