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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2196
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]
Elodin - Tag | 184 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 | 184 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 | 184 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 | 184 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 | 184 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 | 184 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 | 2196 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 | 606 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 | 673 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 | 2196 hsz       Online status #202121   2014.03.21 03:05 GMT+1 óra  
hát hogyne

   
versio - Tag | 673 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.
   
syam - Törzstag | 1491 hsz       Online status #201969   2014.03.12 11:18 GMT+1 óra  
Idézet
__z :
Idézet
syam :
Viszont ha kliens memóriából töltöd fel az adatot minden frameben, akkor tud számítani a felesleges méret.


Jah, hát ezért kérdeztem.
Viszont egyrészt a glDrawArrays-nál gondolom nem véletlenül kell megadni tartományt, másrészt a futás közbeni sebesség bőven jó (30+ FPS egy Alcatel 990-en).



Hogy mikor és mit művel a vertex arrayjal az a driver dolga. A "tartomány" csak annyit mond, h hány mettől meddig akarsz renderelni vagyis azokat fogja feldolgozni - hogy mennyi megy fel a gpunak az már driver kérdés.
Egyébként a drawarrayst nem szeretik, mert nem használod a vertex cachet. Ahol lehet indexelt geometriát használj. Ilyen esetben már extension optimalizálásra: glDrawRangeElements, aminek meg lehet mondani, hogy mekkora vertex mennyiséget fogsz felhasználni az arrayból.

De még egyszer: ha megfelelő / interaktív sebességű a framerate, akkor totál mindegy mit csinálsz, ha minden készüléken megy és ugyanúgy is néz ki
alias aalberik
   
__z - Tag | 74 hsz       Online status #201968   2014.03.12 11:08 GMT+1 óra  
Idézet
syam :
Viszont ha kliens memóriából töltöd fel az adatot minden frameben, akkor tud számítani a felesleges méret.


Jah, hát ezért kérdeztem.
Viszont egyrészt a glDrawArrays-nál gondolom nem véletlenül kell megadni tartományt, másrészt a futás közbeni sebesség bőven jó (30+ FPS egy Alcatel 990-en).
   
syam - Törzstag | 1491 hsz       Online status #201967   2014.03.12 10:58 GMT+1 óra  
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
alias aalberik
   
__z - Tag | 74 hsz       Online status #201966   2014.03.12 10:54 GMT+1 óra  
Idézet
syam :
Én itt nem látok vbot csak vertex arrayt.


A lényeg, hogy működik...
   
syam - Törzstag | 1491 hsz       Online status #201965   2014.03.12 10:43 GMT+1 óra  
Idézet
__z :
Itt a konkrét kód (Android/Java):
Kód:
FloatBuffer vertices = ByteBuffer.allocateDirect(49152).order(ByteOrder.nativeOrder()).asFloatBuffer(),
            texCoords = ByteBuffer.allocateDirect(49152).order(ByteOrder.nativeOrder()).asFloatBuffer();
float[] array = new float[12];
int[] transform = new int[2];         
float width, height;

gl.glVertexPointer(2, GL10.GL_FLOAT, 0, vertices.clear());           
gl.glTexCoordPointer(2, GL10.GL_FLOAT, 0, texCoords.clear());

void drawArrays(GL10 gl) {
  gl.glDrawArrays(GL10.GL_TRIANGLES, 0, vertices.position() / 2);
  texCoords.clear();
  vertices.clear();
}       

