Archived

This topic is now archived and is closed to further replies.

Scenegraph + Rendergraph

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

Here''s an outline of the scene management system i''m considering.. i''d appreciate all comments you may have on it. the scene information is divided into two parts: the info on ''logical'' objects, their hierarchy and spatial arrangement is kept in a tree in the ''game world'' class. The actual geometry is kept in the ''geometry server'' class -- when an object is added to the scene graph, it can ''register'' geometry chunk(s) with the geometry server. The server may optionally break received geometry up into smaller, linked series of chunks if the original object is made of different materials, then records the reference to that geometry in its own, state-sorted tree and returns a handle to the registered geometry to the original ''game world'' object. Rendering is then done in (generally) two stages -- first, the game world scenegraph is traversed to determine which objects are visible through the active camera. If the object is determined visible, it can use the geometry handle it stores to set its geometry to ''active'' state. After this pass is finished, the geometry server traverses its own tree, and draws the geometry marked as ''active''. I''m just wondering if someone has practical experience with this approach, and if there''s something inherently wrong with this idea, in term of performance, design or whatever... since it seems that the most common approach is to do some sort of a single ''do-it-all'' scenegraph?..

Share this post


Link to post
Share on other sites
quote:

their hierarchy and spatial arrangement is kept in a tree in the ''game world'' class


This is how I currently do things, but I''m considering breaking this into two seperate graphs. The hierarchy and spatial arrangement are actually two seperate concepts, although they are often related (ie, objects in the same branch of a hierarchy will often be close together). The problem is that logically most meshes will be placed as children of the root node in the hierarchy, which doesnt make for very efficient culling etc. You can start inserting spatial structures into the same tree, but then you''re polluting the logic of the hierarchy. I think it would be much better to have two seperate graphs. You can then make your spatial structure adaptive, without fear of breaking logical connections in the hierarchy (eg, Yann L''s ABT, or John Ratcliff''s Sphere Trees).

I''ve played around with render-graphs before, but I was never very satisfied with it. A better option might be to use a simpler sorted list for state-sorting. Geometry chunks can be inserted straight into the correct place in the list. You dont need to completely sort the list every frame, although it wouldnt be very expensive.

Share this post


Link to post
Share on other sites

The problem is that logically most meshes will be placed as children of the root node in the hierarchy, which doesnt make for very efficient culling etc. You can start inserting spatial structures into the same tree, but then you''re polluting the logic of the hierarchy.

I was thinking of doing it in two levels, sort of. First to divide the game world into quadtree-based system of cubes of fixed size. Once i get to the smallest level of ~1km, this smallest node becomes a root node for the objects populating this particular tile, with its own hierarchy etc. Obviously this would not work well for the dynamic objects, but most of the geometry is going to be static and there''d be separate tracking of the dynamic objects.

I''ve played around with render-graphs before, but I was never very satisfied with it. A better option might be to use a simpler sorted list for state-sorting. Geometry chunks can be inserted straight into the correct place in the list. You dont need to completely sort the list every frame, although it wouldnt be very expensive.

Hmm...am not sure if the simpler way would really work for me for this particular project, given rather the object texturing can get rather complicated. But thanks, i''ll think of it

just found this, btw: http://www.seas.gwu.edu/~graphics/RenderGraph.pdf at a glance seems like interesting read...

Share this post


Link to post
Share on other sites
quote:
Original post by tolaris
the scene information is divided into two parts: the info on ''logical'' objects, their hierarchy and spatial arrangement is kept in a tree in the ''game world'' class.



Doing this too.
It''s a good thing to keep spatial partitionning structure and scenegraph separate, thus you can keep your pipeline (SceneGraph), and use whatever space partitionning system you like, add a new...

It keeps things simple, makes maintenance and debugging easier.


-* So many things to do, so little time to spend. *-

Share this post


Link to post
Share on other sites