[osg-users] unrendered objects creating performance problems?
robert.osfield at gmail.com
Wed Sep 10 12:04:54 PDT 2008
If you build your VPB terrain using --terrain it'll produce terrain
which a high degree of geometry, but you can dynamically control how
much geometry is rendered by setting the
osgTerrain::Terrain::setSampleRatio(float). You can also control the
LOD scale via viewer.getCamera()->setLODScale(float). See the
osgmultitexturecontrol example for illustration of this in action.
The LODScale is a value you can vary per frame, so if you want to
change it in response to load you can. The SampleRatio is something
that'll be used on building of terrain geometry, and changing this on
the fly would force a rebuild of the geometry so isn't something you
want to vary per frame. I'd suggest altering the SampleRatio fit
different hardware, then use LODScale on the fly.
On Wed, Sep 10, 2008 at 7:52 PM, Joseanibal Colon Ramos
<jcolon at email.arc.nasa.gov> wrote:
> Thanks for the culling mode tip Robert. My terrain was generated using
> VirtualPlanet builder, but I didn't do it, so I'll get back to you when I
> get more details on that. I'm running my application on 2 machines getting
> similar results: a 64-bit-Linux-86 with a double headed Nvidia Quadro
> 3450. The other is an intel MacBook Pro with a GForce 8600. The available
> RAM for both is way over 1GB. I am trying OSG 2.6.0. It usually runs
> smoothly at 60fps, but on this particular terrain, when zoomed in, and at
> angles on which I look far into the distance, the framerate drops to below
> 20, which is unacceptable for my application. I believe I end up drawing
> way too many triangles for the computer to handle efficiently. I am trying
> to find ways to run at a solid 60fps no matter what.
> On Wed, September 10, 2008 12:56 am, Robert Osfield wrote:
>> Hi Joseanibal,
>> By default the OSG does not cull on the near/far planes, and near/far
>> clipping is done down on the GPU only affect the fill rate performance
>> of your application. You can enable culling on the near/far planes,
>> but you have to be careful about setting your near/far planes so that
>> encompass your scene - as the OSG by default computes the near/far
>> planes it'll hide the inappropriately set near/far planes so by
>> toggling these features on you might suddenly find parts of foreground
>> or distance disappearing.
>> To switch off the compute of near far use the Camera methods
>> (inherited from osg::CullSettings) :
>> To enable the culling against the far plane use methods inherited from
>> osg::CullSettings again:
>> int cullingMode = viewer.getCamera()->getCullingMode() |
>> All of this doesn't really address the performance issue too much.
>> You don't mention the nature of your database at all i.e. how you
>> built it, what scene graph components it uses, or what hardware, or
>> OS, or OSG version you are using, all this info is essential for
>> others to know enough to really guide you in the right direction.
>> On Wed, Sep 10, 2008 at 1:08 AM, Joseanibal Colon Ramos
>> <jcolon at email.arc.nasa.gov> wrote:
>>> Hi all,
>>> I was hoping someone has an idea about why I am encountering the
>>> problem: I have a big terrain and on certain viewing angles it contains
>>> huge amount of triangles to draw and puts a big strain on OSG's
>>> performance. I tried playing around with near/far clipping planes to
>>> improve performance, by cutting out a lot of the rendering, to the point
>>> only a very small fraction (and even none at all) of the terrain is seen
>>> through my camera. OSG's framerate, however, behaves just as if I was
>>> looking at the whole thing and drawing all the triangles.
>>> At certain angles, the framerate increases (where small number of
>>> triangles would normally be - even thought I don't see anything),
>>> and at other angles, it decreases (the same angles at which the viewer
>>> normally tries to draw a large number of triangles - even though I can't
>>> see anything). What is going on here?!? help!
>>> osg-users mailing list
>>> osg-users at lists.openscenegraph.org
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
> osg-users mailing list
> osg-users at lists.openscenegraph.org
More information about the osg-users