Hi all,
I've been working further on my scene-graph, and decided to implement an Octree to keep track of the static geometry in my scene.
Rougly, my scene currently looks like this:
RootNode
- staticGroup
-- octreeRootNode
--- 8 child octreeNodes, which can contain 8 child nodes again, also each octreeNode has a vector of MeshInstanceNodes
- dynamicGroup
- skyGroup
- invisibleGroup
This hierarchy is based off the one described in the book, and I'm also basing it off of this discussion: gamedev.net/topic/110342-terrain-and-scene-graphs/ (post number 6 by Yann L)
Basically I've created my own Octree structure that plugs in perfectly with the scene graph. The OctreeRootNode does the overlaying management of checking visibility of the MeshInstanceNodes in the child octreeNodes, and then renders these efficiently.
However I'm not entirely sure how I want my octree to be set up initially, and how inserting new meshInstanceNodes should affect the Octree's structure. I'll describe my current algorithm a bit, and its shortcomings:
- The octree has a limited depth, let's call it DEPTH_LIMIT (say 10 levels of child octree nodes), and a limited amount of mesh instances that each child octree node can contain which I'll call MESH_LIMIT.
- Initially there is only one Node, that of the root node.
- When a new meshInstanceNode wants to be inserted, first a test is done to see if the mesh will physically fit inside the octree node. If succesful, a test is done to see if the octree node has enough room in its vector (comparison with MESH_LIMIT), the node will then add this mesh instance to its list if the limit isn't exceeded. However, if the limit is exceeded, the node is split into 8 child nodes (if allowed by the DEPTH_LIMIT), all the nodes are re-distributed into the child nodes, and an attempt is done to add in the new mesh Instance Node into one of the new child nodes.
- The addChild method is recursive, as the previous sentence roughly describes.
- If the attempt to add the mesh instance to the child node failed for any reason, it is simply left in the parent node of those children.
There's a few other tidbits, but they're not as important to the discussion
Hopefully my description is somewhat understandable to get the gest of what I'm doing. The drawbacks of this approach are:
- you only do any node splitting on insertion of nodes
- my last point in the algo description means that I'm left with "dangling" mesh instances in some parent nodes, and that not all the leaf nodes contain all the mesh instances per sé.
My questions to you are:
- should I already initially split up my octree into several sections, rather than starting off with just one node? If so, how "deep" should the octree be initialised?
- would it be better to push all meshInstances as deep as possible into the octree, and for overlapping meshes keep duplicate pointers to them? Also, when doing visibility and rendering, how do you determine a distinction between these duplicates? (perhaps a flag in each MeshInstanceNode: detectedForRendering ?)
- when should I split an octreeNode to create child nodes?
I look forward to your feedback and suggestions! Thought it was best to get this important part of my scene graph done "right" from the start
Oh btw, in the book you mentioned this neat debug-camera feature in which you could have a "backstage pass" into the game's mechanics. I also implemented this and am finding it very useful :D[list]
[/list]
I've been working further on my scene-graph, and decided to implement an Octree to keep track of the static geometry in my scene.
Rougly, my scene currently looks like this:
RootNode
- staticGroup
-- octreeRootNode
--- 8 child octreeNodes, which can contain 8 child nodes again, also each octreeNode has a vector of MeshInstanceNodes
- dynamicGroup
- skyGroup
- invisibleGroup
This hierarchy is based off the one described in the book, and I'm also basing it off of this discussion: gamedev.net/topic/110342-terrain-and-scene-graphs/ (post number 6 by Yann L)
Basically I've created my own Octree structure that plugs in perfectly with the scene graph. The OctreeRootNode does the overlaying management of checking visibility of the MeshInstanceNodes in the child octreeNodes, and then renders these efficiently.
However I'm not entirely sure how I want my octree to be set up initially, and how inserting new meshInstanceNodes should affect the Octree's structure. I'll describe my current algorithm a bit, and its shortcomings:
- The octree has a limited depth, let's call it DEPTH_LIMIT (say 10 levels of child octree nodes), and a limited amount of mesh instances that each child octree node can contain which I'll call MESH_LIMIT.
- Initially there is only one Node, that of the root node.
- When a new meshInstanceNode wants to be inserted, first a test is done to see if the mesh will physically fit inside the octree node. If succesful, a test is done to see if the octree node has enough room in its vector (comparison with MESH_LIMIT), the node will then add this mesh instance to its list if the limit isn't exceeded. However, if the limit is exceeded, the node is split into 8 child nodes (if allowed by the DEPTH_LIMIT), all the nodes are re-distributed into the child nodes, and an attempt is done to add in the new mesh Instance Node into one of the new child nodes.
- The addChild method is recursive, as the previous sentence roughly describes.
- If the attempt to add the mesh instance to the child node failed for any reason, it is simply left in the parent node of those children.
There's a few other tidbits, but they're not as important to the discussion
Hopefully my description is somewhat understandable to get the gest of what I'm doing. The drawbacks of this approach are:
- you only do any node splitting on insertion of nodes
- my last point in the algo description means that I'm left with "dangling" mesh instances in some parent nodes, and that not all the leaf nodes contain all the mesh instances per sé.
My questions to you are:
- should I already initially split up my octree into several sections, rather than starting off with just one node? If so, how "deep" should the octree be initialised?
- would it be better to push all meshInstances as deep as possible into the octree, and for overlapping meshes keep duplicate pointers to them? Also, when doing visibility and rendering, how do you determine a distinction between these duplicates? (perhaps a flag in each MeshInstanceNode: detectedForRendering ?)
- when should I split an octreeNode to create child nodes?
I look forward to your feedback and suggestions! Thought it was best to get this important part of my scene graph done "right" from the start
Oh btw, in the book you mentioned this neat debug-camera feature in which you could have a "backstage pass" into the game's mechanics. I also implemented this and am finding it very useful :D[list]
[/list]
Cheers and beers from Belgium!