Hallo zusammen,

nach ewigen Zeiten bastele ich auch mal wieder an meinem Projekt herum und habe gerade zaghafte Gehversuche mit Displaylisten gemacht. Ehrlich gesagt war ich erstaunt das es auf Anhieb geklappt hat

Das Projekt ist im Grunde nichts weiter als ein 3D Viewer in den sich der Benutzer Modelle laden kann.
Nix aufregendes mit Animation, keine Texturen, reine Geometrie.
Problem: Es können sehr große Datenmengen sein. (größte Testmodell zur Zeit 800MB)


Ich habe bisher mit Vertexarrays und Normalarrays gerendert...
Also etwa so:




Hier fangen auch die Fragen zu Displaylisten an:

Ich hatte zunächst mehrere hundert Displaylisten generiert um die Modelle darzustellen, jedoch fehlten dann plötzlich eine Vielzahl der Modelle in der Szene, also habe ich versucht alles in eine einzige riesige Display Liste zu ziehen, mit dem Ergebnis das ich eine Access Violation bekomme, weil wohl mein VRAM überläuft..

Nun die Fragen:

1.) würde mir das selbe mit VBO's auch passieren? Denn wenn ichs richtig verstanden habe, belegen die ja letztlich auch VRAM.

2.) Wenn ich bei DisplayListen bliebe, wie würde eine VRam überwachung grob aussehen? Also wie stelle ich sicher das ich da nix zum Platzen bringe?

3.) und nochmal im Vergleich zu VBO's.. das compilen der DisplayListen dauert ja ne ecke.. (bei meinem Test ca. 3x so lange wie ein normaler rendervorgang ohne Displaylisten) ist das beim schreiben der VBO's auch so?

Danke schonmal

Nein, VBOs können auch in den normalen Arbeitsspeicher wandern wenn der VRAM ausgeht. Das wird dann aber natürlich sehr langsam, da dort die Bandbreite sehr viel geringer ist.


Gar nicht. Es gibt zwar herstellerspezifische Extensions für die VRAM-Auslastung zu messen, die dann aber nur auf bestimmten Karten verfügbar ist. An sich gibt es aber generell keine Möglichkeit zu erkennen wieviel VRAM eine Displayliste braucht, zumal sich das sogar von Treiber zu Treiber unterscheiden kann. Du kannst natürlich grob rechnen, also Anzahl Vertices * Elemente pro Vertice * SizeOf(Single) + 15% Overhead o.ä. Aber exakt ermitteln wie groß eine DL ist und wieviel Platz im VRAM ist wird schwierig.


Nein, bei VBOs schiebt man ja nur die Vertexdaten in den VRAM. Wenn man eine Displayliste erstellt zerlegt der Treiber die ja in eine für die GPU optimales Format. Die Vertexdaten einer Displayliste werden zwar auch als VBOs abgelegt, aber beim Hochladen wird die DL zerlegt und entsprechend der Kommandos in einer optimierten Form mit VBOs abgelegt. Ein Kompilieren wie bei der DL gibts es bei den VBOs also nicht.

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

Danke für die Antworten,

dem entnehme ich das Displaylisten in meinem Fall unbrauchbar sind, da ich schlicht keinen Einfluss habe wie groß die Modelle werden die ein Benutzer lädt oder welche Hardware er drin hat und will das auch nicht deckeln.

blieben VBO's aber an denen bin ich schon mehrfach gescheitert bzw verzweifelt... - das die dann ab langsam werden, damit könnte ich leben, zur zeit ist es ja bei großen datenmengen auch langsam. Nur abstürzen mit ner Access Violation, so wie die Displaylisten oder einfach die Hälfte weglassen ohne Fehlermeldung, das geht natürlich nicht.


Ich hab noch nen Haufen andere Punkte auf dem Zettel, die arbeite ich erstmal ab, wenn das alles fertig ist versuch ich vielleicht nochmal mit VBO's.

Ich bin in sofern angefixt als es mir mit displaylisten gelungen ist bei einer ebenfalls sehr großen datenmenge die wohl aber noch in den VRam passt die fps von 2 auf 180 zu bekommen..

die "üblichen" Datenmengen die ich so erwarte haben aber ohnehin fps > 100 - aber bei richtig elend großen datensätzen wirds halt rucklig.

Hallo ..

habe mich vor kurzem auch mit VBOs beschäftigt. Ich kann Dir das glVBO von lossy empfehlen. Das schafft mehr Übersicht.

Gruss Jens

Vielen Dank, ich steck noch immer bis über beide Ohren in anderen Dingen..
kann mich also nach wie vor nicht damit beschäftigen.

