Quote:Original post by ApochPiQ
Sure, there's coupling, but coupling is not always evil. Sometimes things make sense coupled.

As i said already whether this is acceptable or not depends on the context.

Quote:Original post by ApochPiQ
In any case, this is still a very loose coupling; it's still very easy to program to an interface and not an implementation. Honestly, if linking the two structures leads to a coupling to the actual implementation of either data structure, then the programmer has broken something by introducing a poor design.

I wouldn't quite call it loosely coupled because really it isn't, obviously it's better to depend on an interface than an implementation i'm not debating that but the fact of the matter is you've still tied it to one particular interface, in this context some abstract scene graph node. One cannot reuse this spatial data structure any where else.

There are various methods to make them more/less loosely coupled all with different levels of abstraction and/or levels of indirections and all with different trade-offs.

Quote:Original post by ApochPiQ
That doesn't necessarily mean that the design concept (separate, linked structures) is at all to blame.

I'm not saying that, all i'm saying it isn't quite as "clean" or loosely coupled as you make it out to be but one has to eventually make a choice and it all depends on your requirements.

Quote:Original post by ApochPiQ
Really, though, that's more or less academic, since the two systems are fundamentally interrelated by nature.

I wouldn't call it academic, it all depends on the context and requirements and i wouldn't say there "fundamentally" interrelated yes maybe indirectly but a scene graph is not a fundamental concept in the problem domain of spatial data structures.

Spatial data structures are data structures that deal with multidimensional data. The algorithms which build these structures take geometry as input, there typical is no notion of scene graphs in there definition.

You bring up a good point that the input to building any of these structures is geometry. On that note, you could consider a scenegraph, quad/oct-tree, BSP tree, or any sort of spatial subdivision structure an index into a set of scene data. Its just like any other index into a database, where the indices establish different views of the data.

Regardless though of how these indices are built; whether independently, or in a way that interdependancies exist (at the structure node-level) data is shared (at the leaf level where geometry is specified). If you desire transformation and other spatial-sensitive data (such as AABBs) to be available and valid, then the sharing takes place at a level where this data is specified (I assume a model where geometry is "instanced" by independent tranformation nodes). Regardless of what index you use, the tightly coupled nature of the beast becomes apparent (is this what snk_kid was getting at?) when you ponder about how all this data can be kept consistent. If an object moves, all indices that reference this object must be updated accordingly. Again, how do you do all of this in an efficient way (much simpler if structures are entirely sperate)? I understand how scene graphs can propogate changes both up and down the tree efficiently, but it becomes more intricate when complex relationships are established between seperate (types of) structures.

Going back to my initial question, how do you deal with such seperate structures in a practical implementation? Don't you think there should be a single unified mechanism (entry point) through which to perform an sort of queries on these structures? If so, where do you begin to dive into them if they are seperate (not a hierarchy)? How do you yield useful results from queries on seperate structures when the query depends on a coupling (usually spatially sensitive) to provide for efficent/logical structure traversal. Alternatively, if strutures are nested how do you nest them so that your quries are efficient and dont have to dive miles deep into a tree (see my terrain/quadtree example above)?