Optimierung einer Render-Engine
-
thx,
fällt dir/euch noch ZUSÄTZLICH zu dem obengenannten Zeugs was ein??
-
Im Grunde lassen sich diese beiden Punkte zusammenfassen. Was du benötigst, ist ein anständiger Szenengraph, der die Spielwelt erstmal räumlich unterteilt und so Objekte bestimmt, die eventuell in Frage kommen, sichtbar zu sein. Diesen Szenengraph stutzt man dann zurecht indem man die Blätter abschneidet, die nicht in Frage kommen (culling). Je nach Umgebung kommt dafür portal culling (Innenräume), viewing frustum culling, (20000 andere Arten) und Kombinationen davon in Betracht. In der untersten Ebene des Graphen müssen die Objekte dann nach Renderstates sortiert sein, in der obersten erstmal räumlich.
Immer schön nach Szenengraph suchen.
-
ESS_CB schrieb:
- Objekte mit gleichen Texturen/Meshes nacheinander rendern (um das nicht soviel
neu geladen werden muss)Hm, bringt das was? Ich geh mal davon aus, dass Du die Meshes im vram hast, oder? Bringt dann das rendern von gleichen Meshes nacheinander was?
ESS_CB schrieb:
nicht sichtbare Objekte gar nicht erst an RenderPipeline übergeben
Je nach Treiber machen DisplayLists schon ein ziemlich gutes Frustum culling. Und evt. auch occlusion culling? Mal rapso fragen...
-
das soll erstmal ne Renderengine für n Outdoor RPG werden (entsprechend auch mit Indoor)
das mit dem frustum culling habe ich zur Zeit nur a) für jedes Tile (30 * 30 Tiles geladen) sind 5 SichtbarkeitsTests eben auch zimlich viel.
Die Idee mit dem dem Baum finde ich spitze, nur wo fängt man an mit dem "abschneiden"? fängt man unten an kann man es auch gleich sein lassen da wieder alles getestet wird, fängt man dagegen oben an besteht die Gefahr, dass der zu testende Bereich zu groß ist und er zwar sichtbar ist aber die Punkte die auf Sichtbarkeit getestet werden nicht auf dem Bildschirm sind und dass so der Bereich doch nicht gerendert wird!
das mit der Gebieteinteilung ist echt cool da man so rellativ einfach IndoorBereiche einbauen kann (eben mit Portalen; Portal sichtbar -> IndoorSichtbarkeitstest)
Das mit den Meshes hab ich mir dazugedichtet und das mit den TExturen ist aus HL.
-
durito schrieb:
Hm, bringt das was? Ich geh mal davon aus, dass Du die Meshes im vram hast, oder? Bringt dann das rendern von gleichen Meshes nacheinander was?
Es bringt u.U. was wenn du damit weniger oft render states setzt. Aber natürlich kommt es darauf an, wo der Flaschenhals in der Pipeline ist, kann auch mal völlig bedeutungslos sein. Es wird wohl nicht schaden, an den Blättern des Szenengraphen die Objekte dort sortiert zu halten.
ESS_CB schrieb:
Und evt. auch occlusion culling? Mal rapso fragen...
Verdeckungsberechnung kann aufwändig sein und lohnt sich meistens nicht so wahnsinnig, denn das geht dann gescheit auf Kosten der CPU. Anders sieht es natürlich aus, wenn man einen geilen Szenengraphen hat der gleich weiß, dass alles hinter dem Berg nicht sichtbar ist. Sowas kann man schon brauchen, den Verdeckungs-"Test" macht man aber eher nicht.
-
ESS_CB schrieb:
Die Idee mit dem dem Baum finde ich spitze, nur wo fängt man an mit dem "abschneiden"? fängt man unten an kann man es auch gleich sein lassen da wieder alles getestet wird, fängt man dagegen oben an besteht die Gefahr, dass der zu testende Bereich zu groß ist und er zwar sichtbar ist aber die Punkte die auf Sichtbarkeit getestet werden nicht auf dem Bildschirm sind und dass so der Bereich doch nicht gerendert wird!
Du steigst natürlich nur ein paar wenige Äste rekursiv ab. Jeder Knoten ist mit einem Bounding Volume assoziert und wenn das Viewing Frustum einen Teil davon schneidet, steigst du dort weiter ab und prüfst die Kind-Bounding-Volumes. Sobald ein Knoten vollständig im Frustum ist, kannst du alle Objekte darin rendern. Wenn ein Knoten völlig außerhalb ist, beachtest du ihn nicht mehr weiter (bildlich schneidest du ihn vom Baum ab).
Eine einfache Lösung ist ein Quadtree oder Octree, der den Raum gleichmäßig immer weiter aufteilt. Es gibt aber auch professionellere Lösungen, z.B. BSP-Trees, die den Raum anhand der sich darin befindlichen Objekte aufteilen. Wenn du auf eine Insel einen fetten Berg setzt wie in FarCry, dann würde die Insel nie zu mehr als die Hälfte sichtbar sein
schnipp-schapp. Dann steigst du in der möglicherweise sichtbareren Hälfte weiter ab und dort bleibt dir wieder nur ein kleinerer Teil übrig schnipp-schnapp, usw. Da du diese Datenstruktur nur einmal vorberechnest ist das dann während des Spiels nicht teuer. Letztlich müsstest du so oder so irgendwie alle zu rendernden Objekte sammeln und sie mit relativ wenig Aufwand gleich am Beginn der Pipeline rauszunehmen ist nicht das schlechteste.
-
man sollte dabei einen scenegraph nicht mit einem cullinggraph gleichsetzen. ein scenegraph stellt objekte logisch in eine beziehung zueinander, ein cullinggraph macht das meist räumlich.
wenn z.b. 30 figuren durch die gegend laufen würden, würde man ihre scenegraph-root ziemlich weit oben im scenegraphen anhängen (Vermutlich gleich unterm root oder eine node die eventuell "figuren" heißt. die figuren selbst, vielleicht sogar aus mehreren objekten bestehend, würden im cullinggraphen wiederrum in die culling hierarchy einsortiert werden, sodass man neben visibilityculling auch collision usw. machen kann.
man muss sehen, dass die statische geometrie einen cullinggraphen meist sehr gut partitioniert und dort die dynamischen objekte meist sehr profitieren, bei reinen scenegraphen ist das hingegen sehr selten der fall, weil es eben eine logisch einteilung ist.
-
In der DXSDK Doku gibts IIRC eine Liste mit Performance Tipps. f'`8k
Bye, TGGC (Das Eine, welches ist.)
-
DirectX Lib:
Remember, the fastest polygons are the ones you don't draw.
vielen Dank erstmal an euch!!!
Was gibt es denn für (natürlich schnelle
) Methoden einen Bereich (oder BoundingBox) auf Sicht zu prüfen? Ein BoundingBox - "SichtFeldBox" Test ist ja bestimmt nicht die feine englische Art!
Ich habe daran gedacht die Eckpunkte zu testen in welchem Winkel sie zum Sichtwinkel stehen habe da aber das Problem das man nicht unterscheiden kann ob der Punkt nun rechts oder links des FOV liegt (sin 90 == sin -90). Und wenn man das Links/Rechts auch testen würde währe man ja wieder bei der Performance des BoundingBoxenTests!
-
Dein Viewing Frustum wird durch 6 Ebenen definiert. Man kann recht einfach bestimmen, auf welcher Seite einer Ebene ein Punkt liegt, wenn ein Punkt bei nur einer Ebene auf der falschen Seite liegt, befindet er sich schon mal sicher außerhalb des Frustums. Für diesen Test findest du leicht fertige tot-optimierte Formeln im Internet, die würde ich fertig mitnehmen.
