Effektive Implementierung für Darstellung großer Datenmengen in Jogl

[Beowölfchen]

Hallo,

ich möchte mit Jogl ein Höhenprofil darstellen, dass in jeder Achsenrichtung maximal 400 Einheiten einnimmt. Zudem sollen 4 unterschiedliche Höhenbereiche mit unterschiedlichen Texturfarben gekennzeichnent werden.

Mein Ansatz ist folgender:

Ich durchlaufe die x-z-Ebene und baue bei jeder Koordinate einen GL-Cube bis zu der Grenze des Höhenbereiches oder der Höhe, die ich angeben will. Wenn der Turm sich also über mehrere Höhenbereiche ersteckt, dann baue ich erst einen für den untersten Bereich, dann für den Nächsthöheren mit der Farbe für den Bereich usw.

Das Problem ist, dass diese Erstellung sehr viel Rechenzeit in Anspruch nimmt und ich dann beim Start der Applikation und bei Bewegung der Perspektive sehr lange warten muss, bis das Bildneu aufgebaut ist.

ich habe schon versucht zu optimieren, indem ich die nicht sichtbaren GL_Cubes gar nicht zeichne, aber das hat nicht viel geändert...

Ich hab im Netz mir schon so einige Beispiele für Landschaftsprofile angeschaut. Es geht hier nicht um die sanften Übergänge in eine hügeligen Landschaft, sondern eher und schematische Darstellungen. Dir Grenzen der Höhenbereiche mussen also scharf sein und ebenso der Übergang zwischen den benachbarten Würfeln.

 

[Marco13]

Sooo spezifisch kann ich da nicht werden, aber...: Die vorgefertigten Cubes von GLUT oder diese quadrics zu verwenden ist definitiv langsam. Alternativen wären - je nach GL-Version - erstmal "Display Lists", aber besser (vieeel effizienter, aber auch schwieriger zu verwenden) Vertex Buffer Objects bzw Vertex Array Objects.

Fancy hat da bestimmt ein passendes Beispiel für dich

 

[Beowölfchen]

Alternativen wären - je nach GL-Version - erstmal "Display Lists", aber besser (vieeel effizienter, aber auch schwieriger zu verwenden) Vertex Buffer Objects bzw Vertex Array Objects.

Wenn dann will ich das auch richtig machen! Also wäre ich für Vertex Buffer Objects...
Danke für den Hinweis Marco13! (Mit Stichwörtern googlet es sich einfacher )

Wenn Fancy mir ein Beispiel geben könnte, wäre es bestimmt nicht schlecht.

Vielleicht finde ich auch Zeit aus meinen Erkenntnissen ein Tutorial zu machen. Ich finde Jogl an sich sehr interessant, weil man da Ruckzuck nen Applet draus machen kann und dann braucht der Client nur noch JRE und - schwubs - da hat er ne 3D-Ansicht über den Browser (eigentlich Java-Webstart) gestartet.

 

[Marco13]

Ja, du kannst dir mal die Beispiele ansehen, die in http://www.java-forum.org/spiele-mu...4013-jogl-problem-darstellung.html#post597300 oder http://www.java-forum.org/spiele-mu...rfel-hat-durchsichtige-seiten.html#post610603 verlinkt sind. Sind ein guter Einstiegspunkt.

 

[Guest2]

Moin,

die vorgefertigten geometrischen Körper aus GLU und GLUT sind nie eine gute Idee. Die sind nicht nur langsam, sondern in den meisten Fällen auch unvollständig. Entweder sind die Normal- oder die Texturkoordinaten nicht definiert. Imho der einzige sinnvolle Körper davon ist glutSolidTeapot, da sind dann sowohl die Normal- als auch die Texturkoordinaten definiert. Allerdings ist dafür da die Orientierung der Dreiecke falsch (im Uhrzeigersinn statt dagegen).

Grundsätzlich ist es also eine gute Idee alles selber aus Dreiecken zusammen zu bauen. Das Stichwort um große Mengen Dreiecke in einem "rutsch" darzustellen hat Marco ja bereits erwähnt, Vertex Buffer Object (VBO). Eine etwas einfachere Variante davon wäre das Vertex Array (VA), dabei wird vom Prinzip her die selbe Datenstruktur wie beim VBO verwendet, jedoch werden die Geometriedaten nicht im Speicher der Grafikkarte sondern im Hauptspeicher untergebracht. Die beiden Beispiele die Marco verlinkt hat nutzen auch VAs. Man sieht das z.B. am letzen Parameter von glVertexPointer, beim VA ist dort ein Buffer, beim VBO ein int.

Bei beiden gibt es dann nochmal die Unterscheidung ob die Dreiecke ohne Index im Buffer liegen (x, y, z, x, y, z, x, y, z, x, y, z, …) oder mit Index (x1, y1, z1, x2, y2, z2, …) und einen Buffer der Indices (1, 2, 3, 1, 3, 4, …). Mit Indices verbraucht dabei weniger Speicher und ist schneller, dafür kann der Aufbau der Datenstruktur fummeliger sein. Ohne Indices wäre das dann glDrawArrays, bzw. mit Indices glDrawElements.

Ein Vertex Array Object (VAO) ist wieder etwas anderes und liegt eine "Ebene" drüber. Dies nimmt normalerweise ein VBO auf und speichert dessen Zustand, dadurch sind später beim darstellen weniger OpenGL Aufrufe notwendig.

Die Möglichkeiten sind also vielfältig.

Die Beispiele die Du im Netz zu Höhenprofilen gefunden hast, basierten wahrscheinlich auf einem festen XZ Gitter bei dem lediglich der Y Wert aus dem eigentlichen Höhenprofiel kam. Wenn Du bei Dir jetzt senkrechte "Wände" haben möchtest, bedeutet das im Wesentlichen, dass auf einem XZ Punkt mehrere Vertices senkrecht übereinander liegen können. Das erstellen des Gitters könnte deshalb etwas fummelig werden. Allerdings muss dies nur einmal beim Start der Anwendung berechnet werden, anschließend sollte die Geometrie als Konstante im Speicher der Grafikkarte liegen.

Sollte das Höhenprofiel in sich dynamisch sein, würde sich der Geometrie Shader anbieten. Der könnte dann relativ elegant die zusätzlich notwendigen "Wände" an den Seiten der "Hügel" einfügen, so dass man wieder mit einem einfachen XZ Gitter arbeiten könnte (es währe wieder nur ein Vertex pro XZ Punkt notwendig). (Kann man natürlich auch so machen wenn das Höhenprofil statisch ist )
Allerdings muss dazu die Grafikkarte des Zielsystems Geometrie Shader unterstützen.

Gruß,
Fancy

 

[Beowölfchen]

Die Umsetzung mit Vertex Buffer Array ist fertig und funktioniert einwandfrei. Ist echt ein enormer Geschwindigkeitsvorteil.
Vielen Dank.