3D-Grafik JOGL (lädt sehr lange)

[exilit]

Hallo zusammen,

ich will mit JOGL eine 3D Scene erstellen, die die mir einen würfel aus Kugeln Zeigt.
Sprich: Angenommen ich will mir einen 8x8x8 Würfel anzeigen lassen, dann will ich 8 Ebenen haben die jeweils aus 8x8 Kugeln bestehen(ich hoffe es wird klar was ich meine).

Ich habe das im moment mit 8x8x8=512 Vertices gelöst, aber das ganze lädt ewig lange und spätestens wenn ich es animieren will, kann ich aufgeben.

Gehe ich falsch vor oder woran könnte das liegen?

Den code kann ich im Moment leider nicht liefern, aber wenn da Bedarf besteht, werde ich den Nachliefern...

 

[Marco13]

Joa... wo kommen die Kugeln her, wenn du nur vertices hast?

 

[exilit]

Hmm du bringst mich gerade auf eine Idee.

Im Moment werden die in "display" in einer dreifach geschachtelten for-Schleife Erzeugt. Wäre sinnvoller, die einmal zu Initialisieren und in einem Array abzulegen oder?

 

[Marco13]

Womit die Frage nocht nicht beantwortet wäre... aber irgendwas mit Display-Listen (veraltet) oder VBO/VAO (neu!) könnte man da sicher machen. Und wenn eine Kugel dann nicht mehr als 100000 Vertices hat, sollte das auch mit der Geschwindigkeit kein Problem geben...

 

[exilit]

Ok danke,

ich schau erst mal. Habe im Moment keine Zeit, aber sobald ich mich bezüglich VBO/VAO schlau gemacht habe und das getestet habe werde ich mich nochmal melden.

 

[exilit]

Hallo nochmal,

habe nun etwas bezüglich VAO und VBO gelesen und habe nun auch ne Vorstellung, was das ist(auch wenn im Moment noch vage). Eventuell werde ich mich allerdings vorerst mit Display-Listen beschäftigen, einfach um das Verständnis für das Ganze noch etwas zu stärken.

Aber egal welchen Weg ich nehme, bei allen würde mich interessieren, ob ich die Technik(en) auch mit Quadrics anwenden kann (ich habe leider keine Ahnung, wie die Quadrics intern aufgebaut sind und weiß deswegen nicht, ob die genannten Verfahren damit funktionieren würden).
Der Grund wieso ich frage liegt darin, dass ich zu Beginn versehentlich gelogen habe und nicht Vertices für die Kugeln verwende, sondern eben die gluSphere.
Das ist natürlich deutlich einfacher aber eventuell auch nicht so performant wie wenn man es selber schreibt.?

P.S: QMarco13: nun verstehe ich auch erst deine Frage, wo die herkommen. Sorry.

 

[Marco13]

Ja, gluSphere ist an sich erstmal SEHR langsam... Kannst ja mal schauen, ob es was bringt, die in Display-Listen zu packen (bin zwa nicht 100% sicher, aber wüßte nicht, was dagegen sprechen sollte). Die in VBOs zu packen könnte dann aber ein bißchen fummeliger werden. Vielleicht findet man im Web was dazu, oder Fancy hat eine Idee... Ich hatte mir, wenn ich eine Kugel brauchte, immer die Daten, die mit Chapter 2 - OpenGL Programming Guide (Addison-Wesley Publishing Company) (ganz unten) generiert wurden, in ein VBO schreiben lassen.

 

[schalentier]

Grrr... ;-) Display Listen sind nicht veraltet! Keine Ahnung, woher das kommt, aber es ist Quatsch.

Fuer deine Kugeln waeren DisplayList wahrscheinlich super geeignet. Ungeeignet sind sie vor allem fuer sich veraendernde Objekte, da das Erzeugen einer DL relativ langsam ist (und zum Veraendern einer DL muss sie komplett verworfen und neu erzeugt werden).

Man kann uebrigens auch DL mittels VBO erzeugen. ;-)

 

[exilit]

Danke danke für die Antworten,

Sind Eigentlich VBO und VAO vom Prinzip her das gleiche und unterscheiden sich nur von der Datenstruktur oder sind das komplett unterschiedliche Herangehensweisen? im Prinzip kann ein Buffer doch auch ein Array sein und ummgekehrt oder nicht?

 

[Marco13]

Grrr... ;-) Display Listen sind nicht veraltet! Keine Ahnung, woher das kommt, aber es ist Quatsch.

