<div dir="ltr"><div><div><div><div><div><div><div>Hi Shayne,<br><br></div>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.<br><br></div>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.<br><br></div>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.<br><br></div>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.<br><br></div>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.<br><br></div>Doing this is non-trivial, but should be significantly less work than building a scheme for rendering purposes. <br><br></div>Robert.<br><div><div><div><div><div><div><div><br><br></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 August 2015 at 20:29, Shayne Tueller <span dir="ltr"><<a href="mailto:shayne.tueller@hill.af.mil" target="_blank">shayne.tueller@hill.af.mil</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Robert,<br>
<br>
I appreciate the detailed response and correction. My databases are always geocentric round earth built from source DTED or GeoTiff data.<br>
<br>
I guess my problems are two-fold which are performance and correlation.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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...<br>
<br>
If you could answer these questions or provide feedback on the correlation issue, that would be great.<br>
<br>
Thanks,<br>
<span class="">Shayne<br>
<br>
------------------<br>
Read this topic online here:<br>
</span><a href="http://forum.openscenegraph.org/viewtopic.php?p=64760#64760" rel="noreferrer" target="_blank">http://forum.openscenegraph.org/viewtopic.php?p=64760#64760</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
</div></div></blockquote></div><br></div>