Octree und Beschränkung der Sichtweite
-
Hallo.
Octrees sind eine tolle Sache um viele nicht sichtbare Fragmente vom Rendering auszuschließen. Aber leider betrifft das keine verdeckten Teile der Szene "vor" der Kamera.
Wenn man, sagen wir in einem Indoor-Shooter, vor einer Wand steht und eigentlich nur ein paar Polygone sichtbar sind, wird unter Umständen doch sehr viel dahinterliegendes gerendert weil etliche Octree-Nodes im View-Frustum liegen.Welche Techniken setzt man nun am Besten im Zusammenspiel mit Octrees ein um dieses Problem in den Griff zu kriegen?
Ich meine allgemeingültige Techniken, die nicht auf speziellen Zusatzdaten der Geometrie beruhen (wie etwa besagte Wand als Occlussion-Plane einzusetzen und probieren welche Octree-Nodes nun unsichtbar sind).
Gibt es da überhaupt eine Möglichkeit oder ist das ein Grund gegen Octrees für Indoor-Szenen?Gruß und schönes Wochenende
-
Ich glaube du suchst sowas wie das BeamTree Verfahren.
Bin mir nicht sicher ob du manuelle Seperator Surfaces wirklich ausschließen willst.
Die Berechnung dieser Surfaces könnte man auch in den Vorgang der "Level-Kompilierung" (ähnlich BSP) packen, so dass die Level-Designer das nicht manuell erstellen müssen.
-
am besten fuer ein octree sind PVS. du berechnest offline welche node vom octree welche anderen nodes sehen kann und speicherst dir das pro node dann ab.
zur laufzeit pruefst du dann einfach nur noch gegen das PVS, was im optimalfall ein bit-test ist.eine kombination von octree und beamtree sehe ich nicht als besonders effizient an. aber wenn ich nach beamtree+seperatur google, sehe ich die eine deutsche seite dazu. sonst kein treffer.
ich glaube der schaffer dieser kunst meinte anti portale, doch fuer indoor wuerde sich weit aus mehr anbieten portale + rooms/zones/visareas zu benutzen. jedoch ist das alles arbeit.einfacher ist da PVS.
-
rapso schrieb:
am besten fuer ein octree sind PVS. du berechnest offline welche node vom octree welche anderen nodes sehen kann und speicherst dir das pro node dann ab.
Das ist interessant. Aber wie berechnen?
Man könnte für die Konstruktion PV-Sets offline das Level rendern und dann mittels Occlusion-Queries testen welche Knoten sichtbar sind. Ist das praktikabel? Eine exakte Menge der sichtbaren Knoten kann man dadurch ja imho nicht erhalten, wegen der vielzahl an möglichen Kamerapositionen IN einem Knoten.
-
gaengig ist, dass du in jeder node an zufaelligen stellen eine kamera hinstellst und in die 6 himmelsrichtungen mit 90grad fov renderst.
dabei renderst du aber nicht mit normalen materialien und texturen, sondern gibst den objekten die farbe ihrer node (kannst ja alle nodes durchnummerieren oder den pointer dazu nutzen). bei einem 32bit rendertarget geht das problemlos.
dann schnappst du dir den framebuffer und checkst anhand der pixel welche anderen nodes zu sehen waren.eine bessere methode die punkte zu waehlen ist beim spielen aufzuzeichnen wo sich die spieler befinden und pro node dann n-punkte aus diesen aufgezeichneten daten zu nutzen.
mit occlusion queries geht sowas natuerlich auch. sowas kannst du sogar zur laufzeit machen, wenn du hierarchisch vorgehst ;).
-
rapso schrieb:
mit occlusion queries geht sowas natuerlich auch. sowas kannst du sogar zur laufzeit machen, wenn du hierarchisch vorgehst ;).
Habe ich jetzt auch vor. Ich werde am Wochenende mal folgendes probieren:
Die Octree Knoten sortieren und von vorne nach hinten rendern um möglichst viele Occluder zu erhalten. Die Querieabfragen wegen Ihrer blockierenden Natur immer um ein Frame versetzt.
-
das kann tricky werden wenn du die hierarchisch testest, da du dann pro hierarchy stufe ein frame latenz dazu bekommst.