(LWJGL) VertexBufferObjects

[Spacerat]

Hallo
Ich fange gerade an, mich eindringlicher mit VBOs zu beschäftigen, damit ich von diesen schwerfälligen DisplayLists weg komme.
Dazu habe ich nun mal ein paar Fragen.
1. Die Meshes meiner geladenen 3D-Objekte sind nicht immer (eigentlich sogar eher selten) trianguliert. Wie kann ich mit VBOs nun untriangulierte Meshes darstellen, deren Polygone verschiedene Anzahl an Eckpunkten haben. Wenn das nicht geht, wäre ein simpler Algo zum Triangulieren von Ebenen im 3D-Raum auch nicht schlecht, Google spuckt da immer nur "Delaunay für 2D-Punkte aus.
2. Welche Art der VBOs ist eigentlich die aktuellere bzw. gängigere? Die mit "glBindBuffer" oder die mit "glEnableClientState". Ich bin mir echt im Unklaren darüber, weil man ständig überall liest, dass VBOs bis Version 3.0 (1.2, 1.5 usw. usf) gar nicht bzw. immer anders unterstützt werden. Im allgemeinen sind VBO-Tutorials doch eher verwirrend als hilfreich. Soll ich z.B. besser die ARB- oder die normalen Methoden dafür benutzen? Wenn ich's mir recht überlege, sind VBOs aufgrund ihrer Dokumentation eigentlich viel schwerfälliger als DisplayLists. ???:L
3. Kennt jemand aktuelle Tuts für LWJGL? Dieses DGL-Wiki hilft einem in Java nicht wirklich immer und LWJGL.org selber... naja, aktuell ist das anscheinend nicht.

Schon mal Danke im vorraus, für zahlreiche Antworten.

 

[Marco13]

1. Das kann kompliziert sein. Für "gute" Triangulierungen braucht's den Delaunay. Wenn das nicht wichtig ist, muss man wissen, um was für Polygone es geht: Wenn es auch konkave Polygone sein können, muss man wohl sowas wie Ear Clipping (Polygon triangulation - Wikipedia, the free encyclopedia ) verwenden. Frickelig. Wenn es nur konvexe Polygone sind, und man kein Problem mit eventuell spitzen Dreiecken hat, reicht es aber auch, ausgehend vom Punkt 0 Kanten zu den Punkten 2 bis n-1 einzufügen - also quasi einen "Fächer" in das Polygon zu legen (mit Abstand das einfachste).

2. Man braucht wohl beides (ich bin mir nicht sicher, worauf die Frage abzielt). Vielleicht sollte man auch weiter oben anfangen: Nicht bei VBO sondern bei VAO (A kommt vor B ). Bei neueren GL-Versionen braucht man immer ein VAO, wenn man ein VBO verwenden will. Zu VAOs fand ich Vertex Array Object - OpenGL.org ganz gut, aber es gibt vielleicht besseres. Die ARB-Methoden (steht ARAIR für "Architecture Review Board") sind, soweit ich das verstanden habe, Methoden, die noch nicht in den offiziellen Standard aufgenommen wurden, aber vermutlich bald werden. Wenn es eine entsprechende Methode OHNE "ARB" gibt, sollte man die verwenden.

3. Bin neulich über opengl-tutorial.org | Tutorials for OpenGL 3.3 and later gestolpert. Das sieht ganz aktuell aus, und ich werde es mir selbst nochmal näher ansehen.

 

[Guest2]

Moin,

neben dem bereits geschriebenen, vielleicht noch zwei (imho) wichtige Links:

Vertex Specification (aktuell, aber vieles davon gilt auch noch für die deprecated fixed function pipeline)
Vertex Specification Best Practices (achtung, in den Beispielen stehen teilweise deprecated funktionen, z.B.: [c]glVertexPointer[/c])

Viel hat sich an den VBOs seit OpenGL 1.5 eigentlich nicht verändert. Bei aktuellem OpenGL werden die Attribute eben mit [c]glVertexAttribPointer[/c] gesetzt und nicht mehr mit [c]glInterleavedArrays[/c] bzw. [c]glVertexPointer[/c], [c]glTexCoordPointer[/c], [c]glNormalPointer[/c]...

