rob_s schrieb:
Benamsung? Weiß nich. Sieht doch hübsch aus?
Jo, Benamsung.
sgn0. sgn_Texture. *schauder*
Namespaces?
Aber mach wie du es für gut hältst, das hier jetzt lange zu diskutieren führt zu nix (ausser dass die Sachen um die es dir eigentlich geht in den Hintergrund gedrückt werden).
Mir ist noch was eingefallen:
Zwischen Wurzel und erster Ebene eine Sichtbar-Unsichtbar-Ebene. Jede Entity und die Kamera müsste per Signal verbunden sein. Bei Bewegung wird Bescheid geben.
Verstehe ich nicht. Klingt aber nicht effizient.
Das Updaten von unsichtbaren (=fix auf visible=false gesetzten) Teilen kann man dadurch verhindern, indem man die unsichtbaren Nodes einfach "dirty" lässt, bis sie irgendwann mal wieder visible werden. Für Nodes die nur ausserhalb des Frustrums liegen funktioniert das natürlich nicht. Kann aber auch gar nicht, weil die ja durch Änderung der Position (bzw. allgemein Transformation) wieder in den sichtbaren Bereich kommen würden.
Und bei Kameraänderung würde ich genau gar nix machen, ausser die Camera-Nodes (+ alle Parents) "dirty" zu setzen. Das Zusammenbasteln der Camera-Transform und World-Transform kann man während des Culling/Rendering machen - eine zusätzliche Matrix-Multiplikation pro potentiell sichtbarem Knoten sollte nicht sehr schlimm sein.
Ausserdem ... wie verträgt sich deine Variante denn damit dass es mal mehr als eine Kamera geben könnte?
eine
sgn0::OnObjMove
rechnet die BoundingBox mit dem Frustum gegen und sortiert den Pfad um.
Dann müssten beim Rendern nicht haufenweise BBs verwurstet werden...
Welcher Pfad?
Üblicherweise hat man hierarchische BBs, d.h. jede Node hat eine BB für "ihren eigenen" Inhalt, und eine die die BBs aller Kinder mit einschliesst.
Dann kann beim Cullen schön ganze Teilbäume weg-cullen ohne sich die ganzen Child-Nodes anzusehen.
----
Wobei ich noch anmerken möchte dass ich KEIN Experte bin was Grafik-Engines angeht -- gibt Leute hier im Forum die davon wesentlich mehr Ahnung haben.
