[osg-users] Optimizer is awesome!

[Cory Riddell]

I'm getting to the point where I have to start tuning my app a bit and
so I added a call to Optimizer::optimize() today. Wow!

On a typical model, my app was able to push just under 40 fps at
1920x1200 (debug build). After running the optimizer, it's pushing
around 100 fps.

The trade off of course is that it takes 20 seconds to run through all
optimizations. That's a little long, but now I can start looking at the
individual optimizations and see what the cost and benefit of each is.

Cory
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Trajce (Nick) Nikolov]

you can save your model after optimization and load it optimized .... no need to wait 20 seconds then

-Nick

[Cory Riddell]

Our app is very CAD-like. The purpose of it is to create and edit models. Reloading models is a relatively rare activity.

Cory

[Cory Riddell]

I should add that our primary save format is .sat (ACIS), not .osg.

[Robert Osfield]

Hi Cory,

The Optimizer has a range of optimization traversals that deal with
various problems commonly exist in databases, in an ideal scene graph
the optimizer wouldn't do anything for you, so one should view it like
patch for a problem. Sometimes you can't fix the problem directly
because you database loaders just represent data in inefficient way in
which case you are stuck with having to use the Optimizer to fix
things.

However if you have control over the scene graph building you should
be able to avoid any need to invoke the Optimizer and build the scene
graph in a efficient way. A well designed scene graph will be more
efficient than an Optimizer optimized one as you'll be able make sure
everything is well balanced and best suits your data and your range of
hardware targets.

Robert.

[Cory Riddell]

On 7/30/2010 4:06 AM, Robert Osfield wrote:
> The Optimizer has a range of optimization traversals that deal with
> various problems commonly exist in databases, in an ideal scene graph
> the optimizer wouldn't do anything for you, so one should view it like
> patch for a problem.

It is definitely a patch for a problem. We aren't loading anything from
a database. Rather we are using a commercial geometric modeling kernel
to create and tesselate fairly complex bodies. OSG's Optimizer is
cleaning up the output from the tesselation library.

[Robert Osfield]

Hi Cory,

On Fri, Jul 30, 2010 at 3:02 PM, Cory Riddell <co...@codeware.com> wrote:
> It is definitely a patch for a problem. We aren't loading anything from
> a database. Rather we are using a commercial geometric modeling kernel
> to create and tesselate fairly complex bodies. OSG's Optimizer is
> cleaning up the output from the tesselation library.

I would recommend iterating through the various optimizer passes to
see how each of the different visitors affect the scene graphs you
have, it's likely only one or two are the key to the big differences
you see.

Once you've isolated which ones are the key ones you can look at how
the scene graph changes before and after to see what the optimizer has
to work with and what it generates. This will teach you a lot about
what is wrong with the scene graph you have to start with, and
hopefully point you in the direction of spotting more efficient ways
to process the data and to produce even more efficient scene graphs.

Doing your own targeted optimization will almost certainly be able to
produce better results than the Optimizer and to be able to do faster.

Robert.