Hallo,

Ich habe angefangen einen OBJ-Loader zu schreiben und möchte nun die geladenen Models in annehmbarer Geschwindigkeit darstellen.
Das Problem ist, dass ich einen Haufen Triangles und Quads bekomme, die nicht zwangsläufig zusammenhängend sind.
Diese können in einer .obj Datei in Gruppen aufgeteilt sein.

Ich tue beim Laden also folgendes:

• Vertices und Normalen auslesen
• Gruppen ermitteln
• Faces auslesen und den Gruppen zuordnen
• Für alle Gruppen:
  • Erstelle Displaylist
  • Für alle Faces:
    • Zeichne

Und beim Zeichnen gehe ich halt alle Gruppen durch und rufe deren Displaylisten auf.

Das Zeichnen ist allerdings (trotz Displaylisten) zum Teil recht langsam, liegt das an den vielen Displaylisten?
Octrees als Optimierung werde ich noch einbauen. Soll ichs da so machen, dass ich für jede Gruppe eine Boundin-Box erstelle und die dann Prüfe, bevor ich mich den einzelnen Faces zuwende? Ich denke das könnte ganz gut funktionieren.
Eigentlich Problem ist aber dass ich das Modell eigentlich die meiste Zeit komplett im Sichtfeld habe, ergo bringen mir Frustrum Culling und Octrees nicht so viel, was kann ich sonst tun?
Ich habe mir andere Programme angeschaut, die OBJ Dateien laden und die schaffen es diese schneller darzustellen.

Maximale Geschwindigkeit werde ich aufgrund der Benutzung von Java wohl nicht erreichen können, aber ich denke da geht noch ordentlich was

Vielen Dank,

mfg

Wieviele Displaylisten hast du denn pro Model? Und warum spielt es eine Rolle ob sie zusammenhängend sind oder nicht?

Versteh' ich das richtig das du für jedes Primitive einen Sichtbarkeitstest machen willst? Das wäre wohl eher langsam. OcTrees lohnen sich meistens nur wenn auch in den Blättern noch einige Vertices sind. Sonst dauert der Sichtbarkeitstest länger als das Zeichnen. BoundingBoxes sind wahrscheinlich ganz gut, aber der Baum darf eben wie gesagt nicht zu tief sein.

Ich denke für VBOs und Displaylisten gilt dass es schneller ist ein paar Dreiecke mehr zu zeichnen, wenn man dafür einen DrawCall einspart. "Ein paar" können dabei auch gut ein paar hundert werden. Für Trianglesstrips gibt es da zum Beispiel auch die Möglichkeit von degenerierten Dreiecken.

Wenn die Dreiecke zusammenhängend wären, dann könnte ich Triangle_Strip benutzen.
Und den Sichtbarkeitstest hatte ich pro Gruppe gedacht und je nach Anzahl vielleicht auch höher aufgelöst bis zu einer gewissen Grenze natürlich.
Ich habe 80 Groups, also auch 80 Displaylisten, das könnte wirklich ein bisschen viel sein. Nur bietet sich mir so die Funktionalität, einzelne Gruppen auszublenden.

Also Indices sind einfacher zu handhaben als Triangle_Strip und sparen bei einem "normalen" Mesh schon mal ca. 80% der Vertices ein. Dafür muss man aber natürlich auch den Indexbuffer speichern, der aber mit 12 Byte pro Dreieck aber vergleichweise klein ist. Wenn du sowieso schon Indices verwendest, kannst auch auch gleich VBOs benutzen.

Um nicht 80 Displaylisten zu verwalten könntest du auch einen einzigen VBO benutzen bei dem sich einfach alle Gruppen nacheinander im Speicher befinden. Auch im Indexbuffer befinden sich alle Gruppen hintereinander im Speicher. Über glDrawRangeElements kannst du dann Bereiche angeben die gerendert werden sollen. So kannst du Gruppen die sich hintereinander im Speicher befinden in einem Rutsch rendern.

_________________
Yeah!

Meine Objekte bestehen ja aus Triangles und Quads, was ist nun besser: Die Quads in Triangles zerlegen und zusammen ablegen oder ein eigenes VBO für die Quads anlegen? Zweiteres würde die Sache mit den Gruppen so ein wenig kaputtmachen.


mfg

Die Grafikkarte kann eh keine Quads, sondern nur Dreiecke. Zerlege also deine Quads jeweils in zwei Dreiecke. Wenn du Indices verwendest geht das sogar ohne Overhead.

_________________
Yeah!

Das Problem was sich mir momentan auftut scheint mehr ein Java-spezifisches Problem zu sein, folgende Zeile:


führt zu folgendem Fehler:

Mein Buffer sieht so aus:


Oder muss ich die Funktionen mit ARB am Ende benutzen?

Vielleicht ist bei glBufferData die Größe nur in Floats und nicht in Bytes. Bytes wären für Java auch untypisch. Einen Versuch ist es Wert

_________________
Yeah!

Scheinbar leider nicht Ich habs so übernommen wie es in den NeHe Tutorials steht und dort wurde es so gemacht.

Was ist den das für eine OpenGL-Version?

_________________
Yeah!

Soweit ich weiß verwendet JOGL standardmäßig einen OpenGL 2.0 Context (ob 3.0 überhaupt unterstützt wird, weiß ich nicht) und dort wurden AFAIR viele der ARBs fest integriert und das ARB Kürzel weggelassen, die alten Namen wurden aber zur Abwärtskompatibilität behalten. Glaube ich zumindest ^^ sonst würde es da wohl einen Unterschied geben (auch was den Hardware Support angeht).

mfg

Interessanterweise ist ein Delphi Quellcode den ich hier hab, der das selbe Model ebenfalls mit einer Displaylist zeichnet schneller und kann zusätzlich noch Schatten etc. anwenden.

Mal abgesehen davon, dass ichs noch nicht zum laufen bekommen habe, wie mache ich das mit dem Indexbuffer? Die Normalen brauchen ja auch noch irgendwie nen Buffer.