void draw(float x, float y, int textureX, int textureY, int textureWidth, int textureHeight) {     
  if (vertices.remaining() == 0) drawArrays(gl);
  array[10] = array[2] = array[0] = x;
  array[9] = array[5] = array[1] = y;           
  array[8] = array[6] = array[4] = x + Math.abs(transform[0]) * textureWidth;
  array[11] = array[7] = array[3] = y + Math.abs(transform[1]) * textureHeight; 
  vertices.put(array);             
  array[10] = array[2] = array[0] = (transform[0] > 0 ? textureX : textureX + textureWidth) / width;
  array[9] = array[5] = array[1] = (transform[1] > 0 ? textureY : textureY + textureHeight) / height;           
  array[8] = array[6] = array[4] = (transform[0] < 0 ? textureX : textureX + textureWidth) / width;
  array[11] = array[7] = array[3] = (transform[1] < 0 ? textureY : textureY + textureHeight) / height;
  texCoords.put(array);                 
}
// a transform tömböt tükrözéshez és nagyításhoz használom




Én itt nem látok vbot csak vertex arrayt.
alias aalberik
   
Seeting - Törzstag | 2306 hsz       Online status #201964   2014.03.12 08:07 GMT+1 óra  
Idézet
syam :
VBO frissítése nem ajánlott dolog. Ha mégis muszáj, mert pl. uniformként nem kezelhető az adat, akkor buffersubdata esetleg dupla bufferelve. A mappelés annyira nem válik be.



Hát pedig ez a dynamic batchelés lényege. Minden frameben frissíteni. Csak az a kérdés, hogy milyen módszerrel invalidáljuk a régi adatot. A duble bufferinget is el lehet érni többféleképpen. Egyébként miért nem szereted a mapbuffer-t?
   
__z - Tag | 74 hsz       Online status #201963   2014.03.12 06:44 GMT+1 óra  
Itt a konkrét kód (Android/Java):
Kód:
FloatBuffer vertices = ByteBuffer.allocateDirect(49152).order(ByteOrder.nativeOrder()).asFloatBuffer(),
            texCoords = ByteBuffer.allocateDirect(49152).order(ByteOrder.nativeOrder()).asFloatBuffer();
float[] array = new float[12];
int[] transform = new int[2];         
float width, height;

gl.glVertexPointer(2, GL10.GL_FLOAT, 0, vertices.clear());           
gl.glTexCoordPointer(2, GL10.GL_FLOAT, 0, texCoords.clear());

void drawArrays(GL10 gl) {
  gl.glDrawArrays(GL10.GL_TRIANGLES, 0, vertices.position() / 2);
  texCoords.clear();
  vertices.clear();
}       

void draw(float x, float y, int textureX, int textureY, int textureWidth, int textureHeight) {     
  if (vertices.remaining() == 0) drawArrays(gl);
  array[10] = array[2] = array[0] = x;
  array[9] = array[5] = array[1] = y;           
  array[8] = array[6] = array[4] = x + Math.abs(transform[0]) * textureWidth;
  array[11] = array[7] = array[3] = y + Math.abs(transform[1]) * textureHeight; 
  vertices.put(array);             
  array[10] = array[2] = array[0] = (transform[0] > 0 ? textureX : textureX + textureWidth) / width;
  array[9] = array[5] = array[1] = (transform[1] > 0 ? textureY : textureY + textureHeight) / height;           
  array[8] = array[6] = array[4] = (transform[0] < 0 ? textureX : textureX + textureWidth) / width;
  array[11] = array[7] = array[3] = (transform[1] < 0 ? textureY : textureY + textureHeight) / height;
  texCoords.put(array);                 
}
// a transform tömböt tükrözéshez és nagyításhoz használom
   
syam - Törzstag | 1491 hsz       Online status #201961   2014.03.12 01:57 GMT+1 óra  
Mármint dinamikusan töltöd fel / updateled minden frameben a vbo tartalmát?
alias aalberik
   
__z - Tag | 74 hsz       Online status #201960   2014.03.12 00:38 GMT+1 óra  
Idézet
syam :
A vbo "akármekkora" lehet sebességet nem befolyásol. Ha mobilplatform is bejátszik, akkor arra kell figyelni, h 64k vertexnél ne legyen több.


