Sign in to follow this  

Scene Graph / Engine design decision

This topic is 4040 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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 destruction
void Text2D::~Text2D()
{
m_sceneNode->GetParent()->Detach( m_sceneNode );
}



Doolwind

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

This topic is 4040 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this