spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

HÄ?????

vielleicht unvollständiger Beitrag? Bitte den Rest auch noch dazu schreiben!!!

Naja, die Drawfunktion muss den Baum traversieren, dabei die Matrizen (im weitesten Sinne) "aufakkumulieren" und dann immer wenn es einen Blattknoten fndet, diesen mit der "aufakkumulierten Matrix" rendern.

Falls Dir das immer noch zu schwer ist, könntest Du Dir mal die PLIB
plib.sf.net ansehen. Deren Hauptnachteil ist dass sie keine weiterführenden (Render) Funktionen hat, aber das wäre bei Dir ja ein Vorteil, weil es dadurch leichter zu durchschauen ist; der eigentliche Scene graph Code ist relativ klein und ist auch sauber und vom Altmeister Steve Baker geschrieben.

Ja, also ein guter SceneGraph bringt bestimmt sehr viel, jedoch ist es glaub ziemlich viel Arbeit!
Den SceneGraph kannst du aber natürlich nicht nur zum Rendern verwenden, sondern auch für deine Physik. Zb hast du einen Tisch und auf dem steht eine Tasse. Im Scene Graph wurde das dann ungefähr so aussehen:
Welt->Tisch->Tasse->Löffel
Welt->Auto->Spieler
...

Verschiebst du den Tisch, brauchst du dann nur die Matrix für den verschobenen Tisch setzen und die Tasse, Löffel bewegt sich automatisch mit.

Aber am Anfang musst du dir mal überlegen wie du deine Resourcen abspeicherst, dabei kannst du das ganze gleich Plattformunabhängig gestalten für OpenGL und DirectX. Also wie du Vertices, Indices, Texturen, Lichter usw. verwaltest.
Anschließend würd ich dann erst mit der eigentlichen Baum programmierung beginnen und dabei Schnittstellen offen halten für Plugins. Falls du mal zB ein Terrain entwicklen möchtest, wäre das als eigenes Plugin ganz gut.
Und dann einen eigenen RenderTraverser programmieren, der Texturen, selbe Objekte, transparente Objekte usw sortiert und culling gleich durchführt.
Sind die Berechnungen alle durchgeführt kannst du mit dem eigentlichen rendern beginnen!


cya,
Stefan

Ein guter Scenegraph dient ihn erster Linie nur zur Verwaltung von Objekten. Es werden Hierarchien aufgestellt, die in vor allem die natürlichen Verhältnisse wiederspiegeln, das heißt, ein Apfel liegt auf einem Teller, welcher sich auf einem Tisch befindet.

Diese Hierarchie ist für die meisten Vorgänge, außer dem Transformieren aber total ungeeignet.

Idealerweise ist es also so, dass es für jeden Fall einen extra Baum gibt, zum Beispiel ein Octree, der die Szene in Gebiete unterteilt, perfekt geeignet zum Cullen und für Kollisionstest, ein Rendergraph, in welchem die Objekte nach Materialien oder Transparenz sortiert sind.

In der Realität ist sowas kaum zu verwirklichen und man verwendet den Scenegraph auch oft zum Cullen oder zum Collisionstest. Dazu verwendet man die eh schon programmierten Node-Klassen, zum Einbau von Quadtrees (Terrain), Octrees (Indoor-Level) oder ähnliche Konstrukte, die dann direkt dem Terrain hinzugefügt werden.

Ein Node im Scenegraph sollte immer nur die Referenz auf das Interface einer Ressource haben, so dass man bei Plattformunabhängigen Engines den Scenegraph universell verwenden kann.

Zum Rendern könnte z.B. ein DXRenderTraverser den Scenegraph durchlaufen, alle Objekte Sortieren und anschließend Rendern. Es gibt hier aber mehrere Konzepte. Zwei gute Tutorials finden sich hier:

(1) http://www.sir-kimmi.de/tuts/graphics/whats_a_scenegraph.txt
(2) http://www.sir-kimmi.de/tuts/graphics/re…_scenegraph.txt