Hi Robert, It's an old submission !
On Wed, Mar 25, 2009 at 1:13 PM, Robert Osfield <[email protected]>wrote: > Hi Christope, > > I've doing a clean out of old submissions, and this one from back in July > last year I have done reviewed and tested against the model you suggested > and found that it didn't fix things completely - I still saw artefacts. ] > > I tried build the database using --terrain to select a > osgTerrain::TerrainTile based database and this cures the artefact. > --terrain will soon be the default, so I wonder if about whether this issue > is still critical or not. > We now use --terrain for generating our databases and as you see, this artefact disappeared with this option. So it isn't a critical issue. Regards. > > Cheers, > Robert. > > On Fri, Jul 18, 2008 at 12:42 PM, christophe loustaunau < > [email protected]> wrote: > >> Hi, >> >> I have found a little problem with some normals in VPB. >> If you generate a terrain with two dem files : global.tif , local.tif >> -->local.tif have a better resolution than global.tif. >> -->local.tif is part of global.tif >> In other words imagine global.tif representing the USA and local.tif New >> York. >> >> If you generate the terrain with this command line : >> vpbmaster -d global.tif -d local.tif --geocentric -o terrain.ive >> >> You can see in the generated terrain that some normals are wrong, see >> screen.png. >> >> I have searched the code for this bug, and I have found that in both >> functions >> equalizeCorner() and createPolygonal() (in destination.cpp) there is a >> problem if there are two corners that have different resolutions. >> The vec2 heightDelta computed in equalizeCorner() is the average of the >> of all the corners's heightDelta. When dealing with 4 tiles, if three >> corners have the same resolution, they may have all a heightDelta that is >> nearly the same, but the fourth corner with a different resolution has a >> really different heightDelta (generally smaller as it's more precise). These >> heightDelta are then used in createPolygonal() to compute the normals. The >> small heightDelta* *results in a bad calculation of the normal. >> >> I have found a solution but I'm not sure if it's the best one...In fact, I >> checked in equalizeCorner() if the corners have different resolutions, if >> it's the case, I change the normals only for those who have the lowest >> resolution. >> >> Anyways, here is a patch based on the svn version. Tell me what you think >> of it and let me know if you find a better solution. >> >> I have joined to the mail global.tif and local.tif if you want to >> reproduce the problem (the two images are very little, so it's very quick to >> generate the database). >> >> Regards. >> -- >> Christophe Loustaunau. >> >> _______________________________________________ >> osg-submissions mailing list >> [email protected] >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> >> > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > -- Christophe Loustaunau.
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
