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"<[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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
