Hi Shayne Under Win XP we've compiled and used gdal 1.7.2 as well as used gdal_fw 1.7.0b2 (from FWTools) with the same result.
I have however looked at the code again and I think the problem is in the way the intersections are being generated within vpb::SourceData::readImage(...). The added check improves the test to find the intersection, but it can possibly be improved further. I'm still not sure why the original code works on some platforms and not on others. It could, as we've discussed, be a floating point inaccuracy in gdal or vpb (or some other issue) that affects the inputs to the two pass intersection code. I'll investigate it a bit further. Regards, Bernardt >>> "Tueller,Shayne R Civ USAF AFMC 519 SMXS/MXDEC" 07/14/10 4:39 PM >>> JP, Thanks for the info. So I guess we can conclude that this is an esoteric problem.?.? Have you tried VPB 0.9.10 with different versions of GDAL? I may try that and see what happens (I'm using GDAL 1.7.2). I know it fails on both Linux 64 bit and 32 bit i386 (Fedora 10). I haven't tried it with Windows but it sounds like you have. I'm glad you guys came up with a fix...:) -Shayne -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of J.P. Delport Sent: Wednesday, July 14, 2010 12:40 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Fwd: Re: floating point exeption in VPB... 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" 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 > > Reply-To: OpenSceneGraph Users > To: OpenSceneGraph Users > > 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 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 > , > 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 -- 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 -- 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
