Posted 08 December 2012 - 10:58 AM
This depends on what kind of behaviour you want to get out of your scene graph.
In a lot of cases where a hierarchical scene system is implemented the word 'graph' is actually a misnomer, as most of those implementations are tree structures (since it doesn't really make sense in most cases to have cycles in a scene graph unless you're doing some really funky stuff), and to build a tree structure you need a root node.
Of course you could store multiple trees, which is basically what you're presenting. If you store parentless nodes with children in an array you're basically building a forest, and each of these nodes will become roots for their own trees in that forest.
So if you want your scene to be divided into different independent trees, then it isn't necessarily 'bad' to store your different tree roots in an array like you said.
However, the fact that you're trying to do something like this should trigger an alarm-bell. You're trying to 'break the rules' of your chosen data structure to get some kind of different behaviour, which basically tells me that the data structure you've initially chosen (being a scene tree) isn't a good choice for the problem you're trying to solve.
Is there any reason why you need hierarchy within your scene as a default rule, rather than as an exceptional case?
I think a lot of people on these forums will agree with me that the concept of using just a scene tree/graph is starting to get outdated, as the concept of having a hierarchy between objects just plain doesn't make sense in a lot of cases.
Different systems will need different representations of your scene, a physics engine might need to have some sort of partitioned scene structure containing shape and transformation data so it can optimize its collision detection algorithms, while a rendering engine just needs a list of visual data and transformations to crunch. Culling algorithms might need another partitioned structure containing bounding volumes, which again is completely different from what the rendering and physics engine need.
I could go on like this for a while, but I think my point should be somewhat clear by now.
Basically what I'm trying to say is that it doesn't take all too long for the "stick it all in a tree" approach to start breaking down, so if you're at the point where you're trying to somewhat break free from this approach you should maybe try to rethink how you want to handle your scene entirely instead of trying to bend and twist your current approach in ways it wasn't designed for.
Software Engineer - Skybox Labs