Mit ein wenig Fantasie gab es auch schon immer ein VAO. Es hieß halt einfach 0 und war default. Bei aktuellen OpenGL Versionen wurde dieses default VAO als deprecated markiert, deshalb muss im core profile mindestens eines selbst angelegt werden.

In LWJGL sind VBOs ziemlich simpel: z.B. [LWJGL] Fixed Function VBO

Viele Grüße,
Fancy

 

[Spacerat]

Herzlichen Dank für die Antworten. Diesen entnehme ich, dass es mit VBOs nur bedingt bzw. gar nicht möglich ist anderes als Quadrate und Dreiecke zu zeichnen. Wenn "GL_POLYGON" bei VBOs nicht funktioniert, wohl eher gar nicht. Ansonsten sieht's ja doch recht einfach aus.

Leider weis ich nie vorher, welche Art Polygone mich in den dubiosesten 3D-Dateien erwarten. Das bedeutet wohl, dass ich mich entweder eindringlicher mit Triangulation beschäftigen muss oder aber wieder ganz schnell zu meinen Displaylisten zurück kehre... :autsch:
Aber bevor das passiert, versuche ich mich noch mal an Java3D. Da funktionierte das damals ja auch schon mit Polygonen. Vllt. lässt sich ja der Algo vom "Triangulator" für meine Lib klonen, 'ne bessere Idee hab' ich zur Zeit jedenfalls nicht.

 

[Marco13]

Hmja, Polygone sind für OpenGL echt schlecht. ALLES außer Dreiecken ist schlecht: Die Dinger sind meistens nicht planar, und ggf. konkav, und haben im schlimmsten Fall Selbstüberschneidungen ... aber selbst wenn man was mit GL_POLYGON malt, muss OpenGL das irgendwann auf Dreiecke zurückführen, und ich würde wetten dass es intern auch nichts anderes macht, als das pragmatisch und ohne Rücksicht auf Sinn oder Unsinn in einen TRIANGLE_FAN umzuwandeln. (BTW: Bei meinem (nicht "schön" designten, sondern nur sehr rudimentären und pragmatischen) OBJ-Loader (der ja vielleicht bald obsolet wird ) hatte ich mal diese Triangulierung eingebaut javagl.de - Utilities , ObjUtils#triangulate, aber mehr als

            // if face.getNumVertices() > 3
            {
                for(int j = 0; j < face.getNumVertices() - 2; j++)
                {
                    DefaultObjFace triangle = 
                        new DefaultObjFace(face, 0, j + 1, j + 2);
                    output.addFace(triangle);
...
                }
            }

ist es halt eigentlich nicht... Was der Java3D-Triangulator macht, würde mich aber auch mal interessieren)

 

[Spacerat]

Hab' beim letzten Post mal 'ne URL hinzugefügt. Viel spass beim studieren .

So eine ähnliche Triangulation hatte ich auch schon mal. Ich hatte damals 'ne Arraylist instanziert, dieser neue Polygone jeweils aus den ersten 3 Vertices des aktuellen hinzugefügt und zuletzt den ersten Punkt des aktuellen Polygons entfernt, bis in diesem nur noch 3 Vertices übrig waren. Als meine 3D-Welt daraufhin einem Schrottplatz glich, habe ich diese Methode ganz schnell wieder entfernt und nach einem Weg geforscht, wie man untriangulierte Körper rendern kann. In Java3D ging das mit GeometryInfo und in JOGL und LWJGL mit "GL_POLYGON" und Displaylisten. Und jetzt kommen diese VBOs daher und sagen mir, dass es so nicht geht... Frechheit... :lol:

Wegen deinem OBJ-Loader würde ich mir nur deswegen Gedanken machen, weil er möglicherweise bereits obsolet ist, das liegt aber keinesfalls an meinerm Vorhaben. Ich weis jetzt nicht wie rudimentär deiner ist, aber die anderen mir bekannten drei (WireFrame-Demo, Java3D und JOGL) kümmerten sich nur um die Meshes. Allerdings ist's schon länger her, als ich sie mir zuletzt angesehen habe und es kann sein, dass zumindest JOGL und Java3D inzwischen auch Texturen unterstützen.

 

[Marco13]

