Moin ich mal wieder. Und schon wieder mit dem selben thema. (Tut mir fast schon leit)

Hab nu alles mit Display listen programmiert.

Bei Modellen mit etwa 10.000-20.000 Dreiecken kein Problem.
Aber wenn meine Engine nu ein Object mit etwa 100.000 Dreiecken hochlädt und auf den Grafikspeicher schreibt, verbraucht das meinen gesamten Grafikspeicher + über 350 mb ram
Obwohl das Model auf der Festplatte abgespeichert nur 95 mb ram einnimmt.
Das ist mal nicht sehr schnell..

Liegt das daran, dass bei Displaylisten nicht nur die Punkte, Farben usw sondern auch die Tatsache, dass es sich um Punkte Farben usw handel, auf den Speicher geschrieben werden ???
Ich kann mir nicht vorstellen, dass das so viel speicher verbraucht.

Aber falls dass so wäre müssten VBOs ja viel Platzsparender sein, da sie die floats ja einfach hintereinander wegschreiben.

Falls ich irgendwas anderes völlig falsch gemacht haben sollte, ist hier der denke ich entscheiden Kodeteil:



Einige details sind da sicher unverständlich, aber vielleicht erkennt mann ja irgendwat.[/code]

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

Normalerweise sollte ein guter OpenGL Treiber automatisch gebatchte glVertex, glColor u.ä. Kommandos erkennen, und daraus automatisch ein "optimales" Modell erstellen - im Idealfall sogar besser als statische VBOs, da der Treiber eher wissen sollte was performant dargestellt werden kann, als der Programmierer eines VBOs, der sicher stellen muss, dass das Ganze auf allen Grafikkarten läuft.

In deinem Fall ist es so, dass du mit VBOs und glDrawElements Vertex und Indextabellen verwendest (im Gegensatz zu glDrawArrays), was natürlich speicherschonender ist, als sämtliche Dreiecke in eine DL zu packen. Wenn du keine VBOs nehmen möchtest, solltest du glDrawElements mit Vertex Arrays verwenden, und die Aufrufe in Displaylisten packen (und hoffen dass der Treiber halbwegs intelligent programmiert ist). Der Speicher für die Vertexdaten kann nachher freigegeben werden.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

95 MByte auf der Platte? Was speicherst du denn da alles mit?

Kurze Rechnung :


Ergibt für mich ~ 12 MByte (die Werte oben sind gerundet). Das passt dann als DL locker auf die Graka (solange du nicht zu viel an Texturdaten hochlädst, was dann bei nem VBO aber auch Probleme macht) und ist weit weniger als deine 95 MByte. Frage mich also grade woher du deine Größen holst?

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

Sorry das war ungenau: ab dem 100.000 Dreiecke Modell gings stark in die Knie. Das 95mb Model hatte noch ein par mehr Dreiecke ( so 1.111.000 oder son blödsinn) und wurde schlicht nicht mehr geladen (oder ich hab nie lange genug gewartet).


Is auch egal. Habs jetzt auf VBOs umprogrammiert!!! Hat zu meiner überaschung auch sehr schnell funktioniert.
Habe dazu erstmahl vorgefertigte Vertextypen genommen (GL_T2F_N3F_V3F) und (GL_N3F_V3F).




Das hochladen müsste stimmen, funktioniert auch schon bei sehr viel höheren Dreieckzahlen als vorher!
aber auch hier wird bei einem 15-20 mb model (auch wenn ich so watt eigentlich nicht brauchen werde) der Arbeitsspeicher sehr stark mitbeansprucht!!! (Woran liegt dass???)
Ausserdem treten dann sehr starke Fehler im geladenen modell auf (alle zählvariablen sind integer oder longint) bzw die Punkte sind ab einer bestimmten zahl dreiecke einfach falsch verbunden.Hatt eine VBO da irgendwelche Mengenbegrentzung oder do??

