HI Benjamin, Thanks for the more structured explanation. I'm not sure that the overall approach will be the most efficient way to tackle the task for a wide range of usages, so I'd recommend exploring the possibilities of different ways to implement that various usages rather than just sticking to one approach - different approaches are very likely to be suitable for different usages.
> o What is my question at all? > I am searching for a interface where I can grab these visible nodes and put > them into a list. I need them so I can analyse them to run the balancing > algorithm and send the data to the rendering nodes. I think that it might be > possible to use the DrawImplementation of the Drawable nodes. What it sounds like you are suggesting/looking for is a distributed render graph. The OSG's render graph is the rendering back end that the OSG produces from its cull traversal. The render graph containts osgUtil::RenderStage/Bin, a osgUtil::StateGraph and osgUtil::RenderLeaf. The RenderLeaf contain pointers to the projection and modelview matrices, the drawable and the point on the StateGraph that specifies the accumulated state that must applied for that drawable. Once the the OSG's cull traversal creates the render graph, the draw traversal then traverses this render graph in a controlled order that ensures that the scene builds up in the correct way - for instances opaque objects first, then depth sorted transparent objects. Now you could implement a system where rather than the local machine traversing the render graph to do the rendering, you could broadcast this rendering graph to the cluster and get them all render a portion of it, then to collate the result back of the frame buffer chunks. I don't think you should be doing things at as low level as trying to overriding the OpenGL functions that the OSG uses in its Drawables and StateAttributes. To go this low level you might as well use a distributed GL implementation and save yourself a lot of time. You mention transforms and drawables in your text, whereas you actually need all OpenGL state that the OSG manages as well, you really do need the whole render graph, yes it is more complex but its what is actually required to get things to render properly. There are also issues of performance - you want to be distributing as little data as possible, and doing a small a compute on the master as possible, this means differing the most work you can to the slaves, and minimizing the amount of the data that you have to distribute to the slaves and get back. Low level distributed GL loads the network and the master CPU massively, high level distributed application/IG has the lowest network and master CPU load, and since you system is only as fast as the slowest bottleneck then the high level system will always provide the greatest peformance. Your distributed render graph system is somewhere in the middle. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
