[osg-users] _intersectionLimit doesn't seem to be working...

[Robert Osfield]

Hi Shayne,

On 19 August 2015 at 14:34, Shayne Tueller <shayne.tueller at hill.af.mil>
wrote:

> So, if I understand you correctly, there's no way to tell VPB to build a
> "flat" file (i.e. one that that does not have Paged LODs in it) in
> geocentric space? In other words, is there a way to decorate a sphere with
> just raw DTED data using VPB? I know this doesn't make sense for a visual
> database but it might make sense for other usages like viewing a raw DTED
> tile on a spheroid. If VPB won't do this, I suppose I can just use a height
> field and map it to a spheroid myself.
>

VPB doesn't have support for just generating a single level terrain
database at full resolution.  It's written with rendering at a solid 60hz
in mind, it's not written to support the the type of usage you are after.
The task you are after should be a lot more straight forward as big part of
VPB complexity comes down to the reprojection, resample and generation of
well balance quad tree for paging.



> My second question has to do with the LODs in VPB. What is the default LOD
> setting for VPB? You mentioned that I might not have gone deep enough in my
> database? It appears to me that VPB builds LODs by default and goes deep
> enough based on the resolution of the original source data. For example, I
> ran VPB on just one tile of level 1 DTED and didn't specify any levels of
> detail setting on the command line. It built the database to level 6. I
> then did another build and specified "--PagedLOD" and "-l 24" on the
> command line and it didn't do anything different. It still just built to
> level 6...
>

The -l setting is the maximum number of levels.  The VPB won't generate to
this level if the source data doesn't warrant it.  The levels each divide
the X and Y axis by two, doubling the effective resolution at each level,
and will keep dividing until the resolution of the output matches or
exceeds the source resolution.

Even if the resolution of the output tiles is higher than the source the
re-projection and alignment to a different grid will result in unavoidable
differences in the source and output data.  Normally these differences are
small enough to not cause problems for rendering databases.

If I were to tackle the creation of a scheme for paging in source DEM's I'd
come up with a hierarchy for mapping all the source data into a quad tree,
this quad tree would be held in memory and allow rapid intersection testing
to find out which DEM's are of interest for a particular intersection
test.  Once you have the DEM's then you'd cache the DEM's you are likely to
need, and supplement these as the intersection tests required new tiles.
If you can pre-empt what DEM's will be needed ahead of when you do the
actual intersection you'd be able to go fetch them with a background thread
and have them ready so the intersection test doesn't need to stall waiting
for a load.  Finally such a scheme would need to be load balanced so that
once you hit a maximum memory footprint you start expiring DEM's that
haven't recently been used.

Robert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150819/31361d5b/attachment-0002.htm>