Hey Leute

Ich habe schon seit längerm ein Problem mit Vertex Arrays bzw. dem Texturmapping!
Angefangen mit dem Thema habe ich auf der Seite:
http://www.songho.ca/opengl/gl_vertexarray.html

3D Objekte rendern ist alles kein Problem aber mein Punkt der mir Kopfzerbrechen bereitet ist folgender:
glTexCoordPointer()

Wie zum Teufel soll das gehen?

Ich habe z.b ein Array für die Geometrie, für die Texturkoordinaten, Normals, Index usw.
Damit kann ich ohne Probleme das 3D Model laden und die Texturkoordinaten habe ich auch aber wie bestimme ich die Textur die rauf kommt???

So wie ich das sehe wird das Array ja einfach abgearbeitet und das wars...

Aktuell lege ich die Textur mit glBindTexture(...) und glTexParameteri(...) fest aber dann wäre ja überall die gleiche Textur!
Wie kann ich das am besten lösen?

Edit// Irgendwie kam mir gerade eine Idee
Soll man das Array einfach immer nur soweit abarbeiten bis eine neue Textur kommt, diese dann einbindet und dann gehts quasi von dem Punkt wo man aufgehört hat weiter?
Bei glDrawArrays kann ja beim 2. Parameter der Startwert bzw. 3. Parameter der Endwert definiert werden.

Ja, das sollte gehen. Einfach die neue Textur binden und weiterrendern. Hat aber den Nachteil, dass du die Offsets wissen musst, ggf ist es sinnvoller, pro Material einfach eigene Arrays zu erstellen. Dürfte ja nicht viel Zeit kosten.

_________________

Klingt allerdings auch nicht sehr schnell...

Was ist denn von der Geschwindigkeit her besser: Displaylists oder Vertex Arrays?
Die Vor- und Nachteile mal außen vorgelassen!


Edit// Hab nun auch öfters gelesen, dass Displaylists bei ATI/AMD Karten ziemlich langsam sind - also im Vergleich zu nvidia!
Kann auch bestätigen das meine 3D Anwendung ziemlich schnell mit Displaylists einbricht! Werd ich mal auf einer nvidia Testen was da dran ist.
Kann man einer Displaylist auch bei ATI/AMD auf die Sprünge helfen oder hilft da nur VBO, VOA etc.?!

VBOs dürften, bei Geschickter verteilung der Vertices (bzgl. Texturnutzung) das schnellste sein, was du bekommen kannst.
Displaylisten werden je nach Treiber auch zu VBOs optimiert, wenn das möglich ist.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Okay danke für die Info!
Naja ich wollte meine Displaylists ohnehin zu VBO's abändern. ^^

Wie du die Textur wechselst hast du ja selbst herausgefunden, mit den Texturkoordinaten hab ich aber selbst keine Idee, da musste die Textur entsprechend Geschickt einsetzen / bearbeiten / erstellen.



Hat alles seine Vor- und Nachteile.

Vorteile:
VAO :
Vertexdaten werden im Hauptspeicher abgelegt --> der RAM der Grafikkarte wird entlastet,
lassen sich leichter bearbeiten,
schneller als glBegin() und glEnd()

VBO :
Vertexdaten werden im RAM der Grafikkarte abgelegt --> schneller
schnellste Methode

Displaylisten :
flexibler, da diese z. B. Manipulationen an der Matrix und den "states" enthalten können


Nachteile:
Das die Vorteile der anderen Methoden fehlen.
Bei Displaylisten kommt als Nachteil noch hinzu das es "deprecated", also veraltet ist und daher nicht mehr als Kernfunktion zur Verfügung steht (deine Grafikkarte / Treiber KANN diese Funktion allerdings dennoch unter Umständen unterstützen, muss es aber ab 3.x NICHT MEHR).

Das kann man so leider nicht stehen lassen. Displaylisten können nachträglich NICHT mehr geändert werden, die States werden während des Erstellens in die Displaylisten kompiliert. Ist diese erstmal im VRAM kann man an ihr nur noch via Shader etwas ändern.

