Registriert: Sa Jan 01, 2005 17:11 Beiträge: 2068
Programmiersprache: C++
Zitat:
Wenn range gleich Null ist, oder nicht mehr genug freie Namen für die, via range angegebene, Listenreichweite vorhanden sind, oder ein Fehler generiert wird, werden keine leeren Displaylisten erstellt und es wird 0 zurückgegeben.
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7810 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Als erstes landen die DL im Grafikram. Wenn der voll ist kommt erst der RAM. Da is also enorm viel platz. Und solltest du doch mal alles zu bauen: siehe IONIS thread.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
ich hatte ein ähnliches Problem. Meine Engine habe ich voll auf DisplayListen getrimmt. Beim Darstellen eines großen Grids mittels eines Octree's, von denen jedes Ende eine Displayliste erzeugt, wuchs der verbrauchte Speicher ganz schnell auf 280 Megabyte (inklusive der Daten des Programmes).
Ein großer Nachteil bei DisplayListen ist der, das du sie nicht wirklich zur Laufzeit wieder löschen kannst. Ob ein glDeleteLists den Speicher nämlich wirklich sofort freigibt, bleibt der OpenGL-Implementation überlassen. Da ich in meinem Projekt jedoch den Fall habe, das alle Octree-Enden dargestellt werden müssten, sind DisplayListen ungeeignet wegen des Speicherverbrauchs. Die allermeisten OpenGL Implementationen geben den Speicher erst wieder frei, wenn der dazugehörige Prozess beended wird, und nutzen den Speicher für die nächste Displayliste, oder zum Cachen, etc.
Nur werden die Daten halt nicht freigegeben, um sie für andere Prozesse, oder für Daten innerhalb des Prozesses verwenden zu können.
Das war mir zuviel, und so schreibe ich jetzt die ganze Engine um, damit ich Vertex Arrays verwenden kann. Da diese tatsächlich nur Arrays (ohne OpenGL-Magic ) sind, kann man sie problemlos dynamisch löschen und erzeugen, und der Speicherverbrauch wird auch tatsächlich ans Betriebssystem weitergegeben.
Ich würde heutzutage gar keine Displaylisten mehr verwenden. Bei der heutigen Grafikhardhare kann man genauso gut VBOs verwenden. Schließlich sollen ja auch Displaylisten in OpenGL 3.0 rausfliegen, bzw. "gelayert" werden, was auch immer das heißt, jedenfalls gelten sie als deprecated.
Registriert: Di Dez 27, 2005 12:44 Beiträge: 393 Wohnort: Berlin
Programmiersprache: Java, C++, Groovy
Hallo yonibear,
Displaylisten haben aber auch ihre Vorteile.
Bei VBO's muss man seine Daten erst in Vertex-Arrays organisieren, während man Displaylisten nur mit glNewList beginnt , und dann dahinter seine gesamten OpenGL-Befehle ausführt.
Ausserdem sind sie extrem nützlich, um Matrizenoperationen oder andere kostspielige Operationen 'vorzuberechnen'.
Ausserdem sind sie extrem nützlich, um Matrizenoperationen oder andere kostspielige Operationen 'vorzuberechnen'.
Mal abgesehen das man das auch mit einer praktischen Mathe-Unit machen kann, kann man die Matrizen auch per GL berechnen lassen und sich dann das Ergebnis einmal per glGet(GL_MODELVIEW_MATRIX, ...) speichern und dann per glLoadMatrix oder glMultMatrix wieder laden.
Das mit den Displaylisten solle man vielleicht auch mal im Tutorial ergänzen. Denn sonst schreibt der ahnungslose Neuling seine 1a 3D-Engine und muss sie dann hinterher wieder komplett umschreiben (s.o. )
Wie bekommt man eigentlich Tutorial-Ergänzungs-Schreibrechte?
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7810 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Werd Moderator.
Am einfachsten du formulierst deine Ergänzung aus, und stellst die hier rein. Wenn die anderen hier der Ergänzung zustimmen, wird ein Mod das dann ins Tutorial einpflegen.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Registriert: Di Dez 27, 2005 12:44 Beiträge: 393 Wohnort: Berlin
Programmiersprache: Java, C++, Groovy
hallo two,
gut, Matrizen kann man vielleicht noch alternativ mit Mathebibliotheken nachberechnen, es ging ja nur darum, dass man das mit Displaylisten ziemlich elegant und schnell machen kann.
Ausserdem kann man ja noch andere OpenGL-Zustände, wie z.B. Licht und dergleichen mit abspeichern.
Ich finde aber, dass Displaylisten trotzdem ihre Vorteile gegenüber Vertex-Arrays bzw. VBO's haben.
Und die Speichereffizienz von VBO's muss nicht immer gegeben sein.
Ein gutes Beispiel ist z.B. das Rendern eines Würfels. Ein Würfel hat zwar nur 8 Vertices, da man aber für jedes Vertex 3 verschiedene Normalen hat, muss man dennoch ein Array mit 24 Elementen übergeben.
Und wenn man noch Farben oder Texturkoordinaten hinzufügen will, so muss man das immer für jedes Vertex im Array machen, auch wenn sich diese vielleicht nur ein paar mal ändern.
In einer Displayliste hätte man die freie Wahl, an welcher Stelle man sein glColor oder glNormal aufruft.
Zu guter letzt muss ich noch erwähnen das VBO's (jedenfalls auf meiner Grafikkarte) im Durchschnitt ca. 1/3 langsamer als Displaylisten sind.
Mitglieder in diesem Forum: 0 Mitglieder und 6 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.