Mir ist gestern noch eingefallen, das ich mal ein Paper über Relationelle Datenbanken und SceneGraph gelesen habe.
Da drin ging es darum, möglichst viel der Strukturdaten in eine Datenbank zu bringen, damit man komplexere Suchoperationen mit hoch optimierten Datenbanken wesentlich effizienter finden kann und auch wesentlich einfacher zu skalieren sind.
So wäre es z.B. möglich sqlite, mysql oder postgresql als Datenbackend für die Struktur zu nutzen oder sich eventuell sogar ein eigenes zu schreiben.
Das Problem an der Geschichte sind die Binärdaten, denn hier braucht man Blobs bei den SQL basierten systemen und diese sind furchtbar ineffizient(speicher und performance). Ich hab daher lieber ein anderen Weg im 2. Konzeptvorschlag gewählt und es dem User auf gedrückt die Nodedaten zu beschaffen.


Es gibt 4 Tabellen und ein Callback, wenn ein Ladevorgang für ein neues Node vor liegt.
In der Tabelle NodeTable findet man die Nodeübersicht also die ID's zu Node, Abhängigkeiten zu Nachtbarn, Örtliche Informationen und der Ressourcen(UserData).
Die Tabellen Ressource, Dependencies und Spatial sind aufgesplittet und enthalten unter ID immer die in NodeTable angegebene ID.
Alle ID's beginnen immer mit 1 und 0 steht für nicht gesetzt.
Nun kann ich eine Datenbankanfrage machen die z.B. so aus sieht "SELECT ID FROM NodeTable WHERE NodeTable.DependenciesID==DependenciesTable.ID && DependenciesTable.NeighborID==0". Diese Select würde allso alle Nodes zurück geben, die Verweist sind.
Man könnte nun und das ist das schöne an den DB-System, die Struktur der DB ändern und aus NeighborID, von DependenciesTable, ChildID und ParentID machen.
Nun kann ich eine Datenbankanfrage machen die so aus sieht "SELECT ID FROM NodeTable WHERE NodeTable.DependenciesID==DependenciesTable.ID && DependenciesTable.ParentID==0". Also suche alle Root-Nodes(jupp es kann mehrere geben).

Man muss nicht unbeding eine SQL basierte DB nehmen, man kann auch einfach hardcoded Methoden in DB implementieren.
Der Vorteil von diesem Konzept liegt ganz klar in der Skalierbarkeit, da die SQL-DB Lösungen auf skalierbarkeit setzen und man z.B. DB Cluster zusammen schalten kann und es sich nichts am Programmcode ändert. Deswegen bezeichnet der Author von dem Paper diese DB basierten SceneGraph als die nächste Generation von SceneGraph. Denn diese sind zwar ein wenig komplexer aber wesentlich flexibler als die alten, denn man kann kleine Szenen aber auch terrabyte große Szenen damit verarbeiten.

Okey soviel zur DB, wie gesagt hab ich mich in diesem Konzept gegen BLOBS entschieden und diese in Extra Datein ausgelagert.
Also jedes UserData/Ressource würde man in einer Datein auf dem Dateisystem wieder finden, egal ob ein MemoryDump, Script, Model oder was auch immer. Durch die TypeID von RessourceTable kann man zwischen Datein unterscheiden und man hat dem User die macht in die Hand gelegt. Oft sehe ich in den SceneGraph Lösungen, dass Daten-Loader mit im SceneGraph drin sind, was auch dann einen zwingt, renderer und einiges weitere mit zu implementieren und dann entsteht sowas http://www.opensg.org/ . Sehr umfangreich und schwer zu nutzen.

Man schreibt sich also ein eigenen RessourceManager und bindet eine methode an den Callback vom SceneGraph.
Es gibt keine Methoden im SceneGraph, die Update,Draw oder ähnlich heisse, denn diese sollen ja aussen passieren und den SceneGraph selber schlank halten.
Über das DB Interface kommt man ja an alle Nodes und kann z.B. eine eigene KI einpflegen. Damit das ganze Performant bleibt, legt sich KI ein eigenes Node im Tree an wo es sich seperat von Physik und Renderer eine eigene View hält. Hoho ein View, ja ein Datenbank Konzept ist die View, eigentlich filtert diese anhand einer SQL Anweisung Daten aus der DB, Cached und Aktualisiert sich selbständig. So weit wollte ich im Konzept jetzt nicht gehen und pflege über ein neuen NodeTree diese Selbständig. Im Beispiel sieht man, dass Player sich die Daten mit Player aus dem Physic View teilt, mit Ausnahme von den Nachtbarschaftsdaten.
In der KI war es an der Stelle nicht wichtig alle kleinen Kollisionsgruppen von Player zu kennen, nur die grobste Player darstellen(oft ne Sphere oder Elipsoid,wenn verfügbar). Dank dem Physikdaten, die sich die Nodes teilen, kann man nun Raycasts und Sensortests machen, darauf dann entscheiden und die nötigen Kräfte korrigieren. Damit Der Player z.B. ein Objekt ausweicht.

Im vergleich zum vorigen Konzept ist diese einfacher gestrickt, sollte man nicht selber eine Datenbank schreiben, ich schätze den Aufwand für dieses Konzept um einiges geringer ein. Ich würde mit einer SQLite Anbindung arbeiten, diese ist unter Public Domain und gleich bis schneller als MySQL. Da es nur noch ein einzigen Nodetype gibt, kann man den SceneGraph schnell schreiben und sich dann auf den RessourceManager stürzen.
Ich bin der überzeugung, dass diese Lösung bei kleinen Szenen zwar langsamer ist aber sobald man Physik, KI und so weiter mit rein bringt, wird es wesentlich besser performen und vorallem übersichtlicher und Speicherschonender(SQLite streamt die DB und lädt sie nicht komplett in den Speicher) sein.
Ich empfehle auch immer noch ein Octree, wessen Nodes ein Node im SG representieren und das Octree wird vom Usercode implementiert und verwaltet, man kann dann die NodeID's dort hinterlegen und muss nicht im SceneGraph suchen gehen.

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

Projekte: https://github.com/tak2004