Hallöchen,

ich hab mich schon immer gefragt wie man eigentlich wirklich große Szenen am einfachsten gerendert bekommt. Nehmen wir mal an wir haben eine Engine die auf einen Szenengraph aufbaut. Eine Möglichkeit wäre einfach permanent zu Prüfen ob die BoundingBox eines Meshes (und ggf. auch dessen Subs) im Camerafeld liegt zu prüfen. Diese Methode wäre allerdings stark vom Level-Designer abhängig wie "gut" er arbeitet. Hab ich Meshes/Subs die sehr groß sind, wären diese zu oft sichtbar.

Nun könnte man einen Occtree verwenden. Doch hier weiß ich nicht weiter.. Schon klar, erstmal würd ich einen riesen VertexBuffer bauen wo ich alle Vertexe des Szenengraphs erstmal in Weltkoordinaten umrechne und diesen dann zerteile. Pro Würfel nur noch einen IndexBuffer und gut. Doch was ist mit Materialien? Theoretisch müsst ich für jedes, in der Szene verwendete Material einen Occtree bauen?!

Wie machen das die "großen" Engines?

Die Frage stelle ich mir auch oft...

Ich schätze es ist eine Mischung aus cleverem Leveldesign und einer intelligenten Sortierung der Objekte.

zum Leveldesign:
Die Objekte dürfen nicht zu groß werden, da sie ja sonst immer gerendert werden. Da muss also der Leveldesigner entscheiden wo er am besten das Objekt in Stücke hackt. Auch nicht zu vernachlässigen sind künstliche Wände, die die Sicht auf bestimmte Teile einer Map verhindert. Kann man ganz gut bei Rage sehen, da muss man durch einen Zick-Zack-förmigen Gang um zur anderen Hälfte der Stadt zu gelangen. Hier kommen dann wohl Portale zum Einsatz, die der Engine sagen: "Wenn der Spieler hier ist brauchst du das da nicht zu zeichnen."

zur Sortierung:
Die Objekte sind optimalerweise nach Material sortiert, so dass man möglichst wenige Statechanges hat.
Man könnte dann die Objekte noch nach Entfernung sortieren um den Tiefentest auszunutzen.
Transparente Objekte muss man natürlich hier genau anders rum sortieren sonst klappt es mit dem Blending nicht so gut....

Ich denke, dass man bei Objekte die LOD verwenden auch nicht jeden Frame die Entfernung checken muss. Die kann man (Leveldesigner) entweder in Gruppen zusammenfassen und/oder einen Counter nutzen der nur alle n Frames die LOD Stufe testet.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Ich wuerde mal spontan behaupten da liegt dein Denkfehler.

Man kuckt ganz einfach nach was gerade sichtbar wird und was gerade unsichtbar wird +- Toleranz (Zeit,Winkel,Entfernung,etc.). Dementsprechend laedt man die Sachen neu oder wirft sie raus. Naja... lass einfach dem Wahnsinn freien lauf

_________________
Meine Homepage

Mir fallen da auch ein paar Sachen ein:

1. intelligentes Frustum Culling:
Merk dir das Ergebnis des letzten Culling Vorgangs und benutze dies um Annahmen über das durchzuführende Culling zu treffen. Z.B. kann man das Culling überspringen wenn sich die Kamera gar nicht bewegt hat (vorausgesetzt die gezeichneten Objekte sind alle statisch). Oder man kann die Bewegungsrichtung der Kamera nutzen um den Culling-Vorgang zu sortieren (wenn sich die Kamera nach rechts bewegt, fang an der linken Seite des View Frustums an zu testen o.ä.). Da hab ich auch irgendwann mal einen Artikel drüber gelesen, müsste man mal nach suchen.
Eventuell könnte man bei einem scene graphen auch für jede Node ne Bounding Box berechnen, die die Childs komplett einschließt, dann könnte man eventuell große Teile auf einmal cullen. Setzt aber Disziplin beim Level Designer voraus. Und eventuell will man auch nicht wirklich einen Graphen ablaufen um alle Meshes zu rendern, sondern plättet den intern.

2. batching
Beim Laden des Levels kann man Objekte mit gleichem Material zusammenfassen. Erhöhter Speicherverbrauch vs. weniger Draw Calls.
Man kann auch zur Laufzeit Objekte zusammenfassen, das ist aber nur für kleine Datenmengen empfehlenswert, geht aber eventuell schneller als mehrere Draw Calls.

