... ich hab' mir jetzt gerade ein Museum programmiert, in dem in insgesamt 90 Räumen ebenso viele Bilder (alles jpgs) ausgestellt werden sollen. Weil's beim Navigieren jetzt schon bisweilen ruckelt, - besonders bei Rotationsbewegungen - fange ich nun an, über Optimierungen nachzudenken. Bevor ich nun alle Möglichkeiten ausprobiere, würde ich von euch gerne ein paar Hinweise bekommen, wo man am effizientesten spart.
Hier hab' ich mal ein paar Ideen zusammengestellt, (1) und (2) sind bereits umgesetzt:
1. Backface Culling abschalten.
2. Irgendwo in diesem Forum habe ich mal gelesen, dass for/while/repeat - Schleifen und dergleichen möglichst innerhalb von GlBegin ... GlEnd - Blöcken geschachtelt werden sollten und nicht umgekehrt, so dass es möglichst wenige GL-Blöcke gibt.
3. Lossy Ex hat in einem anderen Thread mal geschrieben:
Zitat:
Häufiges wechseln der Texturen sollte man lassen
... gewinne ich also viel Zeit, wenn ich alle meine .jpgs in eine riesengroße Textur lade und dann mit uv-mapping nur Teile der Textur benutze gegenüber der Möglichkeit 90 Texturen aus kleinen Dateien zu laden und diese jeweils vollständig zu verwenden (ich benutze die GLBitmap.pas) ? -- Im Texturen-Tutorial wird das uv-Mapping für kleine Texturen empfohlen. Spare ich ausser der Ladezeit dann auch beim Rendern ?
Falls das so ist, gibt's ein Tool, das mir die ganzen jpgs zu einer Riesen-Textur zusammenfügt oder muss ich das von Hand machen ?
In Delphi könnte man dafür ja Copyrect benutzen, aber soweit ich weiss, kann man in Delphi [6.0] keine jpgs laden ?
4. Rendert OpenGL eigentlich immer das gesamte Modell oder nur die Vertices, die von meinem aktuellem Standpunkt aus sichtbar sind ? Falls Ersteres der Fall ist, wie kann man Letzteres erreichen ?
5. Wie sieht's mit Lichtquellen aus ? Fressen die viel Zeit ?
... so. Ich hoffe, dass die Fragen nicht allzu doof sind - vielleicht habt ihr ja auch noch die eine oder andere Idee.
Registriert: Sa Jan 01, 2005 17:11 Beiträge: 2068
Programmiersprache: C++
ölgötz hat geschrieben:
1. Backface Culling abschalten.
Anschalten , erst dann werden die Rückseiten weggelassen.
ölgötz hat geschrieben:
2. Irgendwo in diesem Forum habe ich mal gelesen, dass for/while/repeat - Schleifen und dergleichen möglichst innerhalb von GlBegin ... GlEnd - Blöcken geschachtelt werden sollten und nicht umgekehrt, so dass es möglichst wenige GL-Blöcke gibt.
Ja, stimmt so.
Das mit den Texturen ergibt auch Sinn, wird aber vermutlich nicht ganz soviel bringen.
ölgötz hat geschrieben:
Falls das so ist, gibt's ein Tool, das mir die ganzen jpgs zu einer Riesen-Textur zusammenfügt oder muss ich das von Hand machen ?
Frag mal Frase, der hat da was gebastelt. Findest du im SVN von XDream.
ölgötz hat geschrieben:
4. Rendert OpenGL eigentlich immer das gesamte Modell oder nur die Vertices, die von meinem aktuellem Standpunkt aus sichtbar sind ? Falls Ersteres der Fall ist, wie kann man Letzteres erreichen ?
Du solltest schon nur die Räume zeichnen, die man sieht, denn Rest berechnet OpenGL natürlich mit ein.
ölgötz hat geschrieben:
5. Wie sieht's mit Lichtquellen aus ? Fressen die viel Zeit ?
k.a., vermutlich ja, sollte aber minimal sein.
Hauptfresser sind 1,2 und 4.
Registriert: Di Nov 26, 2002 22:12 Beiträge: 259 Wohnort: Dresden
(3)
Eine Textur, die mehrere kleine Texturen fasst nennt man Texturatlas. In der nVidia Entwicklersektion gibt es ein Tool mit dem man solche Texturatlanten komfortabel generieren kann. Das macht aber eigentlich nur bei vielen kleinen Texturen, die häufig verwendet werden Sinn. Schaden wird es aber sicher nicht.
(4)
OpenGL rendert alles, was du ihm sagst. In trivialen Szenen lassen sich häufig große Teile der Szene einfach ausschließen. In komplexeren Szenen solltest du auf Octrees oder BSP-Trees mit PVS zurückgreifen.
(5)
Das normale OpenGL-Licht kannst du beruhig verwenden. Es schadet aber sicher nicht die Lichter ebenfalls mit in deinen Octree / BSP-Baum einzubinden. Du musst aber dabei beachten, dass das Licht durchaus Auswirkungen auf sichtbare Objekte haben kann obgleich die Lichtquelle selbst nicht sichtbar ist.
_________________ Nichts auf der Welt ist so gerecht verteilt wie der Verstand. Denn jederman ist überzeugt, dass er genug davon habe.
Rene Descartes, frz. Mathematiker u. Philosoph, 1596-1650
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Ähm. Also das mit den Texturen macht nur sinn, wenn diese sehr klein sind. Du hast auch eine Größenbeschränkung für Texturen und es ist nicht gesagt, dass die überall gleich groß ist. Von daher würde ich es erst einmal so lassen. Was ich damit meinte war eher folgendes. Wand. 1 Dreieck Wand. Boden. 1 Dreieck Boden. Wand. 1 Dreieck Wand. Boden. 1 Dreieck Boden. usw. Da sollte man zu erst alle Wände und dann alle Bodenflächen rendern.
Für mich schreit das ja nach Portalen/BSP-Bäume bzw nach irgendetwas so in diesem Dreh. Also das du den Raum zeichnest in dem du dich befindest bzw den Raum in den du schauen kannst. Oder eben nur die sichtbaren Flächen von dem anderen Raum. Frage mich jetzt nicht wie. Das übersteigt meine Fähigkeiten.
Evtl kannst es auch so gestalten, dass du mit OcclusionQuery etwas erreichen kannst. Dabei kannst du abfragen wie viel von dem sichtbar ist. Wenn du die Räume als Vierecke stark vereinfachst kannst du so das Rendern minimieren. Aber jenachdem wie die Räume aussehen könnte es Problematisch werden.
Die Räume würde ich wohl als DLs ablegen. Damit dürfte sich auch etwas reißen lassen. Vielleicht würde ich sie auch als VBO ablegen. Kommt wieder darauf an wie komplex sie sind.
nun... ich bin sicher, es einfach in VBOs abzulegen, sollte die Lösung sein. Je nach Bandbreite lassen sich so bis zum zehnfachen der Performance rausholen (Vorrausgesetzt, man hat so nen antiquierten Rechner wie ich ^^). Sonst ist damit die zwei- bis vierfache Performance drin. Der Einfachheit halber kannst es zuerst mit Displaylisten probieren. Wenn die dann nen Stück Performance bringen, dann ganz auf VBOs umstellen.
Zu diesem Texturatlas, also dem Unterbringen mehrerer kleiner Texturen in wenigen großen... Schön Jetzt kenn ich endlich den Namen davon Hab es bis jetzt immer Texturebaking genannt :p
Jedenfalls könntest du einfach mal in einem Durchgang die Texturen mitloggen. So dass du am Ende eine chronologische Liste der Texturbindungen hast. Danach könntest du dann diese Texturen in große reinpacken. z.B. als Container-Größe 1024. Da passen nach Adam Riese 4 512er Texturen rein oder 16 256er usw. Speziell, wenn du die in der Reihenfolge reinpackst, wie sie auch gebunden werden, solltest du dadurch bereits nen merkbaren Boost bekommen
Ist aber nicht ohne, das zu automatisieren. Ist aber möglich und sogar im Bereich des realistischen Siehe meinen Texturmanager im X-Dream-SVN, wie i0n0s ja bereits so nett angesprochen hat :p
_________________ "Für kein Tier wird so viel gearbeitet wie für die Katz'."
Registriert: Di Dez 27, 2005 12:44 Beiträge: 393 Wohnort: Berlin
Programmiersprache: Java, C++, Groovy
Hallo ölgötz,
ich würde an deiner Stelle ersteinmal versuchen herauszufinden, wo dein 'Flaschenhals' liegt
Am besten wäre es wenn du dir noch einen FPS-Counter mit ins Programm einbaust, damit die Geschwindigkeit deines Programmes messbar wird. Damit du wirklich gut testen kannst, müsstest du eventuell bei deinem Grafikkartentreiber solche Sachen wie vsync und antialiasing ausschalten, damit deine Ergebnisse nicht verfälscht werden
Laut deiner Beschreibung der Szene vermute ich mal 3 verschiedene Möglichkeiten :
1. Zu viele Vertices
Dies kannst du ganz einfach herausfinden, indem du verschiedene Auflösungen deines Fensters ausprobierst.
Verändert sich die Framerate deines Programms dabei nicht, kann es wirklich sein, dass du zu viele Vertices an die Grafikkarte sendest. In diesem Falle wären Displaylisten, VBO's und dergleichen wirklich angebracht. (lohnen sich eigentlich immer )
2. Zu viele Fragmente
Du zeichnest mehr als du eigentlich siehst. Bei 90 voneinander unabhängigen Räumen kann ich mir das gut vorstellen . In diesem Falle würde ich die Logik des Programmes so abändern, dass du nur den Raum zeichnest, in dem sich der Betrachter befindet (und eventuell noch die Nachbarräume)
3. Zu viele Texturen
Es kann natürlich auch sein, dass du zu viele Texturen hast, die nicht alle in deinen Grafikspeicher passen. Du sagst du benutzt jpgs, aber diese werden trotzdem intern mit viel Speicherverbrauch abgespeichert (fast wie Bitmaps).
In diesem Falle sollstest du es mit komprimierten Texturen versuchen (bietet OpenGL ab Version 1.3 an).
Du hast dabei zwei Möglichkeiten : Entweder du übergibst an die normale Texturfunktion (glTexImage2D oder gluBuildMipmaps nehm ich mal an ) als internes Format GL_COMPRESSED_RGB oder GL_COMPRESSED_RGBA oder du versuchst es mal mit
http://wiki.delphigl.com/index.php/glCompressedTexImage, dabei muss die Textur allerdings schon im komprimierten Format vorliegen (nein, nicht jpg )
Allerdings solltest du dich auch fragen, ob du schon zum Beginn alle 90 Bilder laden musst.
Wäre wahrscheinlich schneller wenn du ersteinmal die ersten 10 Bilder lädst, und die anderen dann erst nach und nach, wenn man sich durch die Räume bewegt.
Was ich vielleicht noch empfehlen kann ist anisotropische Filterung zu benutzen (Extension GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT). Damit sehen deine Bilder dann auch noch seitlich ganz gut aus (und nicht so verschwommen).
ich weiss ja nicht wie deine Räume angeordnet sind...aber vielleicht kannst du einfach der Raum in dem du "stehst" und den links und rechts davon malen...da sparst du dir einen Programmieraufwändigen Octree etc und mals nur 3/90 ...
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7810 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
katz0r hat geschrieben:
ich weiss ja nicht wie deine Räume angeordnet sind...aber vielleicht kannst du einfach der Raum in dem du "stehst" und den links und rechts davon malen...da sparst du dir einen Programmieraufwändigen Octree etc und mals nur 3/90 ...
Mitglieder in diesem Forum: 0 Mitglieder und 4 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.