Hello Robert, thank you again for your helpful advice. I will meet with our team tomorrow and talk with them and decide what approach we will implement in the end.
Regards, Benjamin On Sunday 02 March 2008 at 14:58:41, Robert Osfield wrote: > 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 > [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
