Re: [osg-users] VirtualPlanetBuilder and pagedLOD chalenges my Targeting pod camera

2008-05-16 Thread Robert Osfield
Hi Ralf,

VPB couples terrain with imagery storing them in exactly the same .ive tiles.

Normarily one shouldn't have to tweak
--radius-to-max-visible-distance-ratio, performance should be good
without any tweaks, and should scale to terabyte databases.

I found it pretty hard parsing your email thanks to all the acronyms
so am not entirely clear on what your hardware set up.

It may be that Delta3D is part of the problem, try building the VPB
database and viewing using osgviewer to see if there is performance
delta.

Use of Windows for a visual simulator is not something I would
recommend, the file system performance sucks big time, memory
management and threading support is not great either.   Install a
modern Linux and you'll probably find many of your issues gone.

I'd also recommend an upgrade to OSG-2.4 as the DatabasePager has been
improved w.r.t load balancing, keeping memory consumption much more
even.   OSG-2.4 also offers improvement to osgTerrain, such that one
can now control the sample density of elevation data via the
osgTerrain::Terrain class, to generate such databases you'll need to
build using SVN version of VPB and use the --terrain option.

Robert.

On Fri, May 16, 2008 at 8:44 AM, Ralf Stokholm [EMAIL PROTECTED] wrote:
 Hi

 Im working on a flight simulator project and have been using VTP to generate
 a terrain for visualisation, The input data is 30m landsat orthofoto and 90
 m nasa elevation data. In addition there are som higher resolution orthofoto
 for specifik target areaes dovn to 25 cm resolution.

 My application has a Targeting POD displaying in the cockpit in adition to
 the standart otw view, the problem is that I have a hard time getting it to
 run smothly. To keep good quality in the TGP view I had to increase the
 --radius-to-max-visible-distance-ratio from default 7 to 25 in order to get
 the orthophoto to load early enough in my zoomed targeting pod view. I I
 generate the terrain without height date it almost runs smooth at that
 setting, but with elevation data it studders all the time. Especially when
 turning my head.

 Im using the delta 3d engine and the allocate 4ms for paging opperations
 each frame.

 This is tested on a brand new system Core2 duo 3.0 Ghz 4 Gb RAM and a
 geforce 9800 GTX, it has a raid0 hard drive etc so I cant emagine this it
 the limiting factor. Oh its running windowsXP sry :(

 OSG is verison 2.2.0 and VTP is version 0.9.1

 The aplication is rendered on 2 displays a 1920x1200 display for the cockpit
 TGP view is roughly 512x512 ans a 1920x1080 display for external view.

 The following is the command line used for generating the terrain archive.

 osgdem -d height -t texture -l 20 --radius-to-max-visible-distance-ratio 25
 -v 1.1 --cs +proj=laea +lat_0=55.5 +lon_0=9.5 +x_0=0 +y_0=0 +datum=WGS84
 +units=m +no_defs -o denmark.ive -a denmark.osga

 Is there any way of making the terrain load later in the OTW view? Or any
 other hints on what parameters to play around with to improve the performace
 of this?


 Brgs

 Ralf Stokholm

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


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


Re: [osg-users] VirtualPlanetBuilder and pagedLOD chalenges my Targeting pod camera

2008-05-16 Thread Robert Osfield
Hi Ralf,

On Fri, May 16, 2008 at 10:06 AM, Ralf Stokholm [EMAIL PROTECTED] wrote:
 It sounds like I should defenatly try running it on a linux box, it will be
 quite a challenge though, havent spend much time with linux :(

These days Linux is pretty slick as a development platform.  It takes
me just half another to install Linux, and all the development tools
and sources required to build the OSG, this is from a blank disk to a
work dev environment.  Immediately I just use nedit as an editor,
cmake/gmake for build, and gdb for occasional debug session so I have
no IDE to install, but there are IDE's available, and it'll just be
another item to click to install on modern installers.

If you aren't familiar with Linux then it'll take you while to get up
to speed, but once you are I'd expect you'd find it pretty productive.
 For a vis-sim runtime it's certainly one of the best platforms
available.   With cross platform tools like Delta3D and OSG you can
even dev on one platform and reploy on another.

 The reason I have to tweak the --radius-to-max-visible-distance-ratio
 variable is that one of my cameras are rendering for a Targeting Pod (One of
 those aiming devices for laser guided bombs that you see on Discovery) This
 camera has the ability to zoom in on the target arear vith i.e. a 1.5 degree
 field of view, this results in visual artifacts ( texture popping) because a
 given lod is simply visible from farther away.

What you you use is LODScale instead, this way you can adjust things
according the display you use without needing to tweak the database.

viewer.getCamera()-setLODScale(scale); // 1.0 is default

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] VirtualPlanetBuilder and pagedLOD chalenges my Targeting pod camera

2008-05-16 Thread Ralf Stokholm
Hi Robert

Thx a lot for the swift answer. and sry for the acronyms.

Im working on testing it on osg 2.4 and the SVN version of VTP. Will know
more in a few days ( I hope)

It sounds like I should defenatly try running it on a linux box, it will be
quite a challenge though, havent spend much time with linux :(

The reason I have to tweak the *--radius-to-max-visible-distance-ratio
*variable
is that one of my cameras are rendering for a Targeting Pod (One of those
aiming devices for laser guided bombs that you see on Discovery) This camera
has the ability to zoom in on the target arear vith i.e. a 1.5 degree field
of view, this results in visual artifacts ( texture popping) because a given
lod is simply visible from farther away.

If i increase the *--radius-to-max-visible-distance-ratio *my normal out the
vindow view, which is rendered on a second screen using the same data will
load the same lods roughly 3 times too early. This camera uses a more normal
60 degree field of view, and wont have to load the lods at the same time.

I have testet the database in osgViewer and it seams to run smoother, but if
i set up the view to rotate cose to ground so the data rendered at any given
time will change fast i still get studders/framedrops.

Brgs. Ralf
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org