Sign in to follow this  

Scene Management :D

This topic is 2658 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

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

Share this post


Link to post
Share on other sites
struct Octree_s
{
struct Octree_s* pChild[8];

};




In C++, you only need

struct Octree_s
{
Octree_s* pChild[8];

};



.

Then, I would just save

struct 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: ----------------------------------------------------------------

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
Quote:
Original post by MegaPixel
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

Note 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.

Share this post


Link to post
Share on other sites
Quote:
Original post by XeonXT
Quote:
Original post by MegaPixel
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

Note 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

Share this post


Link to post
Share on other sites

This topic is 2658 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this