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

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.

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