Members - Reputation: 265
Posted 19 April 2012 - 10:46 AM
I was hoping for maybe some design advice with what to do! Thanks
GDNet+ - Reputation: 1813
Posted 20 April 2012 - 12:54 AM
I'm afraid I don't understand the rationale of this. Would you elaborate? As long as the rationale is not understood, I'm not sure the solutions would match your needs.
at the moment if there is multiple copies of the same scenegraph(aka the same model) it will just create a new scenegraph linking. I mean this works all well and good however the loading time is insane.
Perhaps I am being pedantic but if the loading times are insane... I guess it's not "well and good"?
Then don't do that. Do it the other way around if you need this but in my opinion, If you're doing a scenegraph in the appropriate sense (to save on state propagation) then you're doing everything wrong. There has been multiple threads in the past about scenegraphs (for state propagation) to be bad in general: don't use them.
Which is to be expected. I have tried to load the models scene graphs and simply just have the world link to these however... When i need to travel up the scenegraph the model doesnt know anything about the worlds unless you count the last one that was using it. Making it impossible to render the models in the right place as everytime you travel up the scenegraph you get into the problem of not knowing where to go from the models node to get to the world node.
I recall this (please pay attention to Hodgman), but similar questions arise regularly, some google-fu is strongly encouraged.
Moderators - Reputation: 14313
Posted 20 April 2012 - 04:49 AM
Scene Graphs - Just say no.
One of the goals you see of some scene graphs -- particularly those that emerge from academia or overly complex frameworks -- is that the perfect rendering order arises naturally as a consequence of how the scene graph is arranged for traversal. So during a single traversal, you're able to transform, cull, and render efficiently during the traversal. That single structure is supposed to minimize the amount of maintenance necessary, and provide a very elegant arrangement for getting your scene rendered.
This is absurd.
This design mixes three unrelated structural ideas into one. First is the hierarchical culling structure. Second is the transformation hierarchy. Third is the optimal rendering order (for batching etc). These are three different trees, which are going to have different arrangements and different structures. Most scene graph related research proceeds with the goal of merging these three contradicting trees into one. Things like switch nodes and DAGs emerge as a result, trying to provide more sophisticated control of this single traversal.
Personally I think you're better off running it in discrete steps with discrete (and highly compressed) structures. So first, you do transformations across the board. Then you cull and collect a list of visible objects for the frame. Lastly, you do a fast sort across those objects to get a final list with optimal batching.