Hello Robert, On Sunday 02 March 2008 at 11:42:24, Robert Osfield wrote: > 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. You have a point there. But we want to implement a very specialized system for only our kind of factory scenes. Of course our system will perform very bad with other kind of scenes (nature for example). > > > 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. Thank you for that insight. That was something I did not know and that was the part that was missing in my puzzle. This sound exactly like the thing I am searching. So if I want to get this RenderStage object I could get it from the SceneView after doing the update and cull traversal? > > 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. Okay right. We will only have one render bin which eases the thing a little bit because we will not support transparent objects. > > 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. Yes you are right. I did not know that this render graph does exist and only looked at the documentation and the code. But I did not get this insight that you gave me by your explanations above. So I assumend that overwriting the DrawImplementation for getting the information about the visible nodes would be a possible way. It might be possible, but as you said, not a good approach.
Yes you are right, in general we need the whole state, but as we do not want to implement texturing I hope the state does not change that often and it might be possible to use the same state for the whole scene (except for the model-view matrix and vertex data of course). > > 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. Yes that is clear. We have to see how the system performs with that single central node which has to do the culling etc. Thank you very much for your time and help. Regards, Benjamin > > Robert. > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
