Hi Robert,
I can't speak for the hardware on the windows machine, but the linux box
I tested with was a Quad core 2.6Ghz machine with 4GB memory and a
GeForce 8800 GTX 768MB with the latest Nvidia drivers(with Sync to
VBlank set). I'm pretty sure the hardware specs are not the problem, so
what's to best way to check for VBO issues? I've never had to down
sample any of the OSG databases before, so I was surprised when I tried
the --terrain option. I'm not sure I understand all the benefits of
--terrain over the default. The --terrain option doesn't do any
simplification of the terrain during build time, it just produces a
regular triangulated grid and expects you to use it or sample it in some
way at runtime, correct? But the default does do terrain
simplification, so you get longer build times but much less polygons at
runtime. Assuming I'm not way off base there, --terrain would only seem
to be recommended if you plan on doing some custom sampling or other
manipulation at runtime. I apologize if this has been addressed before,
but I haven't had much luck finding a clear explanation on the wiki or
mailing list archives.
To put my results in context, the database I'm testing with is a
whole earth model with SRTM and DTED(1&2) elevation, and 2 texture
layers consisting of Bluemarble NG, Landsat7, Quickbird and CADRG
imagery.
- Ken.
Hi Ken et. al,
On Thu, Aug 14, 2008 at 7:01 PM, Sewell, Kenneth R Civ USAF AFMC
AFRL/RYZW <[EMAIL PROTECTED]> wrote:
> We had similar issues with terrain recently. On windows it was single
digit
> framerates and the same database on Linux was 30 fps but %100 on 2
cores.
> Rebuilding our terrain without the -terrain flag solved the issue.
> Framerates on windows jumped up to 30 fps, Linux to 60 fps with %30 on
1
> core. We tried this with several databases and the ones without
-terrain
> always performed better.
Performance problems when using --terrain (i.e. an
osgTerrain::TerrainTile based database) suggests either problems with
VBO's or that your graphics hardware simply isn't up to the amount of
geometry being pushed to the graphics hardware. The osgTerrain based
databases deliberately use high resolution (64x64 by default) tiles,
and the default GeometryTechnique used doesn't do any simplification
in its default settings. What you get is very high fidelity databases
but... lots and lots of polygons.
The solution is very simple - as osgTerrain tessellates the
TerrainTile on loading its able to down sample the tiles to a user
defined level, so on hardware that is less capable you can use a lower
sample ration, and better hardware use a sample ration of 1.0. To
control this you simply decorate your paged database with an
osgTerrain::Terrain and set the SampleRatio here. The
osgmultitexturecontrol example provides code to do this, as well as an
event handle to vary the sample density.
The osgmultitexturecontrol example has an -r <sampleratio> command
line option so try:
osgmultitexturecontrol -r 0.25 mydatabase.ive
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
