Jump to content
  • Advertisement
Sign in to follow this  
chippolot

General Question on Scenegraphs

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

Before I begin, I've read all the tutorials and articles on scenegraphs I could find on the internet, and also the chapter in Game Coding Complete v2 (excellent book, btw). However, I have a really general question. I think I understand, for the most part, what a scenegraph is and how it works. What I don't understand is how a scenegraph works in conjunction with the rest of your graphics engine. So, when you code your architecture around a scenegraph... does it basically encapsulate your engine? For example... do I still store a drawable list of objects, or are those objects located solely in my scene graph? Do I store a list of lights? or are those lights only in my scene graph? If I don't have many hierarchical models is it even worth making a scenegraph at all? I basically am looking to design a system that can adapt easily to fit in new features. Ex: When I learn shaders, I'd like to be able to "plug them in". In a scene graph, I guess I'd make them group nodes. This was a little long winded, it just confuses me that a scenegraph (tree) could somehow store all the objects in a game cleanly. Any input?

Share this post


Link to post
Share on other sites
Advertisement
The way that I've always seen it, and the way I'll be fleshing out my scenegraph system, is that the scenegraph will store all of the level data, models, lights, whatever. Then, when you want to render the view, grab only the data you need by using the scenegraph, and render only that data.

Like, you'd have a persistent list of renderables, then when you enter the rendering function, you cull the renderables that you can't see, and perform normal rendering on the (post-cull) render list.

Share this post


Link to post
Share on other sites
Quote:
Original post by chippolot
Before I begin, I've read all the tutorials and articles on scenegraphs I could find on the internet, and also the chapter in Game Coding Complete v2 (excellent book, btw). However, I have a really general question. I think I understand, for the most part, what a scenegraph is and how it works. What I don't understand is how a scenegraph works in conjunction with the rest of your graphics engine.


Did you check the links in the new sticky by snk_kid?

Quote:
Original post by chippolot
So, when you code your architecture around a scenegraph... does it basically encapsulate your engine? For example... do I still store a drawable list of objects, or are those objects located solely in my scene graph? Do I store a list of lights? or are those lights only in my scene graph?

All of these are design issues you'll have to decide on yourself. Basically there are two approaches: have every entity in your game inherit from a scenegraph node and put both graphics and game funtcionality in it, or separate your game entities and their logic from the scene graph and let them store a pointer to their graphical representation. I think the sticky contains links to threads about this and related topics.

Quote:
Original post by chippolot
If I don't have many hierarchical models is it even worth making a scenegraph at all?

Maybe not, but it may run into a situation where you could benefit from spatial hierarchy fairly quick: e.g. the gun in the hand of a soldier, the driver of a car, etc.

Quote:
Original post by chippolot
I basically am looking to design a system that can adapt easily to fit in new features. Ex: When I learn shaders, I'd like to be able to "plug them in". In a scene graph, I guess I'd make them group nodes.

Beware, there are big problems with your example. If your scene graph is supposed to represent spatial hierarchy, a shader as group node breaks this purpose. The children of the shader node won't have a spatial relation but a graphical relation (i.e. they 'look' the same). IMO, your graph should focus on a single purpose. If you need more functionality, construct another graph for this (or in case of your shader groups: sort the objects in the graph before rendering to make sure that objects with the same shaders/textures/etc. are drawn in sequence). Note that this view pretty much makes it impossible to use the first of the two approaches I mentioned before.

Quote:
Original post by chippolot
This was a little long winded, it just confuses me that a scenegraph (tree) could somehow store all the objects in a game cleanly. Any input?

If you think you can't, then don't. Just store graphical representations inside game entities, and not the other way around (game entities/logic in the scene graph).

Tom

Share this post


Link to post
Share on other sites
Hi,

I'll just expose how I see the thing. It might give you some ideas.
For me, a scenegraph is just a hierarchy tree which is used to store almost every data of your scene. Using a set of virtual classes, you can store geometry nodes, light nodes, occlusion nodes, etc. in your SG.

Then, at runtime, you'll parse your SG, and will send any visible data to a renderer, which is basically a bunch of queues (vertex / index buffer queue, material queue, etc.) After the SG is parsed, the renderer can then do its work : sort data by shaders, materials, etc. and render.

For me, the SG should be completely free from any API specific functions. I mean the exact same SG should work with a OpenGL or a DirectX renderer without any change. For that, I'd use resources managers, and the node of the SG would only have resources IDs (or a pointer to a virtual resource class that would encapsulate the API specific one)

In this setting, adding shaders is quite straightforward : simply create a shader resource class, add a shader queue in your renderer, and add the possibility to link a shader resource to the nodes that need it. Done.

As said before, read the sticky on this forum, there are many good links. And also read the book "3D Game Engine Architecture" by D. Eberly. Amongst the books I've read, it's the most complete on scenegraphs.

[Edited by - paic on October 10, 2005 4:13:51 AM]

Share this post


Link to post
Share on other sites
I´d second dimebolt´s warning about mixing spatial sorting and sorting based on appearance in one SG. I would use the SG solely for spatial/logic representation of the scene.
Still, your SG should contain enough information for the renderer to actually render a mesh (or something) in the way you want it to. For that I would use paic´s approach of a resource manager, and the SG nodes only containing ID´s or pointers to the needed resources (textures, shaders, materials, the mesh´s buffers). I wouldn´t sort the SG based on that stuff, though. I´d leave that to the renderer class, so you can concentrate on logical representation of the scene in the SG. That way you should also be able to achieve paic´s recommendation (which I again second) of making the SG API-independent.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!