Aber abgesehen davon läufts schon besser als mein Verwendungszweck das erfordert.

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

Sag doch mal was zu deiner Hardware, ohne Infos welche Graka du überhaupt nutzt kann man nicht viel zum Thema sagen. An sich darf ein VBO laut GL-Spezifikationen eigentlich keine Beschränkung besitzen (zumindest in Sachen Größe), und sollte es nicht mehr auf den VRAM passen wirds in den Hauptspeicher ausgelagert. Warum dein Modell so viel Hauptspeicher verbraucht kann ich dir nicht sagen, aber evtl. gehst du nicht korrekt mit deinen Zeigern um. Ausserdem löscht man die Daten normalerweise aus dem Hauptspeicher sobald das Modell als VBO erstellt wurde, es sei denn man braucht die Daten noch für andere Zwecke (z.B. Kollisionsabfrage).

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

Also meine Grafikkarte ist ne geforce 5700 fx von msi mit 256 mb vram.
(512 mb 333 ddr ram / AMD 2400+ / 400er MSI Mainbord)
und die Modelle lade ich garnicht in den ram, sondern diereckt in die VBO übern filestream.
Hm, ansonsten guck ich den Kram morgen noch mal durch.
aber an sich hab ich alle Schleifen und so schon überprüft, ob die zu oft durchlaufen oder so.

Eigentlich müsste die VBO also genau so viel platzt wegnehmen wie das Model als datei auf der Festplatte oder?
Ich speicher ja schließlich im selben Format, mit dem die VBO auch arbeitet.

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

Oh, ich hatte bisher nur versucht, ein model zu laden und dass an mehreren positionenen usw zu rendern.

Wenn ich nun mehrere modelle mit der "engine" (oder was mahl eine werden soll) zu laden, kommt es zu problemen, sobald ich in der scene modelle mit und ohne texturen vermische (sind ja auch zwei unterschiedliche vertextypen, was ich aber eigentlich überall berücksichtigt habe) naja da muss also noch das eine oder andere Fehlerchen drin stecken...

gibt es eigentlich bestimmte treiber, die besonders zu empfehlen sind, oder tuts eigentlich jeder halbwegs neue detonator???

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

Oh meine Treiber sind Detonator 61.11 vom 29.04.2004 macht das was? müsste sonst c.a. 20mb mit nem modem ziehen

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

Nutze zwar keine NV-HW, aber aktuell (nicht beta, da gibts neuere) sind die 61.77er, also ein Treiberseit aus dem gleichen Zweig. VBOs laufen auf NVidia aber bereits seit geraumer Zeit problemlos.

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

Hab jetzt alle Probleme nehoben, war im wesetlichen eine vertauschte Laufvariable (i2 statt i .
Aber der Arbeitsspeicherverbrauch bleibt beim Laden größerer VBOs.
Wobei auch kleinere schon etwas platzt auf dem ram nehmen.
Der Arbeitsspeicher wird auch wieder Freigegeben, sobald ich die VBOs wieder Lösche per glDeleteBuffersARB(1, @...); !

Ist das jetzt normal??? Oder muss da imernoch ein Fehler sein?


Und wieso kann ich im programm "GL_ARB_Vertex_Buffer_Object" im Quelltext keine Zeile rot markieren, um mir die Variablenwerte u.s.w. anzugucken???

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

Ich hab zwar noch nicht mit VBOs gearbeitet, aber ich denke mit Arbeitsspeicher ist der RAM gemeint, den deine Models einnehmen.
Du lädst das Model und liest die Vertexe aus. Die schickst du dann zur GraKa. Du hast dein VBO.
Am Ende solltest du halt den FileStream und das Model freigeben. Es kann natürlich sein, dass du gleich beim Lesen aus dem Stream die Daten zur GraKa schickst. Dann wirst du wahrschinlich kein Model mehr freigeben müssen.


Wahrscheinlich ist der Debugger aus. Guck mal in den Projekteinstellungen unter Compiler.