Scene Graph implementation dilemma

Started by
3 comments, last by Goran Milovanovic 11 years, 10 months ago
ok, this is more philosofical than anything else.

basically, the scenegraph should keep a hierarchy of objects within a scene, when one node is attached to another, then it inherits all/some of its properties (translation, rotation, etc)... however I came into a dillema while implementing a scene graph for my graphics engine:

should each node in the scene graph keep track of its current position? (making the graphics engine user just update how much will it translate from its current position) like this:


MyNode->translate( 10, 0, 0 ); // located at <10,0,0>

// next frame

MyNode->translate( 10, 0, 0 ); // located at <20,0,0>

// next frame

MyNode->translate( 10, 0, 0 ); // located at <30,0,0>


making MyNode to move on steps of 10 units each loop.

Or should the user keep track of each object's position and just update on what position should the object be placed, like this:


MyNode->translate( 10, 0, 0 ); // located at <10,0,0>

// next frame

MyNode->translate( 20, 0, 0 ); // located at <20,0,0>

// next frame

MyNode->translate( 30, 0, 0 ); // located at <30,0,0>




what do you think would be more appropriate?
"lots of shoulddas, coulddas, woulddas in the air, thinking about things they shouldda couldda wouldda donne, however all those shoulddas coulddas woulddas ran away when they saw the little did to come"
Advertisement
both.png
struct MyNode { Transform transform; };
myNode->transform.translate = Vec3( 20, 0, 0 );
myNode->transform.translate += Vec3( 10, 0, 0 );
The transform-hierarchy/"scene graph" doesn't have to be concerned with where your translation data comes from. By allowing the user to set/update the data in either way, as above, you might make your "scene graph" simpler and more re-usable.

The "scene graph" only has to be concerned with how to inherit/propagate data along a hierarchy -- in the case of a transform-hierarchy, you've basically got an array of transform nodes, which contain a transform and an optional link to a parent node.
The only task that your transform-graph should focus on, is producing an array of global/absolute transforms out of your input graph of local/from-parent transforms. If it focuses on more responsibilities than that, then you'll fall into the classic "scene graphs" trap of trying to use a single data-structure for too many different tasks
Usually you have the position and rotation encoded in a matrix saved in the node.

Then you can add support for postTranslate (or whatever you want to call it) on your matrix class, and do either or, depending on your use-case that day.

Edit: hodgman beat me to it..
haha.. I really wasted a lot of time trying to figure out which was more appropriate hahaha... but yeah, I guess you're right.. thanks to both of you!
"lots of shoulddas, coulddas, woulddas in the air, thinking about things they shouldda couldda wouldda donne, however all those shoulddas coulddas woulddas ran away when they saw the little did to come"
A function called "translate" would imply an append operation.

Looking at the example code posted by Hodgman, I would just change translate to translation.

+---------------------------------------------------------------------+

| Game Dev video tutorials -> http://www.youtube.com/goranmilovano | +---------------------------------------------------------------------+

This topic is closed to new replies.

Advertisement