Hi Shayne,
On 13/07/10 23:34, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote:
Just a follow up email...the fix that Bernardt proposed in SourceData.cpp of
the VPB code, seems to have fixed the problem. I don't have any issues
building my database with VPB 0.9.10 now. This seems like a pretty blatant
problem so I'm somewhat surprised that this problem hasn't come on the radar
screen of the OSG community in general...
Bernardt & I have speculated that it might be some floating point
representation issue with various gdal libs or maybe the intersection
code. We've built many databases using the same dataset on a Linux
cluster, with a range of vpb versions, and have never encountered this
problem. In the last week Bernardt tried to build on a Windows machine
to enable a client to build some terrains for themselves and encountered
this problem.
rgds
jp
-Shayne
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Tueller,Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Sent: Tuesday, July 13, 2010 10:01 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Fwd: Re: floating point exeption in VPB...
Bernardt,
Thanks much for that input. I definitely ruled out that my problem was due
to the 64-bit architecture because I was able to reproduce it on 32-bit
Linux using VPB 0.9.10. Using the same tif file, I did not see this problem
using VPB 0.9.7.
I will try your fix to see if that works for my situation. I will report the
results.
Your contribution is most appreciated...
Regards,
-Shayne
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Bernardt
Duvenhage
Sent: Tuesday, July 13, 2010 7:07 AM
To: [email protected]
Subject: Re: [osg-users] Fwd: Re: floating point exeption in VPB...
Hi Shayne
I'm experiencing a similar problem. The SourceData::readImage(...) method in
\src\vpb\SourceData.cpp gives a destWidth and readWidth of zero which
results in a tempImage of zero size (tempImage = new unsigned
char[readWidth*readHeight*pixelSpace]).
This is due to (I think) a failure of the two pass 360-degree shift test for
intersection of the destination and source bounding boxes. The intersection
is tested for 'valid()', but might still be of zero size. I adapted the 'if
(!intersect_bb.valid())' test as shown below and it seems to work now.
if ((!intersect_bb.valid()) || (intersect_bb.xMin()==intersect_bb.xMax()) )
{
log(osg::INFO,"Reading image but it does not intersect destination -
ignoring");
continue;
}
I'm building a simple terrain with BMNG data only. The destination bb is
therefore (-180,180]. The intersection test however generates a valid
intersection for the B1 tiff which is at (-270,-180] at some stage in the
two pass test. The generated intersection is valid, but of zero size and
hence the added condition in the above if.
I attach my SourceData.cpp as reference.
Regards,
Bernardt
"J.P. Delport"<[email protected]> 07/13/10 2:37 PM
=====================
Bernardt Duvenhage
Senior Researcher: Optronic Sensor Systems South African Council for
Scientific and Industrial Research (CSIR)
Tel: +27 12 841 2414
-------- Original Message --------
Subject: Re: [osg-users] floating point exeption in VPB...
Date: Mon, 12 Jul 2010 11:05:19 -0600
From: Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC
<[email protected]>
Reply-To: OpenSceneGraph Users<[email protected]>
To: OpenSceneGraph Users<[email protected]>
Robert,
After running osgdem in the debugger, it is crashing in gdalrasterband.cpp
where an integer divide by zero is happening. Tracing up further, it appears
that in the method SourceData::readImage(...) in SourceData.cpp, the
variable
"destWidth" is coming in as zero. Interestingly, the first pass through the
loop in that method yields a destWidth of 256. On the next time around, it
is
zero which is causing the crash in GDAL.
The ".tif" file is a file that I have used before with osgdem on another
machined with no problems so I know the image file is good.
I will try to dig further to get more on what's happening...
-Shayne
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Robert
Osfield
Sent: Saturday, July 10, 2010 3:30 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] floating point exeption in VPB...
Hi Shayne,
I develop under 64bit system and haven't encountered any floating point
exceptions issues with 64bit build of VPB.
Could you please run osgdem in a debugger and see what happens. Could you
also
update to svn/trunk for OSG and VPB to see if the problem persists.
Robert.
On Thu, Jul 8, 2010 at 11:01 PM, Tueller, Shayne R Civ USAF AFMC 519
SMXS/MXDEC<[email protected]> wrote:
All,
I'm using VPB 0.9.10 along with OSG 2.8.2 on a system that is using
64-bit Linux (Fadora core 10) i386. Both packages were built from source.
No matter what database I try to build, I get a floating point
exception when running osgdem. I know the DTED and imagery are good
since I've built VPB databases with this content on a windows 32-bit
system.
Here is a sample command that fails: osgdem -TERRAIN -geocentric
-PagedLOD -whole-globe -t wholeearthtexture.tif -l 10 -o output.ive
My question is, has anyone else seen problems with VPB in a similar
environment. Are there some 64-bit issues going on here? I'm at a loss
as
to
why I'm getting this floating point exception. If I use any other
content (i.e. dted or imagery), I get the same results.
Any help or input would be most appreciated.
-Shayne
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail
legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at
http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean. MailScanner thanks Transtec
Computers for their support.
--
This message is subject to the CSIR's copyright terms and conditions, e-mail
legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at
http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by
MailScanner
<http://www.mailscanner.info/> ,
and is believed to be clean. MailScanner thanks Transtec Computers
<http://www.transtec.co.uk/> for their support.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
