I've been going through the code files for the SpaceWars sample game. I was somewhat confused by the SceneItem class, because it inherits from List<SceneItem>. This throws me off because I wouldn't expect a "scene item" "is a" list of scene items. Does anyone have any insight into the logic here?
SceneItems is a hierarchy - and can have child items below it. So it makes sense that a scen item is indeed a collection of other SceneItems
Yes this could have been handled buy having a member which contains the child items but its just a design choice I made.
Thanks for the reply.
Yeah, it's pretty neat.
For some reason, I just found it a little hard to get my head around.
I've just never come across this type of recursive type definition before.
Hi Zman,
This is a nice way of handling a SceneItem, one thing I was wondering though is the best way to propagate transformations through the heirarchy.
I can only think of simple approaches such as
public void Position
{
get
{
return Parent.Position + _Position;
}
set
{
_Position = value - Parent.Position;
}
}
This is a simple example and not even tried it however this is one way I thought about it by storing only the local position and returning the parent + local position as the absolute position
Any thoughts on this?
regards
Fluxtah
I see, that would be a problem, I need to think up an elegant way to do it once per frame.
public void updatePostion(Vector2 deltaP)...(it's 2D stuff I'm working on)
I calculate the delta every frame and call the function, then the Position-Property is accessible
without side-effects...there could be the place to calculate once but I guess you have to add a
member more to store all data; parent postion, local offset and one for the sum of both...
this frees property-access from calculating each time....
maybe this idea helps,
cheers
In general, in hierarchical scene graph, you will end up implementing a hierarchical "dirtying" system, where all children of a node being "dirtied" will be dirtied as well (recursively). You only need to dirty down until you find a child that's already dirtied, because it's transitive.
When a node is asked about its world transform, and it is dirty, it re-calculates it by multiplying the parent transform with its local transform, and clearing its dirty bit.
For culling, you probably want to propagate bounding information from the children, up through the parent -- again, if you want to create a traditional, hierarchical scene graph.
I almost understand what you are saying but one thing that confuses matters is how to set the position or rotation of a child in relation to the parent object.
If I had a SceneItem s and set s.Position = 50.0f; should that be the position in the world or relative to the parent?
Would it be an idea to have two ways to set / get the position, maybe WorldPosition and RelativePosition? I am not sure, maybe I need to experiment rather than ponder.
My first game is a 3d arkanoid clone so it does not need to have this kind of relationship between scene graph nodes, although when I move on to a more adventurous game I would want a more robust scene graph.
For culling I would probably use an octree as I would like to make a space game for my next game and that would also serve as a good collision system, although I would probably only start with a space dog fight first :)
In slightly fuller-featured scene graphs, you can set (and get) the position either relative to the parent, or relative to the world. When setting the position relative to the world, you either set a flag saying "don't inherit parent position/rotation," or you get the parent transform matrix, and transforms the incoming world position by the inverse of that matrix, to get your new local position. The difference is in what happens if the parent moves/rotates after the child has been set in world space.
