Simple scene managment question
Author
Hi,
I'm working on a small (really small) demo. Nothing big and fancy like some of the guys here.
I arrived at the time when I shall worry about putting meshes into the scene, to make the scene coherent. Usually I don't have a lot of object so I just use a world matrix (transformation) for each of them. However this time I have to go further.
I hesitate between using octree and scene graph. I understood octree, from what I learned, it is a way of dividing space into logical entities.
I read the different topics and article on the site about scene graph, I have the basics but that's it.
From what I understood with a scene graph, some node are transformations, others are objects to be rendered. The aim is to organised the scene into a logical and spatial representation.
I have three questions:
-How can I select what to render with a scene graph.
-Why is it efficient exactly ?
-Regardless of the difficulty, what should I use if my only concern is effency and all shader base operation are handle by the mesh, itself?
Thanks
PS: I post this because I don't understand related topics about this problem, please be patient.
Hi
There is many ways to do it.
The node of your graph can be a struct with a type and an union.
A node can be an abstract class of object to render and a transformation node and you do the difference with a dynamic cast.
Octree is efficient because with one test you can avoid to render 1/8 th of the space.
If it's a really very small demo perhaps you can just use a linked list ?
But any way I think that octree works fine.
Quote:Original post by lollan
-How can I select what to render with a scene graph.
There is many ways to do it.
The node of your graph can be a struct with a type and an union.
A node can be an abstract class of object to render and a transformation node and you do the difference with a dynamic cast.
Quote:Original post by lollan-Why is it efficient exactly ?
Octree is efficient because with one test you can avoid to render 1/8 th of the space.
Quote:Original post by lollan-Regardless of the difficulty, what should I use if my only concern is effency and all shader base operation are handle by the mesh, itself?
If it's a really very small demo perhaps you can just use a linked list ?
But any way I think that octree works fine.
Simple?
Make your scene a list of drawable entities.
Don't bother with the octree, just do a straight up compare of the bounding volume of each entity with the camera frustrum.
Simple, easy, and a lot of AAA games have shipped with nothing more than this.
Make your scene a list of drawable entities.
class Renderable{ // Other stuff ... float4x4 worldTransform;};class Renderer{public: ... void AddRenderable( Renderable* ); std::vector< Renderable* > mRenderables;};Don't bother with the octree, just do a straight up compare of the bounding volume of each entity with the camera frustrum.
Simple, easy, and a lot of AAA games have shipped with nothing more than this.
SwitchIn : I agree. I used a simple std::vector< IRenderable * > g_Objects; in a quite big professional project and it worked fine.
But the advantage of a scenegraph (as I see it, and i'm using it for the next generation of our product) is that you organize your entities not spacially (this is the role of an octree / quadtree) but logically. If you transform 1 node, all its children will be transformed too.
When you compute bounding boxes, a node's BB should also contains all its children ones. This way, when you do frustum culling, when a node fails the test, you know that all its children won't be visible too.
So it's really up to you to choose : you can go the simple way with a simple list if you know your project won't grow too much. Or you can choose to implement a slightly more complex structure such as a scenegraph if you want to have a few more functionalities (the 2nd and 3rd paragraph were 2 examples of such things)
But the advantage of a scenegraph (as I see it, and i'm using it for the next generation of our product) is that you organize your entities not spacially (this is the role of an octree / quadtree) but logically. If you transform 1 node, all its children will be transformed too.
When you compute bounding boxes, a node's BB should also contains all its children ones. This way, when you do frustum culling, when a node fails the test, you know that all its children won't be visible too.
So it's really up to you to choose : you can go the simple way with a simple list if you know your project won't grow too much. Or you can choose to implement a slightly more complex structure such as a scenegraph if you want to have a few more functionalities (the 2nd and 3rd paragraph were 2 examples of such things)
Author
Hi,
Thanks all! Each of your reply open some perspective I didn't see before.
I was so focus to produce a good demo that by default I limited my options lol.
In fact you all are right, doing a list is much easier and in a way for a small project more efficient. However I think I will go in a first time for the list and then when the time to go further with the demo come, I'll go for the octree.
Thanks to all I now understood why a scene graph is efficient but I don't think that scene graph should be use for small project.
Thank you all
Thanks all! Each of your reply open some perspective I didn't see before.
I was so focus to produce a good demo that by default I limited my options lol.
In fact you all are right, doing a list is much easier and in a way for a small project more efficient. However I think I will go in a first time for the list and then when the time to go further with the demo come, I'll go for the octree.
Thanks to all I now understood why a scene graph is efficient but I don't think that scene graph should be use for small project.
Thank you all
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