Anders VBOs, dort gibt es spezielle Flags (Stream, Read-only, etc.) mit denen man VBOs auch effizient zur Laufzeit verändern kann.

Und zum Thema Distplaylisten gegen VBO :
Auf aktuellen Karten spielt das keine Rolle. Es ist schon lange so dass Treiber Displaylisten intern als VBOs ablegen.

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

Das war ja schonmal sehr Informativ hier

Ich habe gerade mal etwas ganz billiges via VA versucht doch es wird einfach nix gerendert, was ich gerade nicht verstehen will.


Kann mir da zufällig mal jemand schnell sagen woran das liegt?!

Zunächst einmal ist der letzte Parameter von glDrawArrays "count", also Anzahl und nicht "der höchste Index". Dein Array enthält 12 floats, welche 4 Vertices darstellen, darum muss auch count = 4 sein wenn du das komplette Array zeichen willst.

Dann ist deine Modelview- und deine Projektionsmatrix uns unbekannt.
Ist die Modelviewmatrix = Identity und deine Projektionsmatrix eine durch glFrustum oder gluProjection erzeugte Matrix, dann kannst du wegen dem Z-Wert nichts sehen, da dein "3-Eck-Modell" vor der Nahclipping-Ebene liegt. glTranslatef(0.0f, 0.0f, -1.0f); würde das Problem lösen, allerdings sind deine 3-Ecke fast schon zu groß (sehen würdest du aber dennoch etwas).
Für den Fall das du Orthogonale Projektion benutzt ohne Transformationen: überprüfe die Parameter.

Dein Array zeichnet übrigens 2 Dreiecke, wovon das erste durch "Backfaceculling" "unsichtbar" wird.



An Sascha: wie kann man Displaylisten mit Shader manipulieren? O.o

Okay habs auf 4 geändert aber geht trotzdem nicht.

Die anderen Sachen schließe ich alle aus.
Ich habe hier kein 50 Zeilen Projekt sondern schon ein paar Tausend wo Kamerasteuerung usw. integriert ist.
Mit Displaylists, glBegin/glEnd seh ich es ohne Probleme aber bei dem DrawArray kommt da nix.

Ich habe es mal in mein Projekt eingefügt. Bei mir zeichnet es ohne Probleme.

Sonst wäre da noch "Farbe = Hintergrundfarbe"?

Hab ich auch schon überprüft, führt zu keinem Ergebnis.
Ahja wegen dem Matrixmode:
Erst glMatrixMode(GL_PROJECTION) (für Clipping einstellen etc.) und danach einfach Modelview - also glMatrixMode(GL_MODELVIEW).

Ich werd wohl mal kurz ein neues Projekt erstellen und schauen obs da läuft... wenn du sagst es geht bei dir wirds schon so sein

Funktioniert es denn nun?

Jap klappt... kann mir zwar noch nicht so ganz erklären warum aber ok, sei mal dahingestellt.

Ich hätte nochmal eine Frage zu den Displaylists. Jetzt mal ganz allgemein, wie viel Polygones sollte so eine Displaylist rendern können mit aktueller Hardware?
Ich habe leider das Problem, dass meine Performance bei 50.000 deutlich einbricht und das kann ja eig. nicht sein.. oder?!

Es gibt kein Magischen Wert. Früher war es 1024, auf einigen 2048 vertice und das steigt mit jeder gpu generation. Das liegt am Cache, die Performance kommt aus dem vertex cache, welcher n Vertice aufnehmen kann und je weniger zugriffe ausserhalb dieser Vertice passiert des so schneller. Also es ist viel mehr wichtiger die vertice in richtiger reihenfolge in den speicher zu packen und eine displaylist drüber zu packen, statt einen magische Anzahl für die Displaylist zu suchen, denn die ist jedes mal anders, je nach dem wieviele cache misses auftreten und die performance vom buffer zunichte machen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004