Ja, dieses Schlagwort in der Klammer könnte was falsches suggeriert haben: Sie haben sicher noch Anwendungsgebiete, aber für reines Geometriespeichern (zwangsläufig spätestens wenn die Geometrie veränderbar sein soll - auch wenn das hier nicht erforderlich ist) würde man doch eher VBOs verwenden, oder...? (Faaaanncy....?!?! Klär' das mal )


EDIT: @exilit Für die Rolle und Bedeutung von VAO vs. VBO fand ich das hier ganz hilfreich: Vertex Array Object - OpenGL.org

 

[Kr0e]

Gibt es denn noch irgendwelche Vorteile gegenüber den neueren Alternativen in Bezug auf DisplayListen ?
Z.B. VBO hat den Vorteil flexibel zu sein, sind DL hingegen dafür schneller ? FALLS nicht, wüsste ich nicht warum man noch DL verwenden soll, wenn z.b. VBO keine Nachteile hat aber dafür nur Vorteile.

Aber wie gesagt "FALLS", ich wüsste das eigentlcih mal gern

Gruß,
Chris

 

[Marco13]

Ein bißchen Halbwissen, bevor der Meister© antwortet: Bei Displaylisten kann man auch "Server"seitige Zustandsänderungen zusammenfassen - inwieweit sich diese Möglichkeiten mit denen von VAOs überschneiden, müßte ich jetzt aber auch erst mühsam auseinanderdröseln...

 

[schalentier]

Gibt es denn noch irgendwelche Vorteile gegenüber den neueren Alternativen in Bezug auf DisplayListen ?

Vorteile hin oder her - es haengt vom Anwendungsfall ab. DL sind weder schneller noch langsamer als VBO. Sie sind einfach was voellig anderes.

Du kannst z.B. eine groessere Szene (oder einen Teil davon) in einer DL einfach "zwischenspeichern" und anschliessend sooft malen wie du magst. Dazu musst du im Gegensatz zu VBO nichts in irgendwelchen Buffern vorhalten, sondern du kannst alles ganz normal zeichnen, das quasi "aufnehmen", um es anschliessend sauschnell wieder abzuspielen.

Fuer den TO sind sie imho super geeignet, weil er keine Buffer erzeugen muss. Einfach das gluSphere in einer DL speichern und diese immer wieder aufrufen. Fertsch.

 

[Guest2]

Moin,

die aktuelle OpenGL Spezifikation weist alle den DisplayLists zugeordneten Funktionen als deprecated aus. Z.B.:

# display-list commands

NewList(list, mode)
return void
param list List in value
param mode ListMode in value
dlflags notlistable
category VERSION_1_0_DEPRECATED # old: display-list
version 1.0
deprecated 3.1
glxsingle 101
wglflags batchable
offset 0
[..]

Und damit sind sie schlicht veraltet (OpenGL 1.0 ist von 1992, OpenGL 3.1 von 2009 und die Aktuelle 4.2 von 2011). Natürlich kann (und vielleicht sollte) man aus didaktischen oder nostalgischen Gründen DisplayListen mal implementiert haben, zukunftsfähig sind sie aber nicht.

Ähnliches gilt auch für alle mir bekannten GLU Implementationen (z.B. für gluSphere).

Zwar haben alle Hersteller angekündigt auch die deprecated Funktionen weiterhin anzubieten, jedoch zeigt die Vergangenheit, dass Funktionen, die im kommerziellen Umfeld nicht (mehr) benötigt werden, von der Hartwareimplementation zur Softwareimplementation wurden. (Z.B. alle Matrix Funktionen der FixedFunction-Pipeline, selection mode, so gut wie alles was kein Dreieck ist, usw.)

Früher (zur FixedFunction Zeit) konnten DisplayListen (unter Umständen) besser optimiert werden als VBOs. Heute (FixedFunction ist deprecated) passen sie aber einfach nicht mehr ins Konzept. (Ob ein VBO schnell oder flexibel ist, hängt von den angegebenen Parametern ab)

Die Aktuelle OpenGL Spezifikation sieht VAO/VBO als einziges Mittel vor, um Vertex Daten zur Grafikkarte zu übertragen und dort zu halten.

Bei VAOs (Vertex Array Object) muss man aufpassen das diese etwas anderes sind als VAs (Vertex Array). VAOs sind reine Zustandsspeicher, VAs hingegen sind "vergleichbar" mit VBOs (nur anderer "Speicherort" der Daten). Der Link von Marco geht darauf ein.


Gruß,
Fancy

(

..bevor der Meister© antwortet..

lol, ich weis aber auch nicht alles )

 

[schalentier]

Okay, dann hab ich Sche*ss erzaehlt ;-)

Aber ich find DL trotzdem toll, halt weil die so schoen einfach sind

 

[exilit]

Okay, dann hab ich Sche*ss erzaehlt ;-)

Aber ich find DL trotzdem toll, halt weil die so schoen einfach sind

hauptsache man kann sich Fehler eingestehen xD.

Natürlich kann (und vielleicht sollte) man aus didaktischen oder nostalgischen Gründen DisplayListen mal implementiert haben

Und genau das will ich vorerst mal machen(denke ich). da VBO's doch etwas komplizierter sind und ich in dem Dschungel von VBO, VAO, VA und so weiter im Moment nciht durchblicke ist das erst einmal sicherlich eine nicht schlechte Idee...

 

