   Implementing scene graph, where to start?
  Hi there! Finally I got my window and render devices up and running with minimal features than I need now.Now I would like to render something :DSo I thought to create some basic resource system and add Mesh resources to it. I could just pass the mesh to render to make sure that I can render things, but I understood that many uses so called Scene managers that implemented as graphs/trees (also side question: should scene manager handle removal of invisible objects or its done in other places?).So I would like to get some information about Scene Graphs (not from gamedev.net since I read everything I could find here) or others methods to manages scenes.Thanks a lot!   
  Think about it top down if you want.Display Monitors [] - ViewSurfaces []  - ViewPorts []   - Camera   - Scene    - GeometryInstances[]    - Lights[]    - Scenes[]Thats about all the scene graph that i would advocate. And it's not really used for iteration control. It's just a convient and logical way to store all the data.The issue comes when a material referenced by a GeometryInstance is dependent on the output of another ViewSurface. The other ViewSurface must be rendered before the previously mentioned geometry can be rendered. Shadow maps, cube maps, and jumbo-trons are good examples of this case.You can:A.) Register the view surfaces to a render pass manager, comprised of layers. High priority layers such as depth maps will always be rendered before low priority ones, such as the final composition pass.B.) Create a recursive iteration device which will iron out the dependencies while it traverses, and execute them on its way out.C.) Come up with your own dern ideas. :PTo answer your side question, everything in the Scene object should be stored in a spatial partioning system. Maybe an Octree. It's not too often that you'll want to just linear iterate them. You'll always be doing some kind of spatial query. Even the Scenes in the Scene should be partitioned so that if a Scene cell is not visible, then the child Scene is entirely not queried.Good luck to you.I'm sure other people on this forum have a widely different opinion.   ;  Ok I got it, thanks!   ;  A scene-graph is a simple way to structure scene data, but not necessarily an effective one.I find that my scene graph is rarely more than 2-3 layers deep, which pretty much eliminates any benefit one might gain from heirarchical culling/similar. In addition, when one introduces multiple cameras and render-to-texture effects (reflections, shadows, etc.), the structure is no longer very tree-like from the renderer's point of view, instead becoming a DAG (directed acyclic graph).Consequently, I now use a very light-weight 'scene tree' to handle transforms, and a separate sparse kd-tree for culling.   ;  By creating "nodes" in your scene graph you can easily created a tree structure for nested geometry.It is very helpful for things like solar systems.  You can have the sun at the root, then each planet nested around the sun, each moon nested under each planet, then you can have people nested under "earth" and nested under the person you can have objects that s/he are carrying.When you go and render the scene, you don't have to worry too much about figuring out in 3D space where the calaculator should be that the guy is holding in his pocket if you have a scene graph.  The nodes will traverse down to the ends and find the coordinates for you automatically.I made video tutorials showing how to create a scenegraph if you are interested in the details, have a look.   ;  Thanks all for comments, now its more clear for me!   