Az ilyesmikre voltam kíváncsi, de most csak kb. ~12k vertex-nyit foglalok (49152 byte), ami már biztosan elég, és ezek szerint sok vizet nem zavar a "fölöslegesen" lefoglalt hely.
Egyébként nem tudom, milyen alternatívák vannak, de én egyszerű float-ként olvasom be a bufferekbe a texcoord és vertex pozíciókat, így feltételezem, ezek frame-enként "közlekednek" a két ram között, ezért gondoltam, hogy számíthat a méretük...
   
syam - Törzstag | 1491 hsz       Online status #201959   2014.03.11 23:10 GMT+1 óra  
A vbo "akármekkora" lehet sebességet nem befolyásol. Ha mobilplatform is bejátszik, akkor arra kell figyelni, h 64k vertexnél ne legyen több.

Kb. csak arra kell figyelni, hogy interleaved legyen az adat és minél kisebb méretű legyen a vertex attrib össz mérete.

VBO frissítése nem ajánlott dolog. Ha mégis muszáj, mert pl. uniformként nem kezelhető az adat, akkor buffersubdata esetleg dupla bufferelve. A mappelés annyira nem válik be.
alias aalberik
   
Seeting - Törzstag | 2306 hsz       Online status #201958   2014.03.11 22:08 GMT+1 óra  
Egyébként te hogy frissited a vbo-k tartalmát? Mert jelenleg pont én is ilyesmit implementálok. És ez egyáltalán nem triviális dolog.
   
Seeting - Törzstag | 2306 hsz       Online status #201957   2014.03.11 22:05 GMT+1 óra  
Minél nagyobb a vbo, nyilván annál többet foglal a vram-on, és ha kevés négyszöget rajzolsz ki, akkor ráadásul feleslegesen is.
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #201950   2014.03.11 12:57 GMT+1 óra  
Amit írtam, az igazából független attól, hogy mit rajzolsz ki - ezer db négyzet = kétezer db tri (feltéve, hogy nincs ismétlődés), meg egy kétezer polys modell is kétezer tri

Szóval nem, nem látom, hogy lenne bármilyen hátulütője a dolognak.
Dare to imagine!
http://www.insaneidea.hu
   
__z - Tag | 74 hsz       Online status #201949   2014.03.11 08:41 GMT+1 óra  
MaNiAc :
Még mindig csak 2D-s sprite-okat rajzolgatok.
A kérdés arra vonatkozott, hogy foglalhatok akkorát, amibe mondjuk 1000+ "négyzet" belefér, úgyis csak a használt rész számít (a glDrawArrays-nál ugyebár meg kell adni ezt), vagy lehetnek ennek hátulütői?
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #201939   2014.03.10 22:29 GMT+1 óra  
Ha 1x akkora kell a modellnek, amit megjelenitesz, akkor akkora kell neki, ebbol ne csinalj problemat Ha mar millios nagysagrendrol van szo, akkor meg ugyis lesz valamifele vagas, ami alapjan megjelenitesz vagy nem jelenitesz meg egy objektumot (pl. egy epulet modelljet felvagod reszekre es csak azokat a reszeket jelenited meg, amik a latoterben vannak, stb)
Dare to imagine!
http://www.insaneidea.hu
   
__z - Tag | 74 hsz       Online status #201891   2014.03.09 07:55 GMT+1 óra  
Implementáltam a dolgot, még az a kérdés merült fel bennem, hogy mekkora vertex és texCoord buffereket érdemes foglalni? Vagy másként megfogalmazva: ha túl nagy méretet foglalok (persze itt csak kilobyte-os nagyságrendre kell gondolni), annak lehet negatív hatása? (Most 4kb-ot foglalok, és ha kevés lenne, meghívódik a glDrawArrays és a bufferek visszaállítása.)
   
