Jump to content
  • Advertisement
Sign in to follow this  
skwee

Scene Manager, Scene Node, Octrees, confused

This topic is 3637 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi there. I have a basic resource management system, that manages resources (for now only meshes). I want to implement Scene manager. Few questions about it: 1. Should scene manager be able to do culling (for example by using octrees, or BSP)? Now I know that scene manager holds a pointer to root Scene Node, while each Scene Node holds a pointer to his father and a list of sons. I also know Scene Node can be different types like: Renderable Node (Mesh with Texture, and I think Ill create an object called Entity to represent a full object), Light Node, Sound Node, Transformation Node and etc (correct me if I'm wrong till this point). At this point I'm not sure, but as I understood before rendering the scene, I should traverse the Tree twice, once for updating objects states and second time to actually render them (those which can be rendered), am I right? Is there are something else I should know? Something wrong I said? This issue is really confusing to me. Thanks a lot for help!

Share this post


Link to post
Share on other sites
Advertisement
My architecture involves gathering a render list. I have my scene graph which simply keeps all the instanced nodes, I then call scene_graph.fillRenderList(RenderList3D& list) and it will append nodes to that list. Static nodes are attached to my "sparse grid" (although I could use an octree too if i wished) and moving nodes are BVH trees.

This list is gathered once per second, using a spherical bounding volume vs each tree. This lets me cut out the vast majority of the scene which will not likely be rendered, while not excluding any data that is not visible but may become visible in the next frame.

At render time, the renderer then takes this render list and applies its own culling to it, this time using frustum culling against the contents of the render list which is now a flat list of lower level objects, such as a VBO or a light. This secondary render list only persists for the duration of one frame.

Not a typical architecture, but its pretty fast (for the moment). I'm currently refactoring a few things (I dont yet have the BVH tree for each moving node, so the scene graph currently has a flat list of single moving nodes) so that smart ptrs are involved.

Share this post


Link to post
Share on other sites
Thank you a lot for your comment! I really appreciate it. It helped me a lot!
Thanks again!

Share this post


Link to post
Share on other sites
The system I use is similar to what speciesUnknown uses but without doing any culling in the scene graph itself. If nodes want to be renderable they implement an interface ISceneGraphRenderable and override the AddToRenderQueue(RenderQueue targetQueue) function.

To render I iterate over the tree and call AddToRenderQueue() on each node that implements the interface. The quadtree nodes for example then do their culling here and add what is visible to the queue.

My current scene setup looks something like:

RootNode
|
|-- StaticWorldGeometry (QuadtreeNode containing Geometry)
| |
| |-- StaticWorldLights (QuadtreeNode containing Lights)
|
|-- NPCS (QuadtreeNode containing SkinnedMeshes)
|
|-- Player (SkinnedMeshNode)
|
|-- Weapon (SkinnedMeshNode)
|
|-- FlashLight (Light)


I use the scene graph to represent how the objects relate to each other, the nodes themselves take care of any culling. Any transforms are inherited down the tree, this works really well for some things such as my player, when I move him his weapon and the flashlight object attached to it move automatically.

If you want to traverse the tree once or twice is up to you. I do it twice (once for update, once for render) at the moment with nodes that want updating implementing an interface (ISceneGraphUpdateable) in the same way that the render system works.

There are some discussions about scene management with some interesting posts by Yann L such as this, this and this.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kath
The system I use is similar to what speciesUnknown uses but without doing any culling in the scene graph itself. If nodes want to be renderable they implement an interface ISceneGraphRenderable and override the AddToRenderQueue(RenderQueue targetQueue) function.

To render I iterate over the tree and call AddToRenderQueue() on each node that implements the interface. The quadtree nodes for example then do their culling here and add what is visible to the queue.

My current scene setup looks something like:

RootNode
|
|-- StaticWorldGeometry (QuadtreeNode containing Geometry)
| |
| |-- StaticWorldLights (QuadtreeNode containing Lights)
|
|-- NPCS (QuadtreeNode containing SkinnedMeshes)
|
|-- Player (SkinnedMeshNode)
|
|-- Weapon (SkinnedMeshNode)
|
|-- FlashLight (Light)


I use the scene graph to represent how the objects relate to each other, the nodes themselves take care of any culling. Any transforms are inherited down the tree, this works really well for some things such as my player, when I move him his weapon and the flashlight object attached to it move automatically.

If you want to traverse the tree once or twice is up to you. I do it twice (once for update, once for render) at the moment with nodes that want updating implementing an interface (ISceneGraphUpdateable) in the same way that the render system works.

There are some discussions about scene management with some interesting posts by Yann L such as this, this and this.


Your heirarchy makes good sense, I was originally going to do something similar, but it occurred to me that it would be too restrictive - which is why I decided to let the base class of node have an aggregation of nodes of its own type. For example, if you want to put a SkinnedMesh into a car, you cant. If you want to mount a machinegun on top of a vehicle, you cant, unless I'm mistaken in what im reading.

Also, why the specialisation of the player compared to NPC nodes? Don't they ever carry flashlights etc?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!