Couple scene graph questions
Author
I like the idea of a scene graph simply for cheap parent transforms, and that is all I may use the tree structure for. I'm wondering though if I should use scene nodes to also represent bones; it seems a bit too specialized. I'm hesitant about sending a million visitors through my tree say to do things like update skeletons when there is a large change that very few nodes are bones. I'm also wondering about multiple render targets if I was doing split screen for some reason. What would be a clean way to tell the renderer to render certain things to one texture, and other things to a different texture?
Something like: render( "things with tag", "texture", "camera" )
Or maybe link a camera and texture to certain buckets and use buckets all over the place.
Quote:Original post by M4573RI'm hesitant about sending a million visitors through my tree say to do things like update skeletons when there is a large change that very few nodes are bones.
Is there an interesting alternative ? Each time the main body moves or rotates, you will have to update all its bones one by one yourself. I am not sure this is better than doing it through a scene graph.
Author
The bones would still be stored like a tree, breadth first in a vector and handled separately than renderables. At least that is how I've been doing it. I'm just having trouble thinking of how a scene graph can be generic enough to handle the bones without making it "too generic". Maybe there is a clean way of doing it I'm not able to think of that someone else has done.
The way i usually do it:
Treat bones as a subclass of my "Node" class. So they get updated (and drawn, if you want them to) the same way as any other node. Since all nodes can be animated too, animating the skeleton is straightforward. You can also parent stuff to the bones, make a ragdoll...with very little effort. The only real difference with a plain node is that they also have a orientation and some code to do the skinning.
Treat bones as a subclass of my "Node" class. So they get updated (and drawn, if you want them to) the same way as any other node. Since all nodes can be animated too, animating the skeleton is straightforward. You can also parent stuff to the bones, make a ragdoll...with very little effort. The only real difference with a plain node is that they also have a orientation and some code to do the skinning.
Author
I like the benefits of having the skeleton in the scene graph like everything else. But the part I'm having the most trouble with is how to accomplish this in a nice OO way. Lets say I'm traversing the graph with visitors to cull things, but some things shouldn't be culled. Each object now needs a flag for whether or not it should be culled. The same thing happens for debug drawing, some things may want to draw debug or not. I don't want a flag for each visitor, and I want to avoid writing new virtual functions for every new visitor I make. Maybe there are a limited enough cases where I can afford doing it. It just doesn't seem robust enough.
@ArKano22: How do you generically animate a scene node? Doesn't each type of node have different values it might want to interpolate?
@ArKano22: How do you generically animate a scene node? Doesn't each type of node have different values it might want to interpolate?
Personally I like subclassing bones from a generic scene node class, and parenting the skeleton root to the mesh being animated/skinned, because a lot of functionality is the same, and then it's easy to attach objects to bones just like ArKano22 said.
But I don't do culling or update through a scene graph, instead things which have "volume" (geometry, lights, but *not* bones) put themselves into an octree for culling. Actually as a result of this I don't really have a root scene node either; objects can just sort of float in the octree (which is not really that different from a "flat" scene graph where a lot of unrelated objects are just attached to the root node.) But that's just one way to do it...
[Edited by - AgentC on May 6, 2010 10:18:08 AM]
But I don't do culling or update through a scene graph, instead things which have "volume" (geometry, lights, but *not* bones) put themselves into an octree for culling. Actually as a result of this I don't really have a root scene node either; objects can just sort of float in the octree (which is not really that different from a "flat" scene graph where a lot of unrelated objects are just attached to the root node.) But that's just one way to do it...
[Edited by - AgentC on May 6, 2010 10:18:08 AM]
Author
That sounds more like what I'm thinking of doing, simply using the scene graph for parent transforms. When thinking of ways to make a robust graph, I was thinking of making my scene nodes like my game objects, and have them component based. I'd have bone components, bounding component for culling, mesh component, texture component, line list component, etc. That way I wouldn't have to derive new node types. Technically I would only need to keep the transform components in the tree.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