Beim ersten überfliegen sieht der Code zwar nicht "schön" aus, aber doch einigermaßen überschaubar, und scheint zumindest in bezug auf das Vorgehen kommentiert zu sein. Sowas wie "earsRandom"... legt nahe, dass es eine Form des oben verlinkten ear clipping algorithmus ist.


EDIT: Zum "nicht 'schön'":

boolean gotIt[] = new boolean[1];

1-elementige Arrays um "call by reference" zu emulieren - durftet markant nach Code, der von C/C++ rüberportiert wurde

 

[Spacerat]

Hab' mir die Klassen nun mal angesehen und bin zu dem Schluss gekommen, dass sie schon viel zu weit über's Ziel hinaus schiessen. Das Problem: Der Triangulator trianguliert ganze Körper mit dem Ear-Algo. Diese müssen nicht eben sein und dürfen auch Löcher haben. Ich dagegen benötige eine Triangulation für Polygone von denen ich vorher nicht weis, wie sie aussehen bzw. ob sie überhaupt Eben sind. Löcher haben Polygone meines Wissens nicht, sonst wären es im Zweifelsfall ja bereits wieder 2D-Körper (z.B. eine Ring). Das bedeutet, die erwarteten Polygone haben genau eine Aussenkante und liegen irgendwie im Raum, statt auf einer Ebene.
Irgendwo im Netz muss es doch eine brauchbare Implementation eines solchen Algos geben, denn ich glaube kaum, dass ich der erste bin, der so etwas machen will. Leider finde ich da nichts. Was muss man eigentlich studiert haben um diese mathematischen "Hieroglyphen" bei den Beschreibungen von z.B. Delauney zu verstehen? Ich will's doch blos als Java-Methode haben... ;(

 

[Evil-Devil]

Wäre es nicht einfach möglich das Modell ins 3D Programm zu laden und zu triangulieren?

@VBOs: Wenn das im Wiki nicht ausreicht und du letzten Endes einen guten Ansatz gefunden hast, wäre es super, wenn du das im Wiki niederschreiben würdest

 

[Marco13]

Hab' mir die Klassen nun mal angesehen und bin zu dem Schluss gekommen, dass sie schon viel zu weit über's Ziel hinaus schiessen. Das Problem: Der Triangulator trianguliert ganze Körper mit dem Ear-Algo. Diese müssen nicht eben sein und dürfen auch Löcher haben. Ich dagegen benötige eine Triangulation für Polygone von denen ich vorher nicht weis, wie sie aussehen bzw. ob sie überhaupt Eben sind.

Das klingt widersprüchlich ???:L Wenn der Algorithmus dort mächtiger ist, als das was du brauchst, wäre das doch an sich OK...?!

Irgendwo im Netz muss es doch eine brauchbare Implementation eines solchen Algos geben, denn ich glaube kaum, dass ich der erste bin, der so etwas machen will.

Das Problem ist ziemlich komplex. Wenn jemand so etwas schreibt, dann ist das entweder
- einfach - also sehr speziell und für "den allgemein(st/er)en Fall" unbrauchbar
- schwierig - also sehr allgemein, und das kann eben beliebig (!) weit gehen. Nur wenige haben das Wissen und die Fähigkeiten, eine "gute Triangulierungsbibliothek" zu schreiben, und noch weniger haben die Zeit dafür, und das dass ganze dann auch noch als praktische, frei downloadbare JAR mit der Methode
[c]Magic.triangulateThisCrap(stuff);[/c]
( :bae: ) angeboten wird ist eher unwahrscheinlich.

Noch zwei Links: Bei jtem - Java Tools for Experimental Mathematics wird (ich glaube in "numericalMethods.jar") ein Delaunay- und ein Ruppert-Triangulierer angeboten. Die habe ich selbst schon verwendet, die sind recht leicht anzuwenden, aber natürlich erstmal nur 2D.

Ansonsten hat Geometric Tools eigentlich immer alles, was man braucht. Speziell auch Geometric Tools: Delaunay3D . Das ist in C++, aber meistens relativ leicht zu portieren (zumindest das, was ich bisher gebraucht habe). Den Delaunay habe ich mir da aber noch nicht angesehen.

 

[Spacerat]