3. instancing
Gleiche Objekte (gleiche Geometrie, Materials) können mit unterschiedlichen matrizen in einem Draw Call gerendert werden.

4. LODing
Unwichtige Objekte in großer Entfernung müssen evtl garnicht gerendert werden. Andere evtl in niedrigerer Auflösung oder mit einem einfacheren Shader (weit entfernte Bäume z.B. werden gerne als Billboards gezeichnet).
Realtime Schatten, Reflections etc. nur bis in eine bestimmte Entfernung rendern.

5. Occlusion Culling
siehe viewtopic.php?f=10&t=10884

6. Vorberechnen verschiedener Effekte
Lightmaps für realistische Beleuchtung und Schatten. Qualitativ meist auch besser als realtime Schatten. Cube-/Spheremaps für Reflektionen. Geht aber nur für statische Objekte.

7. Faken was das Zeug hält

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Ich könnte dir einfach eine Lösung präsentieren aber ich probier es mal über ein anderen Weg.

Was sind die Probleme die auftreten, wenn man sehr große Gebiete, mit mehreren km² rendern will ?
-Tiefenpuffer genauigkeit(welche schnell sehr ungenau wird und zum flickern führt)
-Anzahl der zu verarbeitenden Objekte wird so groß, dass ein frame zu kostenintensiv wird, um die üblichen 60FPS zu schaffen
-Anzahl der renderbefehle ist so groß, dass die 60FPS nicht mehr erreicht werden
-Füllrate wird zum limitierung, wenn zu viele komplexe shader gerendert werden

Nun macht es Sinn, sich Lösungen für diese Hauptprobleme an zu gucken und eine Lösung zu designen.

Der Tiefenpuffer ist ein Problem, welches sich über mehrere Jahre kaum verändert hat.
Die Grafikkarten supporten nach wie vor bis zu 32 Bit als einzelnen Buffer aber in deferred rendering musste man vor einigen Jahren noch weiter runter gehen, weil zuviele Buffer der Karte ein schnelles Ende bereitet haben. Man kann aber mit einem eigenem Tiefenpuffer eigene Shader benutzen und somit noch mehr Genauigkeit an einer Stelle raus holen und dafür an anderer verlieren.
Die genauigkeit nimmt aber so oder so sehr schnell ab und bei sehr großen Gebieten greift man dann auf das zerlegen von Bereichen zurück.
Da gibt es diverse Techniken, von mehreren Render Targets, render Schritten, Imposter und natürlich Game Design entscheidungen.
Ziemlich effizient ist es mit mehreren render Targets zu arbeiten, wo man einfach in X Tiefenebenen zerlegt und jede in einen eigenen Rendertarget rendert und am Ende alle nacheinander in den backbuffer rendert.

Zu Punkt 2 kann ich mich kurz fassen, ein Octree bzw. Quadtree's sind hier die übliche Lösung.

Um Herr über zu viele Rendercalls zu werden muss man logischerweise diese reduzieren.
Dies kann man durch Instancing, so viele OpenGL Objekte wie möglich teilen und batching erreichen.
Punkt 2 reduziert alles raus, was man nicht sehen kann, das reduziert enorm, nun sollten die übrigen Objekte möglichst effizient rendern.
Zuerst sollte man seine Objekte nach gemeinsamen OpenGL Objekten(texturen, vbo und shader) sortieren.
Die teuersten OpenGL Calls sind die Objekt binding Befehle und das sortieren reduziert diese.
Instancing reduziert Drawcalls und der Speicher wird effizienter ausgenutzt,
Atlanten, Virtuelle Texturen, Ueber Shader helfen hier auch enorm.

Füllrate kann man auch recht einfach beschreiben.
Je einfacher der Shader des so weniger Zeit braucht das füllen eines Texels.
Je niedriger der Overdraw, des so weniger Texel müssen gefüllt werden.
Damit man den Overdraw niedrig hällt kommt ein prerender step hinzu, welcher schreiben von Farben deaktiviert(damit auch den fragment shader) und alle Objekte zeichnet.
Dieser Schritt wird üblicherweise Z-Pass genannt und sorgt dafür, dass man im nachfolgendem Renderpässen nur für Alpha Materialien ein Overdraw hat, da der Tiefenpuffer alle verdeckten Pixel skiped.

Zum Ende bleibt zu sagen, es ist kein Hexenwerk, einfach mit was anfangen und dann immer wieder durch die Liste iterieren, bis man wieder Glücklich ist.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004