   Scene Management :D
  I'm in the process of implementing some kind of system to manage my scene. I was thinking to start using an Octree for now (no fancy fat scene graph structures ). However I have to admit that the possibility to know the hierarchical relation between for example lights and some other objects in the scene, or a particle system, could let the frustum culling routine be more general and relative to objects instead of necessarily just meshes (like would be the case of a simple and raw Octree). But maybe I could think about that octree in a more general way ? I mean not strictly used for spacial partitioning of meshes only :D.My worry is just to not to be able in the future to handle all the things in the right way, like when I'll want to cull lights, particle systems and anything that could be potentially culled. I say this because for now I'm going just to implement the frustum culling for meshes (i.e. renderables).Plus (one last question), in the past I used to always implement the Octree node like:struct Octree_s{    struct Octree_s* pChild[8];};is this struct a naive way to implement it or there is a better way ?Thanks loads in advance for any help and advice   
struct Octree_s{    struct Octree_s* pChild[8];};In C++, you only needstruct Octree_s{    Octree_s* pChild[8];};.Then, I would just savestruct Octree_s{    Octree_s* pChild;};which will save you 7*4 or 7*8 bytes for leaf nodes. If your tree is irregular, i.e. some children might exist, others not, you could also do struct Octree_s{    Octree_s** pChild;};where (pChild != 0) tells whether you have a leaf node, and (pChild[x] != 0) tells you whether that particular child exists.Don't forget that leaf nodes make up the majority of nodes (or in other words, inner nodes are in utter minority), so this will save a lot of RAM in most cases:level0: -level1: --------level2: ----------------------------------------------------------------;Quote:Original post by phresnel *** Source Snippet Removed ***In C++, you only need*** Source Snippet Removed ***.Then, I would just save*** Source Snippet Removed ***which will save you 7*4 or 7*8 bytes for leaf nodes. If your tree is irregular, i.e. some children might exist, others not, you could also do *** Source Snippet Removed ***where (pChild != 0) tells whether you have a leaf node, and (pChild[x] != 0) tells you whether that particular child exists.Don't forget that leaf nodes make up the majority of nodes (or in other words, inner nodes are in utter minority), so this will save a lot of RAM in most cases:level0: -level1: --------level2: ----------------------------------------------------------------Are you thinking implicitly about loose Octrees at some point here in your post (a part from saving memory implementing the struct as you suggested, which is useful) ?Plus, do you think I would need to manage the octree separated from, for instance, a more high level graph (e.g. a graph handling lights, octrees and so on...) ?One last question (sorry for so many questions): How I would manage the idea to have the scene stored on a file on disk, given the fact that for example I do not have an editor to organise the scene and most of the time the meshes that I have don't come from a scene file but they are separated (so not in the context of a scene) withuot any relation with particle system, lights and so on ... Is there any existing package to allow this ? Or I have to write my own ?Note: What about using a pool of preallocated nodes, managed as a linked list from which to allocate nodes and relase them (to fight memory fragmentation)?Thanks again for any help[Edited by - MegaPixel on September 2, 2010 8:49:19 AM];Quote:Original post by MegaPixelNote: What about using a pool of preallocated nodes, managed as a linked list from which to allocate nodes and relase them (to fight memory fragmentation)?Thanks again for any helpNote that, in order to fight memory fragmentation, you would need to use a vector, not a linked list.In most scenes, however, I would think it would just be easier to create all the leaf nodes and then disable them if they contain no entities. A boolean check for each leaf node would not be expensive, and the memory overhead of empty leaf nodes wouldn't be a problem unless you're talking about a ridiculous number of levels.Of course, if an object moves into an empty node, it must be enabled again.   ;Quote:Original post by XeonXTQuote:Original post by MegaPixelNote: What about using a pool of preallocated nodes, managed as a linked list from which to allocate nodes and relase them (to fight memory fragmentation)?Thanks again for any helpNote that, in order to fight memory fragmentation, you would need to use a vetor, not a linked list.In most scenes, however, I would think it would just be easier to create all the leaf nodes and then disable them if they contain no entities. A boolean check for each leaf node would not be expensive, and the memory overhead of empty leaf nodes wouldn't be a problem unless you're talking about a ridiculous number of levels.Of course, if an object moves into an empty node, it must be enabled again.Yeah of course I use a vector, I've made a mistake writing linked list. I actually use a vector to hold a block of contiguous memory and a vector of pointers that will hold free pointers to the location of the previous vector.Concerning the approach of creating all the leaves, I'll think about that as I'm still wondering on my scene graph architecture and the octree will be just used in one of the scene node (as for example to handle complex static geometry).Thanks   