[osg-users] Optimizing scene structure and geometry
jean-sebastien.guay at cm-labs.com
Fri Jan 21 13:13:03 PST 2011
I thought I had a pretty firm grasp on what to optimize given a certain
set of scene stats, but I've optimized what I can and I'm still getting
little improvement in results. So I'll explain my situation here and
hope you guys have some good suggestions. Sorry if this is a long
message, but I prefer to give all the relevant data now rather than get
The whole scene is about a 200m x 200m square (apart from the ocean and
skydome but these are not significant, I have removed them and confirmed
that the situation is the same). The worst case viewpoint is a flying
view where the whole scene could be visible at once. So I need to
balance culling cost with draw cost, since in some views we will see
only part of the scene (so we should be able to cull away at least part
of what's not visible) and in the flying view everything is visible so
we shouldn't waste too much time doing cull tests which we know will not
The other thing is that there are a lot of dynamic objects, so there are
a lot of transforms. But I can't change this, it's part of our simulation.
So, after doing some optimization (removing redundant groups, building
texture atlases where possible, merging geodes and geometry, generating
triangle strips, most of which I did with the osgUtil::Optimizer), I get
the following stats, which I'll talk about a bit later:
State graphs 1282
Tri. Strips 211091
Tri. Fans 16
Quad Strips 534
Total primitives 226705
And, both in our simulator and in osgViewer, for the same scene and same
viewpoint, I get:
This is on a pretty good machine: Core i7 920, GeForce GTX 260.
First of all, the stats above tell me that the "Primitives" part of the
scene stats refers to primitive sets, not just primitives... Since the
camera stats tell me there are over 226000 primitives in the current view.
As you can see, the number of primitiveSets is very high. If I
understand correctly, each PrimitiveSet will result in an OpenGL draw
call, and since my draw time is what's high now, I would want to reduce
that (since I'm currently at about 3 primitives per primitiveSet on
average). If I remove triangle strip generation from the optimizer
options, the stats become:
State graphs 1254
Tri. Strips 191
Tri. Fans 7212
Quad Strips 534
Total primitives 131523
This indicates to me that the tristrip visitor in the optimizer does a
pretty bad job. I looked at an .osg dump, and it seems to generate a
separate strip for each quad (so one strip for 4 vertices) which is
ridiculous... But that's a subject for another day.
When I disabled the tristripper, you can see a massive decrease in the
number of primitiveSets (and even in the number of primitives), however
there was no significant change in the frame rate and timings. I don't
understand this. I would have expected, with more primitives per
primitiveSet (I'm now at about 26 prims per primSet on average, as
opposed to around 3 before) and much less draw calls, that the draw time
would have been much lower. That's not what happens in practice.
My previous attempts at optimizing (using the osgUtil::Optimizer) were
also centered around lowering the number of primitives (by creating
texture atlases and sharing state so the merging of geodes and geometry
objects gave good results). And even though that also lowered the
numbers (I started at around 2215 Geodes and 2521 Geometry objects in
the same scene, compare that to 992 each now), it also had underwhelming
results in practice.
Clearly there are more than one primitiveSet per Geometry in the above
stats. What I see in the dumped .osg file, is there is often things like:
DrawArrays TRIANGLES 0 12
DrawArrays QUADS 12 152
DrawArrays TRIANGLES 164 12
DrawArrays QUADS 176 152
I would expect, by reordering the vertex/color/normal/texCoord data, I
would be able to get only 2 primitiveSets there, one TRIANGLES and one
QUADS. Am I wrong? Why does the osgUtil::Optimizer not do this already
when merging Geometry objects? I expect because it's easier not to do
it, but still, it gives sub-optimal results...
Of course I can't do that for strips or fans, unless I insert new
vertices to restart the strip. Again this is something that could be
done, but might bring diminishing returns in my case given that my own
scene contains many more triangles and quads than strips and fans (when
I turn off tristripping).
So, first of all, am I on the right track trying to reduce the number of
primitiveSets? Do you think on current hardware, disabling tristripping
is a good idea?
Why, when disabling tristripping which reduced the number of
primitiveSets from 73953 to 4899, didn't I see an increase in performance?
Is there some other way to find out what's going on and seeing what I
can improve to increase the performance? I've tried running our app in
gDEBugger, which tipped me off that I was batching poorly when using
triangle strips (about 3 prims per primitiveSet as I said above).
Turning off triangle strips improved the situation (as gDEBugger sees
it), but not by that much, which is probably coherent with what I'm
seeing in practice, but I'm no closer to finding out what to improve
next. What is not mergeable now is like that because of different
settings in StateSets (backface culling on vs off, can't use texture
atlas because the wrap mode is set to REPEAT, etc.), so I don't think
osgUtil::Optimizer can help me improve the situation further...
I have looked at video memory usage by the way, and I'm fine in that
respect, so I don't think I'm getting any thrashing or paging between
video RAM and main RAM at runtime. Also, I'm using display lists for
most of the objects in the scene, I tried using Vertex Buffer Objects
and it actually slowed it down.
I should also mention that these results are obtained using
osgShadow::LightSpacePerspectiveShadowMap. I can run the dumped .osg
osgshadow --lispsm --noUpdate --mapres 2048 <dumped_file>.osg
and I get the results above, which are pretty similar to our simulator.
If I run the same data file in plain osgViewer without shadows, it runs
at a solid 60Hz, with stats and timings:
State graphs 321
Tri. Strips 85
Tri. Fans 2508
Quad Strips 178
Total primitives 49384
(that's the no tristrips version, so compare these stats to the second
set of stats from the top, not the first)
I would have expected most numbers there to be half what they were with
shadows enabled, but as you can see they're consistently less than half,
so shadows added more than a 100% overhead... Note that even if it added
exactly 100% overhead, I would still be at 16ms draw, which is too much,
but I'm just mentioning it in case it may prompt some other suggestions.
I'm not sure I could send my whole scene to everyone on the list, but I
might be able to send it to someone if they want to see firsthand. Just
the bare .osg file without any textures and without ocean and skydome
shows the problem adequately well.
Thanks in advance for any suggestions you might have. I really need to
improve this, and I've been working for a while already with only a
small improvement to show for my time...
Jean-Sebastien Guay jean-sebastien.guay at cm-labs.com
More information about the osg-users