Aber so eine Sache wurmt mich doch:
Worüber ich immernoch grübele ist wieviele VBO's erstellt man? gibts ne Grenze?
Mach ich einfach für jedes Bauteil für das ich bisher ein VertexArray ein NormalArray und ein IndexArray hatte ein VBO? Oder muß alles in ein VBO geballert werden?

In der Tat weiß ich darauf keine Antwort weil ich in den Tutorials immer nur 1 VBO gesehen hab, zumindest bis zu dem Punkt wo ich dann frustriert den Rechner runtergefahren habe.

Nein, man muss nicht alles in ein VBO packen. Zumal das je nach Materialverwaltung ja auch garnicht möglich ist, wenn man z.B. für zwei verschiedene Objekte unterschiedliche Shader oder Texturen braucht. Spätestens dann muss man ja unterteilen.

Wie genau man hier unterteilt hängt dann wie gesagt von deiner Materialverwaltung und der optimalen Batchgröße für die Zielhardware ab. Hier muss man also ggf. mit der größe der VBOs experimentieren. Zu klein (20 Vertices o.ä.) sollten sie natürlich nicht sein, evlt. fängst du einfach mal bei 1.000 Vertices an und schaust dann wo der optimale Performancepunkt liegt.

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

Danke,

das hilft mir schonmal weiter! Ich kann also viele VBO's haben.. ich glaube das war in der Vergangenheit mein Hauptdenkfehler, ich hatte iwie immer versucht alles in eins zu bekommen.

Texturen und Materialien habe ich nicht bei mir geht es um reine technische Daten, die haben ne Farbe, das wars auch schon.

sieht zur Zeit etwa so aus:

http://screencast.com/t/dtxwtEzG8M

aber was der Benutzer lädt und was er für nen Rechner hat, liegt nicht in meinem Einfluss.

Hallo, ich habe mir das gerade angeschaut und komme zur ersten grundlegenden Frage. Dazu eine kleine Geschichte:Bei meinen Dreiecksdaten hat jedes Dreieck 3 Vertices und 3 gleiche Normalen.. Beim Versuch das zu optimieren und jedem Dreieck nur 1 normale zu geben (weil is ja immer gleich) bin ich schonmal gegen die Wand gelaufen, als ich ganz am Ende feststellen mußte das sich das mangels zweitem indexarray nicht rendern lies.
Ziemlich gefrustet habe ich dann meine schön optimierten Daten eben wieder aufgeblasen, also wurde aus

Dreieck (V1,V2,V3,N1) wieder (V1,V2,V3,N1,N1,N1); So rendere ich bis heute, mit einem unnötigen ballast von 2*3*4 bytes...

Jetzt stehe ich mit VBO's vor der selben Frage und habe sowas hingetippt:



für mein Verständnis (was ja gern mal falsch liegt) ist das genau was ich will, 3 Vertices und 1 Normale... Die Frage lautet, lässt sich mit dem magischen VBO Zeugs das dann auch rendern?

und nein, die Frage ist kein Aprilscherz..

edit... die Frage hat sich wohl schon erledigt, bzw glVBO hat sie mir beantwortet:

Nein, das ist nicht möglich. Eine Displayliste macht auch nichts anderes, sie würde die Normale einfach dreimal speichern. Du könntest allerdings potentiell Flat-Shading für die Normale nutzen. Dann wird einfach die Normale des ersten (oder letzte) Vertex eines Dreiecks benutzt. Kannst du via glProvokingVertex (ab OpenGL 3.2) einstellen. Flat-Shading aktivierst du via "flat" attribut für das entsprechende Varying der Normale im Shader.
Wenn OpenGL 3.2 keine Option ist, kannst du dir mal glShadeModel anschauen. Ich bin mir aber nicht sicher ob die Funktion überhaupt mit Shadern zusammen arbeitet. Klingt sehr nach fixed-function.

Natürlich muss auch bei Flat-Shading weiterhin jeder Vertex eine Normale haben, ABER via Indexbuffer kannst du die Vertices mehrfach benutzen und die Indices zu setzen das jeweils die korrekte Normale benutzt wird. Ich habe zugegebenerweise gerade keine Ahnung wie man ein Mesh automatisch entsprechend aufbereitet.



Eine Alternative Lösung wäre ein Geometry-Shader. Dann braucht der VBO einfach gar keine Normale. Da du im Geometry-Shader Zugriff auf die drei Vertices jedes Dreiecks hast, kannst du die Normale einfach zur Laufzeit via Kreuzprodukt im Shader berechnen.

_________________
Yeah!