On Sun, Mar 2, 2008 at 11:41 AM, Benjamin Eikel <[EMAIL PROTECTED]> wrote: > > 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).
Even for you factory scene what approach to use will depend upon what you are viewing - its relatively small section then a distributed approach will be slower than a local rendering. You have to bare in mind the overheads and bottlenecks inherit with a distributed system, throwing lots of hardware at the problem won't help if you are introducing greater bottlenecks in the process of using the cluster. > > 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? You get the root RenderStage after cull traversal. osgViewer::Renderer has the SceneView that you can get the RenderStage from. The root RenderStage has everything you need. Might I recommend using osgViewer as your base and then just having a custom renderingTraversals method that you can override the cull and draw traversals if need be. "If need be" is the key part as you may well find using standard local rendering will often be better than a distributed implementation. > Okay right. We will only have one render bin which eases the thing a little > bit because we will not support transparent objects. Much of modern rendering is done with multiple pass techniques that go well beyond just the need for transparent bins. Don't forget there techniques like using of the occlussion query extension requires multipass, and its one technique that is well suited for complex CAD models. Paul Martz was even commission recently to add support for this in the OSG for the purpose of better handling CAD models. So, while limiting what types of rendering you can use to just standard opaque models might make your tasks easier, there is a real danger of excluding modern rendering techniques that help solve the performance problems in a better way. > > 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). If I was to tackle render graph distribution (I have been contemplating this approach for number of years) I'd sereailize the whole render graph and distribute this to the cluster. One would take care to cache objects like osg::StateSet's, osg::StateAttribute and osg::Drawables locally, and only update them any time they are updated. osgIntrospection could potentially be used for serialization. The slaves would then listen to render graph dispatch then cull the render graph down to just the required viewing volume then rendering, then dispatch back their portion of the colour and depth (if required) buffers. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
