Scene Graph / Engine design decision
Author
Ok so I have been working on a game engine for about 2 months that incorporates a render I have already built and it is pretty much all done now.
But Im looking back on a design decision I made a while back and I want all of your input on if I should change it.
Let me give you an example, for my text objects I create a class called Text2D which inherits from a class called Resource which is the whole code base it needs to function in my engine and is this specific type of object that can be added to my Scene Graph.
Now to be added to the scene graph it needs a specific class, in this case Text2DNode which inherits from the SceneGraph class. So when the Text2D object is instantiated it registers it's self as a "Resource" and an object of type Text2DNode is instantiated and associated with that Text2D object and can then be attached anywhere in the scenegraph.
So my question is this, is that too much? Should the Text2D class have the code necessary to be attached to the Scene Graph and thus be it's own Scene Graph node?
It is nice in one respect because it keeps the scene graph specific code separate from the Resource specific code and the Scene Graph nodes are pretty light weight small classes then.
Quote:Original post by Wavesonics
So my question is this, is that too much?
I believe that's definitely too much. You shouldn't need to create a new class for every class that will fit into your scene graph. My recommendation would be to use containment rather than inheritance. Why not make your Text2D object contain a 'SceneGraphNode' object. This way your SceneGraphNode object fits into your scene graph and handles the logical code, and your Text2D object code is kept completely separate while still having unlimited access to it.
Some examples of code:
// Add to scene graph (just within engine code)m_sceneGraph->GetRoot()->AddNode( myText2DObject->GetSceneNode() );// Remove ourselves from scenegraph on destructionvoid Text2D::~Text2D(){ m_sceneNode->GetParent()->Detach( m_sceneNode );}Doolwind
Author
Ah I like that, it is nice.
Now one minor complication is, I use the visitor pattern for my renderer to traverse my scene graph. So right now the Renderer picks the proper visit function to render the certain node type depending on just that, the node type. But now if all resources will have the same node type, how would you recoment handeling this?
Now one minor complication is, I use the visitor pattern for my renderer to traverse my scene graph. So right now the Renderer picks the proper visit function to render the certain node type depending on just that, the node type. But now if all resources will have the same node type, how would you recoment handeling this?
Quote:Original post by Wavesonics
But now if all resources will have the same node type, how would you recomend handling this?
Your SceneGraphNode can have a pointer back to the object which contains it. Whether this pointer is of type "Resource" or another better candidate based on your design, you'd be able to simply call a virtual function on this pointer and it will call the function based on whatever type of object you have.
Something like:
void SceneGraphNode::CallRenderFunction(){ // Call virtual "Render" on object type "Resource*" m_ownerObject->Render(); // for all children for(...) { nextChild->CallRenderFunction(); }}// Usage{ m_sceneGraph->GetRoot()->CallRenderFunction();}Doolwind
I've commented about this before, so if you search you can get the longer winded version of this, but short version: Scene graph nodes should not be renderable things. Renderable things may refer to scene graph nodes to determine position and orientation, but why have a scene graph node refer to a renderable thing (thereby limiting it to one renderable item) for no gain?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
