Servus,

ich hab grad probleme ein lächerliches quad auf den bildschirm zu bringen.
Das rendern per indices funktioniert nicht und resultiert weder in einem fehler noch mit einem sichtbaren ergebnis.

Habe folgende Vertex Struktur die ich verwende:



Ich versuch grad ein Quad zu erzeugen aus 2 Dreicken, dazu generiere ich mir 2 Dynamische Arrays in meinem Vertex Format oben, wobei ich nur Position und Texcoord verwende.



Das füllt mir nur diese 2 arrays oben und dann ist das thema eigentlich durch.

Versuche ich nun das ganze mit glDrawElements() zu rendern, bekomm ich kein Ergebnis.
Es passiert auch kein Fehler, einfach es wird nix gerendert



Die Daten stimmen, weil folgende Funktion geht einwandfrei und liefert das quad.



Ich peils irgendwie grad nicht, warum geht die Draw Elements methode nicht.
Es sind doch 6 Indices, also 6 Punkte = 2 Dreiecke.

Wo liegt denn der fehler ? Es muss ja an den indices liegen.

A few questions:
-what opengl context do you use? 2.x or 3.x
-how do you load the vertex buffer after setting your arrays and before rendering?
-do you bind the indices buffer, you also need to do that again before rendering
-i dont trust your indices however you say the work using old skool opengl
-also i do not trust your vertexpointer, can you try nil/0 as you want to start at the first element.
-personaly is use arrays of glfloat instead of a record structure.
Hope this is of some help...

_________________
http://3das.noeska.com - create adventure games without programming

Ich kann mich auch irren, aber - ich finde bei Dir kein einziges glBindBuffer ...

Also so etwas:


lgTraude

@Traude: Er nutzt VertexArrays, das ist ok so. Mir ist ein Rätsel warum das nicht funktioniert...

_________________
Yeah!

An sich ist der Code in Ordnung. Hast du es mal mit einem packed record für dein TVertex probiert?

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Jop hab ich und kein unterschied, das rekord hat auch weiterhin 64 bytes.
Weil ich ja 8 Bytes padding anhänge (Pad)
Siehe opengl.org wiki http://www.opengl.org/wiki/Vertex_Buffer_Objects



I use normal old opengl 2.x.
There are no vertex buffer or binding in my case, because i use old style vertex array without buffer.


Mein problem ist aktuell das das gleiche Konstrukt auch mit VBO nicht geht.
Wenn ich also meine Daten in ein VBO und IBO hochlade und mit nil Pointer rendere,
dann hab ich das gleiche ergebnis.

Sprich wenn die Vertex Array geschichte nicht geht, dann geht auch die VBO sache nicht.

Evtl. setz ich mich voll in die Nessel (kann mich grad kaum konzentrieren), aber es kann an den Datentypen liegen. Du gibts an GL_UNSIGNED_INT, und wenn ich recht entsinne ist unsigned int doch 16 bit, während du für die Indices aber Longword = 32 Bit benutzt. Oder hab ich da was verpeilt?

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Unsigned Int = 32bit..
Unsigned Short = 16bit

*nesseln rüberreich*

@Aya : I stand corrected...

Aber echt komisch. Ich hab grad mal meinen alten Scenemanager (Bumpmapping, PP-Lighting usw.) geöffnet und da nutz ich glDrawElements für die Schattenvolumen. Das sieht fast genauso aus wie bei dir, klappt aber problemlos. Einziger Unterschied dass ich nicht den Pointer auf die X-Koordinate vom Vertex setze. Das dürfte aber ja eigentlich nix ausmachen, aber probier mal nur @Vertices[0] ohne Pos.X.

P.S. : So siehts bei mir aus :

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Auf die gefahr hin das ich mich mit in die Nesseln setz...

Ist dein stride richtig?... müßte das nicht sizeof(TVertex) - 12 sein?

Aya~

Nein, sein Stride ist korrekt. Der gibt nich an wie viel Platz zwischen den Vertices ist, sondern wo das nächste beginnt. Da ist also SizeOf(Struktur) richtig,

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Wenn das stimmt wie du es sagst, würde ein stride von 0 aber keinen sinn machen... und rein theoretisch versteh ich den text in der doku so, dass stride den abstand zwischen aufeinanderfolgenden vertices angibt.

Aya~

Stride is the third not fourth parameter. Stride has to be the size of the records used. So opengl knows where the next vertex coords can be found
The fourth parameter is the position of the first element unless you want to skip some it can be set to 0 or nil. You can skip texture and normal coords with that.
Personaly i would use ptr(0) or in case of my normals:
to skip 2 vertex coord floats.
but then i use an array of floats. (is an record structure always equal internaly to an array of glfloat?)
But in your case there is no need to skip anything to 0 or ptr(0) should be fine. But now that i think of it refering to the .x should also give a ptr to the first element in the array meaning 0 or ptr(0). Or is there something like a record header that needs to be skipped?

http://www.opengl.org/sdk/docs/man/xhtml/glVertexPointer.xml

_________________
http://3das.noeska.com - create adventure games without programming

Ok ich habs hinbekommen.

Es lag wohl definitiv am Index Array.
Longword passt einfach nicht, das ganze auf Word geändert geht.



Das lief, und sogar mit farben

K ich hab noch ne weitere frage:

Ich hab nun auch VBO ans laufen gebracht und aber feststellen müssen,
sobald meine VBO daten hochgeladen wurden, dann kann ich keine normalen Vertex Array´s mehr nutzen für die Daten welches die basis für VBO waren.

So lade ich meine Daten in den VRAM:



Das lädt meine Vertex Daten und meine Index Daten in den VRAM mit einer VBO und einer IBO id.
Das passiert direkt nachdem initialisieren von OpenGL, da wo ich auch meine Texturen lade und so.

Wenn ich aber nun, per vertex array meine Mesh Daten Ohne VBO rendern will... AMesh.Vertices und AMesh.Indices.
welche in einer Klasse gespeichert sind, wieso knallt es dann mit einer Zugriffsverletzung in Lazarus?

Würde gerne verstehen wieso es da knallt, sobald ich versuche mit AMesh.Vertices über Vertex Array zu rendern.

Weil das VBO dürfte nachdem upload ja eigentlich gar kein zugriff mehr haben auf meine Rohdaten,
weil ja alles im VRAM ist. (Raff ich grad nicht)

Da muss ja noch irgendein bezug da sein.