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

[Robert Osfield]

Hi Shayne,

Using a paged database for LOS queries introduces the complication that if
you need the highest resolution tiles then you need to iteratively retrieve
them from lowest to highest res tile.  The osgSim::LineOfSight class has
this support built in, but it so slow when the tiles aren't yet loaded.
There really isn't any way around this.

The crux of the problem is that VPB generates paged databases for rendering
purposes, it's all geared towards getting a solid 60Hz.  Hierarchical paged
databases aren't ideal for serious intersection testing.  The OSG can
provide tools like LineOfSight that workaround some of the issues but it
can't resolve the fundamental problem that the hierarchy of LOD levels has
to be traversed to get to the highest res tile.

As for a discrepancy between the original height field and the VPB
generated database this can come about for a couple of reasons, first your
settings, if you don't build a deep enough database then the high res tiles
won't have a resolution high enough to map the original height fields,
secondly the source height fields are unlikely to align perfect to the
generated tiles (these are aligned according to a geocentric division not a
local projection.)  When you don't get perfect alignment sampling will lead
smoothing out of the data and a discrepency developing.  In flat areas this
discrepency should be small, but in rapidly changing heightfields the
potential for bigger discrepencies is higher.

Over-sampling the generated database would help minimize the
discrepancies.  However, you can't fully avoid discrepancies when the
source data and the generated data aren't in the same coordinate frame and
have exactly matching resolution.

If you need to do intersection tests against the source data then this is
probably what you should do.  So rather than the try to co-opt a paged
database fine tuned for rendering you consider building an parallel
database and intersection scheme just for doing your intersections. I.e. if
you have a square peg and it has to be a square peg then build a square
hole to start with rather than try and force it into a pre-pared round hole.

Doing this is non-trivial, but should be significantly less work than
building a scheme for rendering purposes.

Robert.



On 13 August 2015 at 20:29, Shayne Tueller <shayne.tueller at hill.af.mil>
wrote:

> Robert,
>
> I appreciate the detailed response and correction. My databases are always
> geocentric round earth built from source DTED or GeoTiff data.
>
> I guess my problems are two-fold which are performance and correlation.
>
> I was hoping that the general implementation in OSG would get me there on
> both counts but it is apparent that I will most likely need to roll my own
> stuff to get the performance and correlation to where I need it to be.
>
> I'm hoping to still use the some of the OSG infrastructure (e.g. the
> database pager) since I don't want to develop something from scratch
> entirely.
>
> At this point, correlation seems to be a much larger problem than
> performance at this point. I was hoping that when I query for terrain
> height at a given lat,lon, the OSG would page in the highest LOD which
> would match closely the height of the source data. Unfortunately this is
> NOT the case. In most instances, I see height deltas of 30-50 feet between
> what OSG returns and what the actual source data reports for height! I
> understand the interpolation schemes  between elevation data will introduce
> differences but I wouldn't expect that much.
>
> Do you know any way to resolve this problem? Is the highest LOD of an
> osgTerrain::TerrainTile that much different from the source elevation data
> for its elevation values? It would appear that it is which is a major
> problem. I suppose I could try and build a height field database from
> source data in VPB but I haven't been able to get that to work. Further,
> can a height field be built as a paged LOD database or is it just flat?
> How's the performance for a height field database? Not too good compared
> with an osgTerrain database would be my guess...
>
> If you could answer these questions or provide feedback on the correlation
> issue, that would be great.
>
> Thanks,
> Shayne
>
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=64760#64760
>
>
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150814/138bb63b/attachment-0003.htm>