Scenegraph + Rendergraph

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