Scenegraphs and Collision trees

Started by
0 comments, last by Pto 14 years, 8 months ago
Im a little confused as to how these techniques are used. Firstly i keep hearing about using a scenegraph to support the transformation and rendering technique of objects in game. I dont see how this could work. How can you group objects by tranformation and rendering technique at the same time? Lets say you have an Army truck, which is carrying a number of men. I understand the transformation process, in that World -> Truck -> Man So that the mans parent is the truck, so that any transformation on the truck then propagates down to the mans root bone. But how are scenegraphs used to group rendering tasks? As the parent rendering technique could be completely different to the childs rendering technique. In which in then becomes a case of sorting by rendering technique or parent/child transformation relationship. I dont see how it can be both. Sceondly, wouldnt it be better to have the collision tree a separate object to the scenegraph? As again, to me, it appears that the representation of the collision tree, would again be completely different, whether its using BSP, or quad/octrees or whatever. So wouldn't it be better to have 3 trees? - One tree which is used to transform objects based on their parent child transform relationship - another tree for calculation of all collisions, which stores all game objects in some manner, lets say as a Quad tree, for optimized iteration - then a third tree which groups all rendering of the same type, so it might group togeather all static mesh renderings, then all dynamic type rendering, and then others such as terrin rendering or ocean rendering.
Advertisement
The scenegraph link of choice.

But that aside - clearly you must have a primary sort method. The other considerations just help to sort tie cases on the primary case (be it transforms or state changes).

Basically its usually a case of profiling and finding the bets sort order. Lots of objects each with its own state (individual texture, shader) might work best sorted front to back because you have to change state per object anyway so why sort? If you have alot of objects but only 2 or 3 different states, then sorting by texture (or shader etc) will probably help you out more.

In every game I've worked on only had 2 systems. 1 for collision detection which was entirely removed from rendering, and the PVS system (usually sorted on texture). In my experience we never have a tree of transform states. How often do you have objects inside others? The truck in an RTS is 1 example but its pretty uncommon, and they will get out eventually so having a tree to work out those transforms usually just ends up with 1 root node with 387873 leaves ... which is clearly pointless. Each object should just have its own world position - then all your physics knows where it is, and you can just render when you like without any traversal required.

This topic is closed to new replies.

Advertisement