Sign in to follow this  

one vs many Scene(Object) Graphs

This topic is 4357 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, I have been a silent observer for a while now and have finally got some questions which I couldn't find a satisfactory answer to (although some posts did help me get to where I am now). Anyway I am working on the handling of all my scene objects, and originally I was just going have a tree-structure and handle Update/Render/Collision going down the hierarchy tree. Then as I read some posts I realised that this tree needs to change based on what you want the objects to do. For instance when Rendering you want to order the objects/tree by materials. I have come up with the following structure: Note: doing in c# but really is code independent - but below is in hack code :-) The following objects: SceneNode which implements IDynamic, ITransform RenderObject::SceneNode which implements ICollidable, IRenderable Camera::SceneNode which implements ICamera Brief description of the interfaces: IDynamic - contains Update(deltaTime) ITransform - contains Transform() and all transformations (children, rotation, scale, etc) ICollidable - contains bounding informatio IRenderable - contains Render() and information about geometry, materials, etc ICamera - contains all camera information with this structure I then have the following Management classes: ObjectManager { SceneNodes<SceneNodes> - all scene nodes .Add() - add to appropriate managers below .Delete() - delete from appropriate managers below } SceneManager { DyamicObjects<IDynamic> - all IDynamic objects (Note: doesn't need to be SceneNode) RootTransforms<ITransform> - all root transforms this manager will call Update() and Transform() every frame } RenderManager { RenderObjects::Map<Material, IRenderable> - map which groups IRenderables by material this manager will call all RenderObjects in groups of Materials, setting up the Material state only once } PhysicsManager { CollidableObjects<ICollidable> this class hasn't been thought through yet but will handle physics and collision, not very relevent. } So if anyone has any ideas/thoughts on the above please let me know. Also I have some questions: 1. One problem is that part of the SceneManager structure is partially stored in the ITransform implementation as it keeps track of children objects, I see this as not good in design, but cannot see an easy way around it? 2. Is there going to be a worrying ammount of overhead keeping so many list/trees? 3. Is texture swapping the most expensive change, followed by shading swapping? It appears so and if that is the case am i best to order all my IRenderable objects first by Material and then by Shader, or is there a better order? 4. Other designs seem to keep the cameras/render objects seperate from the SceneNodes (i.e. as properties and not by inheriting), is there an obvious reason for this? Thanks for all taking the time to look and help! Cheers

Share this post


Link to post
Share on other sites
I just realised I can remove the ObjectManager as the SceneManager knows about all the nodes in its object hierarchy.

Also the SceneNode shouldn't implement IDynamic and it should be done on a per object basis, as a lot of nodes (such as camera, billboards, etc) won't need an Update() method.

Share this post


Link to post
Share on other sites
First of all, I'm having a bit of trouble of understanding how all this would work for the user (i.e. the guy specifying the scene to be rendered). After creating scene objects, does he have to sort them into each separate component himself? Or can he create a scene graph, which is subsequently sorted into a render list, a collision structure, etc?

Quote:
Original post by tank104
1. One problem is that part of the SceneManager structure is partially stored in the ITransform implementation as it keeps track of children objects, I see this as not good in design, but cannot see an easy way around it?

If you want parent/child information separated from the ITransform class and defined within the scene manager, you can use the Decorator pattern: define some tree classes (group/leaf) local to SceneManager that contain ITransforms (with a has-a relation rather than the usual is-a (inheritance)). Use these classes to define the hierarchy for their contained ITransforms. I'm not sure if this is a good idea though. A transformation is an operation that should be applied to it's context (children). If you separate data and children, a single ITransform becomes rather meaningless. This means that if an object different from the scene manager requires to apply a transform, he'll have to go the scene manager first (which could also be axplained as a good thing, so I really don't know).

Quote:
Original post by tank104
2. Is there going to be a worrying ammount of overhead keeping so many list/trees?

As a base rule, don't do performance optimization until you run into a performance problem. That being said, there is a simple observation that applies to scene management overhead: the overhead of managing a single scene object is only noticable when the cost is approaching the cost of the actual rendering of that object. This implies that if your management overhead becomes higher, your system will perform worse on applications with many simple (i.e. low rendering cost) objects.

Quote:
Original post by tank104
3. Is texture swapping the most expensive change, followed by shading swapping? It appears so and if that is the case am i best to order all my IRenderable objects first by Material and then by Shader, or is there a better order?

This question is addressed in the OpenGL forum FAQ. Although it's described in the context of OpenGL, it will apply to direct3D as well, as they're useing the same hardware.

Quote:
Original post by tank104
4. Other designs seem to keep the cameras/render objects seperate from the SceneNodes (i.e. as properties and not by inheriting), is there an obvious reason for this?

I believe it's mainly a matter of personal taste. I prefer to put the camera in the scene graph, that way I can simply attach it to the head of an avatar and it will move automatically when this avatar moves. It's a lot less bookkeeping for the user.

Tom

Share this post


Link to post
Share on other sites
Tom thanks for the feedback.

The way I figured it would work is that the person using the engine would inherit objects from either the SceneNode (for non-rendered objects) or RenderObject (for rendered objects) and then add them into the SceneManager (since I have removed the need for ObjectManager). The SceneManager will then check which interfaces are supported in the object and add to the appropriate Mangers, which will take care of the rest.

You raise a valid point about removing parent->child relations and I think I will keep them intact.

Share this post


Link to post
Share on other sites

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