The error I'm seeing looks like a flipping around the Y axis, rather than a small shift you report. I used the 4k imagery as Dmitry and you used.
After sending my last post yesterday it occured to me that perhaps its GDAL that is the problem, as your code looked fine, relying upon GDAL to get the data correctly. The fact that you aren't see the the Y axis flip perhaps could another hint that the problem is in GDAL, but has been fixed already.
What version of GDAL are you guys using?
This is my version:
gdalinfo --version
GDAL 1.3.1.0, released 2005/10/04
Robert.
On 9/17/06, Jason Beverage <[EMAIL PROTECTED]> wrote:
Robert,
I don't have time tonight to download and run the high res Puget Sound
data but I got the 4096 texture and 4096 heightfield to do a quick test.
I ran osgdem on the png's and I'm not seeing any flipping around the y
axis on that data set. I tried setting interpolateTerrain to false and
their is only a slight change in the position of the terrain, but
nothing I would call "flipping around the Y axis".
The alignment of the texture to the heightfield is a little off when
interpolateTerrain is set to true though, if that is what you all are
referring to. I can see where the whitest part of the texture should be
at the top of the peak on the right of the dataset, but with
interpolateTerrain on, it is slightly off. The reason for this is
because the changes I made only applies to terrain, not to imagery, so
the sampling method in readHeightField is different than in readImage.
If that is what the problem is, let me know and I'll see what I can do.
Jason
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of Jason Beverage
Sent: Sat 9/16/2006 11:24 PM
To: osg users
Subject: RE: [osg-users] osgTerrain DataSet bug?
Hi Dmitry and Robert,
I'll take a look and see what I can do. The issue is almost definitely
in the getInterpolatedValue method. Is this issue only showing up on
non-georeferenced files? If so, that will help me track it down.
Jason
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of Robert Osfield
Sent: Sat 9/16/2006 4:43 AM
To: osg users
Subject: Re: [osg-users] osgTerrain DataSet bug?
Hi Dmitry,
I have followed your instructions and also come across the flipping of
the
terrain in the Y axis. I have tried using the png's directly and this
also
has the problem so the problem isn't related to the data source, and
points
to a problem in DataSet.
Working with this dataset used to work, at least the 16kx16k datasets
did,
it was the very first dataset that I started testing osgTerrain on. It
now
handles much larger and more complex datasets, but should also still
work
with the simpler datasets like this. I have just conducted some other
data
tests to make sure that conventional (ones with gesopatial coords)
datasets
work fine and the results all look good.
Since 1.0 there has been the addition of some terrain interpolation code
to
improve on accuracy of reading terrain data, and disabling this
optimization
code does fix the problem. Change line 978 of DataSet.cpp to:
bool interpolateTerrain = false;
I've done a quick review of the code and can't spot any reason why there
should be a difference. Perhaps the author of this change, Jason
Beverage,
will be able to spot why this particular dataset doesn't work, while
others
work perfectly.
Robert.
On 9/16/06, Dmitry Platonov < [EMAIL PROTECTED]> wrote:
>
> I'm using OSG v. 1.2
> I'm following
> http://www.openscenegraph.org/index.php?page=UserGuides.Osgdem
> (exept gdaladdo -r average, which is not working for me).
> All is somewhat well (maybe, too slow database
> generation), but texture and mesh are misaligned (in fact,
> one of them is flipped around Y axis). Data files are OK.
> Is there bug in DataSet.cpp?
> Steps to reproduce:
> 1) Download
>
>
http://www-static.cc.gatech.edu/data_files/large_models/ps/ps_texture_1k
.png
> and
>
>
http://www-static.cc.gatech.edu/data_files/large_models/ps/ps_height_1k.
png
> Verify that files are matching.
> 2)
> $ gdal_translate ps_height_1k.png ps_height_1k.tif
> $ gdal_translate ps_texture_1k.png ps_texture_1k.tif
> 3)
> $ osgdem -t ps_texture_1k.tif -d ps_height_1k.tif -l 3 -v
> 0.001 -o puget.ive -a puget.osga
> 4)
> $ osgviewer puget.osga
> Playing with t & l keys, it's clearly visible that mapping
> does not follows mesh.
> ---
> Professional hosting for everyone - http://www.host.ru
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