[Marco13]

Bei VAOs (Vertex Array Object) muss man aufpassen das diese etwas anderes sind als VAs (Vertex Array). VAOs sind reine Zustandsspeicher, VAs hingegen sind "vergleichbar" mit VBOs (nur anderer "Speicherort" der Daten).

Inwieweit wäre darauf bezogen meine Andeutung angebracht, dass VAO die Zustandsänderungen abdecken sollen, die früher mit DLs abgedeckt wurden? Vermutlich sind sie nicht deckungsgleich, aber haben doch einen ähnlichen Zweck, oder?

 

[exilit]

So ein kleiner Erfolgsbericht meinerseits an dieser Stelle,

mit einer DL und gluSphere für die kugeln funktioniert es jetzt wunderbar.
Allerdings werde ich eventuell doch auf eine der nicht-deprecated Methoden ausweichen müssen, da ich unter Umständen zur Laufzeit Änderungen vornehmen muss.

 

[schalentier]

Inwieweit wäre darauf bezogen meine Andeutung angebracht, dass VAO die Zustandsänderungen abdecken sollen, die früher mit DLs abgedeckt wurden? Vermutlich sind sie nicht deckungsgleich, aber haben doch einen ähnlichen Zweck, oder?

Hab mich mal noch ein bisschen belesen.

Ein VAO (Vertex Object Array) beschreibt letztlich, was sich in einem oder mehreren VBOs befindet. Z.B. also, dass man einen Buffer verwendet, bei dem abwechselnd Koordinate, Texturekoordinate, Farbe und Normale vorkommen. Ohne VAO muss man OpenGL das mit Methodenaufrufen mitteilen (glVertexArray, glColorArray, ...). Mit dem VAO spart man sich also diese Aufrufe und bindet stattdessen ein VAO vor dem glDrawArrays.

Eine DisplayList war urspruenglich quasi als Macro angedacht. D.h. alle OpenGL Befehle innerhalb einer DL werden gesammelt und anschliessend beliebig oft abgespielt. Wenn ich das richtig verstanden habe, koennte man sogar die Texture wechseln, innerhalb einer DL. Das wird aber nicht empfohlen.

Im Endeffekt kann ich mir vorstellen, wird vom Treiber aus der DL eine Reihe von VBO mit entsprechenden VAO generiert, die dann nacheinander gerendert werden. Den Vorteil von DL seh ich uebrigens vor allem darin, dass ich vorher nicht wissen muss, wieviele Dreiecke ich gerne rendern moechte. Bei VBO muss ich einen entsprechend grossen Buffer bereitstellen, oder diesen mitwachsen lassen (langsam). Bei DL is das voellig egal, macht der Treiber oder die Graka.

 

[Kr0e]

Im Endeffekt kann ich mir vorstellen, wird vom Treiber aus der DL eine Reihe von VBO mit entsprechenden VAO generiert, die dann nacheinander gerendert werden.

Genau das schwirrte mir auch noch im Kopf rum... Meine das mal iwo gehört zu haben.

 

[Guest2]

Ja, das geht schon alles in die richtige Richtung. Display Listen hatten ihren Höhepunkt als der ganze Schmu noch als T&L (transform and lighting) bezeichnet wurde. Das die ganze Pipeline damals starr und unflexibel war hatte den Vorteil nicht nur Zustände, sondern auch Daten vorbereiten / zwischenspeichern zu können. Mit den ersten programmierbaren GPUs wurde das aber schwieriger / hinfällig.

Bei VBOs ist der Ansatz hingegen den "Kontext"-Switch zu vereinfachen (ggf. pipeline stalls zu reduzieren). Grundsätzlich ist es so, dass jede Umkonfigurierung der Pipeline relativ teuer ist. Über VBOs die an VAOs hängen, lassen sich relativ leicht "Einheiten" bilden, die alle notwendigen Daten der Vertices bereitstellen können und zwischen denen "relativ" schnell umgeschaltet werden kann. Das hilft dem Treiber auch Optimierungsmöglichkeiten zu finden, geht aber nicht so weit, wie es mal bei FixedFunction und DisplayListen möglich war. (Auch bei VAO gilt weiterhin, dass man seine Renderschleife so sortieren / aufbauen sollte, dass es zu möglichst wenig Zustandsänderungen kommt.)

Spannend wird das auch wenn DSA (direct state access) ins Spiel kommt. Ansätze sind bereits in der aktuellen Spezifikation vorhanden, es fehlt aber wohl auch noch einiges. Durfte dazu führen das vieles, was heute gut ist, dann bald schon wieder deprecated ist .

(Ob und gar welche Treiber eine DisplayListe in ein VBO umbauen, kann ich nicht sagen. Wäre aber gut möglich.)

Gruß,
Fancy