Seeting - Törzstag | 2306 hsz       Online status #201835   2014.03.07 05:56 GMT+1 óra  
Ja igen, főleg ha VAO-t használsz. De ha nem, akkor jobb az összevont buffer, mert az csak 1 db glBind().
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #201830   2014.03.06 19:40 GMT+1 óra  
Idézet
Seeting :
Desktop GL esetében is ajánlott, a drawcall-ok számának redukalasa. Persze pc-n egy 2D-s játék eseteben nem fogod érzékelni a változást.

Összevonás alatt arra gondoltam, hogy két külön array van vs. egy db array + stride. Ez drawcall szempontból tök mindegy szerintem.
Dare to imagine!
http://www.insaneidea.hu
   
Seeting - Törzstag | 2306 hsz       Online status #201820   2014.03.06 13:11 GMT+1 óra  
Desktop GL esetében is ajánlott, a drawcall-ok számának redukalasa. Persze pc-n egy 2D-s játék eseteben nem fogod érzékelni a változást.
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #201818   2014.03.06 09:36 GMT+1 óra  
Szerintem az összevonás preferencia kérdése - bár nem tudom, ES-nél van-e erre valami speciális dolog... (Desktop GL-lel dolgozok). Én csináltam már így is, úgy is.

A másik meg igen, triangles... Régen nagyon nyomatták a tristrip-et is, néhány esetben biztos jó is, de sokszor elég szopás, mivel egy random 3d progiból (pl. Blender) kiexportált modellben sima trik lesznek, indexelve.
Dare to imagine!
http://www.insaneidea.hu
   
syam - Törzstag | 1491 hsz       Online status #201817   2014.03.06 09:34 GMT+1 óra  
Amit lehet batchelj. A mobilok nagyon kényesek a drawcall számra.
Célszerű külön kezelni uvt és pozíciót.
Indexelt háromszögeket érdemes használni, mert akkor egymással össze nem kapcsolt háromszögeket tudsz renderelni (strip esetén degenerált háromszög kellene), de ugyanakkor használod is a vertex cachet.

Én billboard pontokat és vonalakat batchelek (ill. szöveget) - tipikusan az az eset, amiből sok van viszont egyszerre kevés a geometria.
alias aalberik
   
__z - Tag | 74 hsz       Online status #201814   2014.03.06 09:02 GMT+1 óra  
Még két kérdés:
- a texCoord és vertex tömböket össze lehet (illetve érdemes) vonni egybe?
- mi a legcélszerűbb primitiv (gondolom GL_TRIANGLES) ?
   
Pretender - Törzstag | 2498 hsz       Online status #201813   2014.03.06 08:29 GMT+1 óra  
Szövegekre mindenképpen érdemes egybegyúrni. Sőt, a sprite-ok rajzolásához is. Általában Sprite Batch-nek nevezik ezt az egészet, és egy dinamikus VBO-ba frissítgetik az értékeket.
Szóval ilyesfajta sprite renderelésnél szerintem mindenképpen gyorsulást hozna, elkerülve a draw callok overhead-ét.

   
__z - Tag | 74 hsz       Online status #201812   2014.03.06 05:39 GMT+1 óra  
OpenGL ES (1.1) kérdés: Egy 2D-s játéknál, ha a "négyzetenkénti" rajzolás (gl.glDrawArrays(GL10.GL_TRIANGLE_STRIP, 0, 4); ) helyett összegyűjteném a textúra és vertex koordinátákat egy über tömbbe, és csak egyszer hívnám a glDrawArrays-t, az eredményezhet-e érdemi gyorsulást, illetve lehetnek-e egyéb előnyei/hátulütői (rajzolási sorrend, stb.) ?
(Most főként a szövegek kiírásánál jön elő lassulás, ahol a betűket is a fent leírt módon, "egyesével" rajzolom.)
(Szerk: Persze a felvetett megoldás feltételezi, hogy egyetlen nagy textúra atlaszból rajzolok, és nem váltogatom a textúrákat közben.)
   
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]