Wäre es nicht einfach möglich das Modell ins 3D Programm zu laden und zu triangulieren?

Ne, leider nicht. Die Modelle, die geladen werden kommen aus irgendwelchen 3D Programmen und man kann halt nicht davon ausgehen, dass sie dort trianguliert gespeichert wurden.
Das Ganze soll ja ein pluginfähiger Objektloader als Teil einer ebenso pluginfähigen Datentyperkennung werden.

@VBOs: Wenn das im Wiki nicht ausreicht und du letzten Endes einen guten Ansatz gefunden hast, wäre es super, wenn du das im Wiki niederschreiben würdest

Tja, leider reicht das im Wiki soweit aus, dass ich zu der Überzeugung gekommen bin, dass ich entweder triangulieren oder weiterhin Displaylists verwenden muss.

Das klingt widersprüchlich ???:L Wenn der Algorithmus dort mächtiger ist, als das was du brauchst, wäre das doch an sich OK...?!

An sich schon. Real leider nicht, weil:

Das Problem ist ziemlich komplex. Wenn jemand so etwas schreibt, dann ist das entweder
- einfach - also sehr speziell und für "den allgemein(st/er)en Fall" unbrauchbar
- schwierig - also sehr allgemein, und das kann eben beliebig (!) weit gehen. Nur wenige haben das Wissen und die Fähigkeiten, eine "gute Triangulierungsbibliothek" zu schreiben, und noch weniger haben die Zeit dafür, und das dass ganze dann auch noch als praktische, frei downloadbare JAR mit der Methode
[c]Magic.triangulateThisCrap(stuff);[/c]
( :bae: ) angeboten wird ist eher unwahrscheinlich.

Der Triangulator ist nicht wirklich gerade einfach, er "foliert" (also als wenn man einzelne Fixpunkte mit Unterdruck in eine Folie einschweisst) dir sogar ganze Punktwolken, wenn's denn sein muss. Objekte aus 3D-Programmen sind aber höchst selten nur noch Punktwolken, sondern sie setzen sich bereits aus mehreren Polygonen zusammen und das halt nicht immer trianguliert. Mir geht es deswegen nur noch darum, einzelne Polygone zu triangulieren. Leider sieht meine Objektstruktur aber nicht so aus wie die von GeometryInfo aus Java3D. Daraus folgt, dass ich im Prinzip die komplette Java3D Objektstruktur auseinandernehmen müsste, um an den Teil zu gelangen, der für mich interessant ist.
Ich hätte mir allerdings schon gedacht, dass es einen solche Methode für Polygone aller Art in simpelster Form (z.B. mit Float-Arrays in der Form float[n][3]) bereits irgendwo gibt, warum denn auch nicht, ich bin ja wohl nicht der Erste, der in OpenGL bzw. ganz allgemein triangulieren will.

Noch zwei Links: Bei jtem - Java Tools for Experimental Mathematics wird (ich glaube in "numericalMethods.jar") ein Delaunay- und ein Ruppert-Triangulierer angeboten. Die habe ich selbst schon verwendet, die sind recht leicht anzuwenden, aber natürlich erstmal nur 2D.

Ansonsten hat Geometric Tools eigentlich immer alles, was man braucht. Speziell auch Geometric Tools: Delaunay3D . Das ist in C++, aber meistens relativ leicht zu portieren (zumindest das, was ich bisher gebraucht habe). Den Delaunay habe ich mir da aber noch nicht angesehen.

Danke, den letzten Link werde ich mir auf jeden Fall mal ansehen. 2D Beispiele habe ich aber selber genug.

 

[Marco13]

Das 3D-Delaunay-Ding zielt wohl auf Tetraeder ab. Für Polygone in 3D... hm ... ich bin mir nicht sicher, wie so eine allgemeine Methode aussehen sollte: Wenn man ein Viereck hat, gibt es schonmal zwei Möglichkeiten, die das trianguliert werden kann. Das kritische ist: In 3D können die Ergebnisse davon höchst unterschiedlich aussehen.

 

[Spacerat]

Ich hab' mich nochmal zurück gelehnt, über die Ear-Clipping-Methode nachgedacht und siehe da, für Polygone mit nur einer Aussenkante (also ohne Löcher) ist's doch relativ simpel:

List<Polygon> triangulate() {
  List<Polygon> rc = new List<Polygon>();
  List<Vertex> verts = this.verts;
  Vertex v1, v2, v3, v4, v5;
  while(verts.size() > 3) {
    v1 = verts.remove(0);
    if(verts.size() == 3) {
      rc.add(new Polygon(v1, verts.get(0), verts.get(2));
      rc.add(new Polygon(verts.get(0), verts.get(1), verts.get(2);
      return rc;
    }
    int sw = 0;
    v2 = verts.get(0);
    v3 = verts.get(1);
    v4 = verts.get(verts.size() - 1);
    v5 = verts.get(verts.size() - 2);
    if(v1.distance(v2) > v1.distance(v4)) {
      sw |= 1;
    }
    if(v1.distance(v3) > v1.distance(v5)) {
      sw |= 2;
    }
    switch(sw) {
    case 1:
      rc.add(new Polygon(v1, v3, v4));
      break;
    case 2:
      rc.add(new Polygon(v1, v2, v5));
      break;
    case 3:
      rc.add(new Polygon(v1, v5, v4));
      break;
    default:
      rc.add(new Polygon(v1, v2, v3);
    }
  }
  return rc;
 }

Das Ist jetzt zwar nur Pseudocode aber diesen habe ich getestet und er funktioniert auch soweit.
Das Problem, welches sich jetzt aber darstellt, kann ich nicht nachvollziehen, es geht darum, dass in den VertexBuffern (interleaved Arrays) sporadisch irgendwelche Texturkoordinaten (in Vertex verankert) nicht mehr passen und Texturen deswegen bei jedem Start der Anwendung mal korrekt und mal falsch angezeigt werden. Was ich aber bereits nachvollziehen konnte ist, dass dieses Verhalten nicht nur bei triangulierten Polygonen auftritt. Ist solch' ein Verhalten in LWJGL bereits bekannt?

 

[Marco13]

Das Problem, welches sich jetzt aber darstellt, kann ich nicht nachvollziehen, es geht darum, dass in den VertexBuffern (interleaved Arrays) sporadisch irgendwelche Texturkoordinaten (in Vertex verankert) nicht mehr passen und Texturen deswegen bei jedem Start der Anwendung mal korrekt und mal falsch angezeigt werden. Was ich aber bereits nachvollziehen konnte ist, dass dieses Verhalten nicht nur bei triangulierten Polygonen auftritt. Ist solch' ein Verhalten in LWJGL bereits bekannt?

Kommen in deiner Geometrie Vertices vor, die von ZWEI Dreiecken referenziert werden? (Klassisches Problem z.B. bei OBJ: Die Dreiecke
1//1 2//2 3//3
1//1 2//4 3//3
verwenden beide die Vertices 1,2,3, aber das eine verwendet Texturkoordinaten 1,2,3 und das andere 1,4,3 - d.h. ein Vertex hat zwei verschiedene Texturkoordinaten ... wenn man sowas beim Triangulieren nicht mit berücksichtigt, kommt man schnell in die Hölle...)

 

[Spacerat]

Kommen in deiner Geometrie Vertices vor, die von ZWEI Dreiecken referenziert werden?

Auf jeden Fall. Alle Polygone, die jemals von obiger Methode trianguliert wurden, teilen sich definitiv Vertices (glaube, das hat Triangulierung so an sich ). Texturkoordinaten werden sowie Normals bei mir in diesen Vertices per Polygonmap mit gespeichert. Ich glaube ich hab' schlicht vergessen, in den entsprechenden Vertices die neuen Dreiecke bekannt zu machen, deswegen fehlten auch einige Koordinaten. Aber warum würfelt LWJGL die restlichen Koordinaten den dann so durcheinander, statt einfarbige Flächen zu zeigen? Naja, was solls. Nun scheint es zu funktionieren.

 

[Spacerat]

Kann nicht anders, muss Doppelpost...
Hatte zwar gesagt, dass das soweit funktioniert, nun aber Level 2...
MultiTexturing mit VBOs. Dabei geht's nun nicht um die Texturen selber, sondern um die Texturkoordinaten (z.B. Bump-Offsets). In interleaved Arrays ist ja nur ein Kanal dafür verfügbar. Geh' ich recht in der Annahme, dass das mit dieser Art Buffer gar nicht geht? Wenn ja, wie mach' ich's dann?

 

[Marco13]

Auf jeden Fall. Alle Polygone, die jemals von obiger Methode trianguliert wurden, teilen sich definitiv Vertices (glaube, das hat Triangulierung so an sich )

jaja ... blabla... "mit unterschiedlichen Texturkoordinaten".. blabla ... Aber wenn's jetzt geht ists ja gut

EDIT: Den zweiten hatte ich nicht gesehen...

EDIT2: Wie man bei Interleaved mehrere TexCoords unterbringt... weiß Fancy bestimmt (ich finde ja einzelne Buffer praktischer, aber das kann man sich ja aussuchen)

 

[Guest2]

Hier ist das recht ausführlich beschrieben: OpenGL VBO Sample Code

(Davon ausgehend, dass die deprecated pipeline gemeint war. Bei aktuellem OpenGL würde sich die Frage ja gar nicht stellen.)

Viele Grüße,
Fancy

 

[Spacerat]

Davon ausgehend, dass die deprecated pipeline gemeint war. Bei aktuellem OpenGL würde sich die Frage ja gar nicht stellen.

Wie bidde? Ich weis ja bei dem ganzen VBO-Wust nicht mal, was aktuell ist und was nicht. Für mich stellt sich diese Frage also schon. Ich hätte keine Sorge damit, aktuell zu werden, dafür bräuchte ich aber mal ein paar funktionierende Beispiele ganz ohne "deprecated API" und auf keinen Fall mit ARB. Oder beschränkt sich die Aktualität etwa nur auf die Pointer (glVertexAttribPointer statt dem anderen Kram, wie oben beschrieben)?
Dann stellt sich auch noch die Frage, wie aktuell z.B. LWJGL mithält.
Man könnte ja sagen, dass ich mich erst mal wie ein Anfänger mit Grundlagen befassen sollte, aber in diesem Fall erwies sich das leider als nahezu tödlich, weil VBOs in Grundlagen kaum bzw. nicht sehr aktuell erschlagen werden. Herumexperimentieren, wie es bei einer Menge anderer Tutorials geht, bringts ja hier auch nicht, weil kleinste Fehler mit 'ner Exception statt einer fehlerhaften Ausgabe quittiert werden, weswegen man Fehler anfangs erst mal an komplett falscher Stelle sucht.
Trotzdem Danke für die Links, sie helfen doch sehr bei derartigen Experimenten.

 

[Evil-Devil]

Dann stellt sich auch noch die Frage, wie aktuell z.B. LWJGL mithält.

Aktuell ist LWJGL bis OpenGL 4.1 kompatibel. Das sollte aktuell genug sein

Sonst gibt es hier einen schönen LWJGL Port zu der Learning Modern 3D Graphics Programming Tutorial Serie. (OpenGL 3.3)
https://github.com/rosickteam/OpenGL

 

[Guest2]

Bei aktuellem OpenGL gibt es keine Unterscheidung mehr zwischen den einzelnen Vertexattributen. Es macht also keinen Unterschied ob Du Vertexkoordinaten oder Texturkoordinaten oder 42 rosa Schweinchen übermitteln willst, der Aufruf ist immer glVertexAttribPointer. Entsprechend kannst Du auch beliebig viele Texturkoordinaten übertragen.

glVertexAttribPointer arbeitet allerdings (imho) nicht mit der deprecated fixed function pipeline zusammen. Wenn Du komplett auf die deprecated API verzichten willst (imho sinnvoll), ist das Ganze ein wenig komplizierter, da alles, was OpenGL einfach machte, nun deprecated ist.

Man braucht dabei leider einfach eine gewisse Menge Code, ehe das erste Dreieck sichtbar wird. Z.B. müssen zwingend Shader verwenden werden. Auch alle OpenGL Matrix Funktionen sind deprecated.

Hier ist z.B. ein Beispiel, bei dem ein OBJ-File geladen und dargestellt wird. Die ForwardShading.java ist dabei zwar noch übersichtlich, mit den Tool Klassen läppert sich das allerdings (die liegen aber auch alle im repository).

Viele Grüße,
Fancy