Hi Can, Your bottleneck is almost certainly CPU, in both your model cases. Using display lists is important. As for faces, if you are concerned about fill then enable OpenGL back face culling, and don't both with any scene graph representations of it.
Please use the StatsHandler to profile what the update, event, cull, draw dispatch and draw GPU time are. This will tell you a huge amount about where the bottlnecks are. When doing optimization work always examine the costs of the different phases of the frame (update,event,cull, draw dispatch, draw GPU), and then look to address the largest of these first. In your case the use of many thousands of PostionAttitudeTransforms is likely to make the cull traversal slow, the draw dispatch traversal will also be relatively high. You want to avoid all these transforms. You could just build all the data in a single osg::Geometry, which would almost entirely elliminate the CPU costs for cull and draw dispatch. Modern graphics cards can deal with lots of geometry and fill so you'll be surprised how much performance you'd get once you remove the bottlenecks. Robert. On Thu, Oct 23, 2008 at 8:56 AM, Can T. Oguz <[EMAIL PROTECTED]> wrote: > Hi Robert, > > I've attached a model description and a screen capture to make it clear. > What I understand is that : > > Model 1, with high number of faces (some unnecessary) > Model 2, with low number of faces (only visible) > > Model 1 is much more efficient (almost doubles the frame count) And the > reason is Model 2 brings more CPU time because of lacking gl display lists? > If I get it right, what I need to do is minimize the number of Geometry > nodes. Right? > > In addition to this, I've observed that the frame rate loss happens with far > camera positions (as expected) So I tried to use overlay nodes but couldn't > get much use of that. So I've decided to create a hand made texture during > object regeneration and use it in the far LOD node. > > Thank you very much for your guidance, > > Can > > 2008/10/22 Robert Osfield <[EMAIL PROTECTED]> >> >> HI Can, >> >> The bottleneck is very unlikely to be fill rate so optimizing of faces >> won't be an advantage, and if you increase the CPU, bandwidth or >> vertex processing overhead with this change you will see a net loss. >> >> As for optimizing, the best way would be create the boxes yourself and >> place them into a set of osg::Geometry where each Geometry contains a >> say a 5 by 5 cube of your boxes, then position these (or perhaps even >> this) geometry around your scene using transforms. >> >> Robert. >> >> On Wed, Oct 22, 2008 at 4:00 PM, Can T. Oguz <[EMAIL PROTECTED]> wrote: >> > Hi, >> > >> > I have a seen with about 10,000~100,000 textured boxes. They were mostly >> > aligned on top of each other so instead of using osg::Box, I've prepared >> > the >> > equivalent with only visible faces (textured quads) But I've got lower >> > frame >> > rates with this "optimized" scene. So I want to ask what kind of >> > optimizatin >> > does OSG run (except display lists)? >> > >> > Thanks for reading, >> > >> > Can >> > _______________________________________________ >> > 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 > > > _______________________________________________ > 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
