Re: [osg-users] osgQt versioning problem
Hi Jan, > The only way you could have problems is if you rely on the OSG > libraries shipped by the distro, where you don't have control over how > it was compiled. That is precisely what's going to happen. My application is likely to become available in distro repositories (FWIW, an older version of my application that isn't using the OSG *is* already in distro repositories). Packaging guidelines typically require a package to use the established library stack. A package isn't likely to get accepted if it ships its own forks of already packaged software. That would be a maintenance and security nightmare. > > I don't think that is necessary - you need to ensure in your > application that it is built against the correct version of Qt which > is the *same as the version you use for osgQt*. > Sounds easy in principle, but will cause a waterfall of problems for package repositories. - Not all application developers are willing or able to upgrade to Qt5 yet. - *if* there is a mismatch, we just get a crash, instead of the mismatch being detected at the build system stage. The packager or tester is left to dig into the crash to find out what's wrong. There is no way for the application to detect what version of Qt the osgQt was built with, so the application can't provide a sensible error message either. Ultimately, the developer will be left to deal with lots of support requests by frustrated users. - If one package requires osgQt5, but a different one requires osgQt4, we get a conflict. The user wouldn't be able to install those two packages at the same time. Yes, these aren't problems if you ship your application with static libs, but not everyone can or wants to ship software in this way. > In addition, if you are trying to distribute a binary-only package I don't. I just distribute source-code and let others worry about the rest ;) My suggestion is: - Provide separate libosgQt4/5 libraries. - Provide a libosgQt library that points to the default, either 4 or 5, for backwards compatibility. - Add an OSGQT_DESIRED_QT_VERSION switch for the FindosgQt.cmake script, allowing applications to opt for a specific version. For now, I'm going with the workaround of upgrading my application to Qt5. Still, I'm convinced there's a bigger issue here. I'd be curious what Robert's thoughts are. Thanks, Jannik[/quote] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64064#64064 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt versioning problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/11/2015 10:19 PM, Jannik Heller wrote: > Hi, > > Recently I have had my application tested on a wide range of linux > distributions. Some users are running into a problem with Qt > version mismatch. My application gets built with Qt4, but osgQt > might be built with Qt4 or Qt5. If you load Qt4 and Qt5 libraries > in the same executable, a crash ensues. This means you have built your application incorrectly. It is normally not possible to start an application built with Qt4 using Qt5 libraries and vice versa - the APIs and ABIs are not compatible, the library version numbers are different and the application will not start . > > This forces users to rebuild the OSG with a particular version of > Qt, just to run a certain application, which is bad. It is unfortunately inevitable, because Qt4 and Qt5 are not compatible. There were huge API changes, some libraries were removed and many more added between Qt4 and 5. > > For a proper solution, the OSG could provide libosgQt4 and > libosgQt5 libraries, along with find scripts that allow the > application to request a particular osgQt version to be used. What > do you think about the idea? > I don't think that is necessary - you need to ensure in your application that it is built against the correct version of Qt which is the *same as the version you use for osgQt*. Then you ship both OSG libraries and your application. The CMake scripts for Qt and OSG allow specifying the Qt version already. And most Linux distributions ship both the older Qt4 and the new Qt5 series, so if you build for one of them, it should work. The only way you could have problems is if you rely on the OSG libraries shipped by the distro, where you don't have control over how it was compiled. However, that is a terrible idea, because that OSG tends to be outdated and many distributions don't ship OSG at all. In addition, if you are trying to distribute a binary-only package, you are going to have major problems with library version and C++ ABI incompatibilities between distributions. Qt will be the least of your problems. You should always ship your shared libraries with the application or recompile/package the software for the particular distribution. J. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFVefgYn11XseNj94gRAjQ+AKCk66wnwYe6LPfM35sJCxMsCwNCyACfcjCU BQs5Q4TgtHM5+vB8zQdI054= =hWe4 -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgQt versioning problem
Hi, Recently I have had my application tested on a wide range of linux distributions. Some users are running into a problem with Qt version mismatch. My application gets built with Qt4, but osgQt might be built with Qt4 or Qt5. If you load Qt4 and Qt5 libraries in the same executable, a crash ensues. This forces users to rebuild the OSG with a particular version of Qt, just to run a certain application, which is bad. For a proper solution, the OSG could provide libosgQt4 and libosgQt5 libraries, along with find scripts that allow the application to request a particular osgQt version to be used. What do you think about the idea? Thank you! Cheers, Jannik -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64062#64062 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQt integration required
On Thu, Jun 11, 2015 at 4:43 PM, manish Choudhary wrote: > Hi, > > I'm using Qt 5.4.2 for Windows 32-bit (VS 2013) and OpenSceneGraph-3.2.2 > stable release on Window 8.1 platform. > osgviewerQt example is not working without any modification. > It is aborts and in the command prompt it showing > "Warning: detected OpenGL error 'invalid operation' at Before > Renderer::compile > Error: In Texture::Extensions::setupGLExtensions(..) OpenGL version test > failed, requires valid graphics context. " > ... > > Why osgviewerQt example not working that seem strange to me.? Those errors are Qt/OpenGL problems, not OSG issues. Did you install the Qt version using the Angle emulation, by chance? I believe that is the default download. Angle supports only OpenGL ES 2.x and translates that to Direct3D calls, so any code requiring "true" OpenGL will not work with that. The Angle backend is mainly there to accelerate the Qt scenegraph and is not really a full OpenGL implementation. Make sure to download the version of Qt with the native OpenGL support The versions with "OpenGL" in the name are the correct ones: http://www.qt.io/download-open-source/#section-2 If that is OK, then make sure you have the vendor OpenGL drivers for your graphic card installed (from AMD or Nvidia) - Windows used to ship with an ancient version of OpenGL, that will not work with OSG. Regards, J. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQt integration required
HI Manish, I could be a Qt change in behavior that it's setting the context up or managing the threads in an different way. Qt's this moving goal posts with trying to integrate. Each rev it the way Qt works w.r.t OpenGL shifts a bit. One thing you could try is OSG-svn/trunk or the OSG-3.3.7 dev release. There is chance that revisions to osgQt help keep track of the later versions of Qt better. However, I'm not personally a Qt expert. I have to defer to others to provide expertise. Robert. On 11 June 2015 at 15:43, manish Choudhary wrote: > Hi, > > I'm using Qt 5.4.2 for Windows 32-bit (VS 2013) and OpenSceneGraph-3.2.2 > stable release on Window 8.1 platform. > osgviewerQt example is not working without any modification. > It is aborts and in the command prompt it showing > "Warning: detected OpenGL error 'invalid operation' at Before > Renderer::compile > Error: In Texture::Extensions::setupGLExtensions(..) OpenGL version test > failed, requires valid graphics context. " > > Earlier in my application I have used osg 2.8 in Qt(4.8 VS 2008 - Window 8 ) > using "class ViewerQT : public osgViewer::Viewer, public AdapterWidget" to > integrate osg in QT. (attached file showing this integration) > > Now I want to switch to latest QT (5.4) and Osg (3.2) and but in this latest > version ealier(old) osg Qt intergration didn't work. So I look for > osgviewerQt example . But both showing same type of error. > > Why osgviewerQt example not working that seem strange to me.? > > > > > ... > > Thank you! > > Cheers, > manish > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=64056#64056 > > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQt integration required
Hi, I'm using Qt 5.4.2 for Windows 32-bit (VS 2013) and OpenSceneGraph-3.2.2 stable release on Window 8.1 platform. osgviewerQt example is not working without any modification. It is aborts and in the command prompt it showing "Warning: detected OpenGL error 'invalid operation' at Before Renderer::compile Error: In Texture::Extensions::setupGLExtensions(..) OpenGL version test failed, requires valid graphics context. " Earlier in my application I have used osg 2.8 in Qt(4.8 VS 2008 - Window 8 ) using "class ViewerQT : public osgViewer::Viewer, public AdapterWidget" to integrate osg in QT. (attached file showing this integration) Now I want to switch to latest QT (5.4) and Osg (3.2) and but in this latest version ealier(old) osg Qt intergration didn't work. So I look for osgviewerQt example . But both showing same type of error. Why osgviewerQt example not working that seem strange to me.? ... Thank you! Cheers, manish -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64056#64056 header.h Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Ready to tag OpenSceneGraph-3.3.8 dev release, please test
On 11 June 2015 at 12:25, Jordi Torres wrote: > Hi Robert, > > That's exactly what I was referring. Just tested and it works for me in a > fresh install of Ubuntu 15.04. Also compiled with success for Android ndk > r8e and ndk r10d in GLES1 and GLES2. > Should'nt these lines ( 34 and 36 ) be removed too? Yes, they should, I just removed the single line to get quick feedback on whether it broke the Android build or not. If everything looks OK I'll remove the #ifdef's. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQt integration required
Hi Manish, I'm not a Qt user so can't help with the specifics. Others with more Qt experience might well be a bit clueless to what's wrong at your end as you don't provide any code or many details. You won't get many answers if no one has enough information to know what might be wrong. For starts, does osgviewerQt work without any modifications? Which version of Qt are you using? What platform? Which version of the OSG? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQt integration required
Hi, Have not found the solution regarding above issue? Please Help. ... Thank you! Cheers, manish -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64052#64052 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Ready to tag OpenSceneGraph-3.3.8 dev release, please test
Hi Robert, That's exactly what I was referring. Just tested and it works for me in a fresh install of Ubuntu 15.04. Also compiled with success for Android ndk r8e and ndk r10d in GLES1 and GLES2. Should'nt these lines ( 34 and 36 ) be removed too? Rafa will try in OSX later. https://github.com/openscenegraph/osg/commit/9d737b86ad110f9fe9f42cd2e856f9809912941e Thanks. 2015-06-11 10:44 GMT+02:00 Robert Osfield : > Hi Rafa, > > I have reverted this problem typedef. > > Could you please test svn/trunk to make sure everything is looking good > now? > > Cheers, > Robert. > > On 9 June 2015 at 20:03, Rafa Gaitan wrote: > > Hi Robert, > > > > I've just did an svn update and the error in android is still there. > > > > If we remove the line 35 ( typedef GLfloat GLdouble; ) of GLDefines file > > then builds ok. And it does not affect to macosx build, and probably > won't > > affect to other desktop environments. > > > > I think this commit ( > > > http://trac.openscenegraph.org/projects/osg/changeset?new=14862%40OpenSceneGraph%2Ftrunk%2Finclude%2Fosg%2FGLDefines&old=14747%40OpenSceneGraph%2Ftrunk%2Finclude%2Fosg%2FGLDefines > ) > > was not correctly tested at that moment and probably should be reverted. > > > > Regards and thank you for your efforts! > > Rafa. > > > > El mar., 9 jun. 2015 a las 20:17, Robert Osfield > > () escribió: > >> > >> Hi All, > >> > >> I have checked a couple of bug and build fixes today, could you please > >> do an svn update and test again ;-) > >> > >> Robert. > >> ___ > >> osg-users mailing list > >> osg-users@lists.openscenegraph.org > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > ___ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Jordi Torres ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Correct way to get texture data from USGS or any other source?
Hy Elias, your procedure seems correct to me, it is more your conclusion that I don't understand... What do you mean by "vpb didn't make texture elevated" ? Ha you fully zoomed on the textured zone in order to be sure that it is really not elevated. When I see the size of your dem, I would say that the elevations look reduced, due to the very large size of represented zone and the fact that there are only small elevations (try to calculate the ratio of highest point of dem and the length or width of your terrain). As far as I know you can define the extend of generated terrain in osgdem (and vpb) with command line option : -e Extents of the model to generate The artefact is due to the fact that the whole current LOD containing your texture will be black (that's why when you get farer away you see more black texture) I think the result will be correct (or look correct to you, as I think that it is already correct :-) ) once you reduce the extend of your generated database. Regards, Christian Le 11/06/2015 10:52, Elias Tarasov a écrit : Hello! My statement about the problem, that had been solved, looks a little premature. The problem: Terrain is displayed incorrectly. Results: 1. https://drive.google.com/file/d/0ByDDImhSolf6cGFyV21PRXZuZHM/view?usp=sharing 2. https://drive.google.com/file/d/0ByDDImhSolf6N3FvRkNJUW1nMlk/view?usp=sharing Step-by-step actions to make a terrain 0. Gathering required data 0.1. Choose texture: https://drive.google.com/file/d/0ByDDImhSolf6S3E0M1VmR2xDd1U/view?usp=sharing 0.2. Choose dem: https://drive.google.com/file/d/0ByDDImhSolf6cDNtWjlUa3VqdXc/view?usp=sharing 0.3. Downloaded texture: https://drive.google.com/file/d/0ByDDImhSolf6eXRpYlhxMFN3NnM/view?usp=sharing 0.4. Downloaded dem: https://drive.google.com/file/d/0ByDDImhSolf6MXVLUV9kOG1xR2c/view?usp=sharing 1. Straightforward vpbmaster --geocentric -d dem/n30_w086_1arc_v3.tif -t texture/2.tif -o output/out.osgb answer: --geocentric -d dem/n30_w086_1arc_v3.tif ADD: dem/n30_w086_1arc_v3.tif -t texture/2.tif ADD: texture/2.tif -o output/out.osgb Adding terrainTile Error: vpbmaster can not run without all source data being in the correct destination coordinates system, please reproject them. Recieved signal 15, doing TERMINATE_RUNNING_TASKS_THEN_EXIT. Setting up MachinePool to use all 8 cores on this machine. MachinePool::signal(15) Machine::signal(15) Machine::cancelThreads() hostname=, threads=8 Cancel thread Cancel thread Cancel thread Cancel thread Cancel thread Cancel thread Cancel thread Cancel thread Completed Machine::cancelThreads() hostname=, threads=8 2. osgdem osgdem --geocentric -d dem/n30_w086_1arc_v3.tif -t texture/2.tif -o output/out.osgb answer: --geocentric -d dem/n30_w086_1arc_v3.tif ADD: dem/n30_w086_1arc_v3.tif -t texture/2.tif ADD: texture/2.tif -o output/out.osgb Adding terrainTile DataSet::_run() 0 0 Now checking for plug-in osgPlugins-3.3.8/osgdb_nvtt.dll osg::Registry::addImageProcessor(ImageProcessor) Loaded plug-in osgPlugins-3.3.8/osgdb_nvtt.dll and located ImageProcessor started DataSet::createDestination(30) reprojecting to file temporaryfile_2.tif ERROR 1: No PROJ.4 translation for source SRS, coordinate transformation initialization has failed. Failed to reproject texture/2.tif Time for after_reproject 0.003934 And here program crashes. 3. Manual reprojection using gdalwarp 3.1. gdalinfo for dem file: Driver: GTiff/GeoTIFF Files: n30_w086_1arc_v3.tif Size is 3601, 3601 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (-86.0001384,31.0001391) Pixel Size = (0.0002778,-0.0002778) Metadata: AREA_OR_POINT=Point DTED_CompilationDate=0002 DTED_DataEdition=02 DTED_DigitizingSystem=SRTM DTED_HorizontalAccuracy=0013 DTED_HorizontalDatum=WGS84 DTED_MaintenanceDate= DTED_MaintenanceDescription= DTED_MatchMergeDate= DTED_MatchMergeVersion=A DTED_NimaDesignator=DTED2 DTED_OriginLatitude=030N DTED_OriginLongitude=086W DTED_Producer=USCNIMA DTED_RelHorizontalAccuracy=NA DTED_RelVerticalAccuracy=0004 DTED_SecurityCode_DSI=U DTED_SecurityCode_UHL=U DTED_UniqueRef_DSI=H24 084 DTED_UniqueRef_UHL=H24 084 DTED_VerticalAccuracy_ACC=0005 DTED_VerticalAccuracy_UHL=0005 DTED_VerticalDatum=E96 Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left (
Re: [osg-users] Ready to tag OpenSceneGraph-3.3.8 dev release, please test
hi robert, OS:windows 7 X64 compiler:VC2010 cmake version: 3.2.2 current OpenSceneGraphsvn14909. compiled and tested OK zhuwan 06,11,2015 > -原始邮件- > 发件人: "Robert Osfield" > 发送时间: 2015-6-8 23:37:29 > 收件人: "OpenSceneGraph Users" > 抄送: > 主题: [osg-users] Ready to tag OpenSceneGraph-3.3.8 dev release, please test > > Hi All, > > I have merged various pending submissions for bug fixes and minor > feature enhancements, made a number of bug fixes/improvements myself > and am now ready to tag the 3.3.8 dev release. I've have tested under > Kubuntu 15.04 and Windows 7+VS2005 and VS2013. These are all the > platform combinations I have to had. > > Could users test svn/trunk and let me know how you get on. If things > look good I'll tag 3.3.8 tomorrow. > > Cheers, > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Correct way to get texture data from USGS or any other source?
Hello! My statement about the problem, that had been solved, looks a little premature. The problem: Terrain is displayed incorrectly. Results: 1. https://drive.google.com/file/d/0ByDDImhSolf6cGFyV21PRXZuZHM/view?usp=sharing 2. https://drive.google.com/file/d/0ByDDImhSolf6N3FvRkNJUW1nMlk/view?usp=sharing Step-by-step actions to make a terrain 0. Gathering required data 0.1. Choose texture: https://drive.google.com/file/d/0ByDDImhSolf6S3E0M1VmR2xDd1U/view?usp=sharing 0.2. Choose dem: https://drive.google.com/file/d/0ByDDImhSolf6cDNtWjlUa3VqdXc/view?usp=sharing 0.3. Downloaded texture: https://drive.google.com/file/d/0ByDDImhSolf6eXRpYlhxMFN3NnM/view?usp=sharing 0.4. Downloaded dem: https://drive.google.com/file/d/0ByDDImhSolf6MXVLUV9kOG1xR2c/view?usp=sharing 1. Straightforward vpbmaster --geocentric -d dem/n30_w086_1arc_v3.tif -t texture/2.tif -o output/out.osgb answer: --geocentric -d dem/n30_w086_1arc_v3.tif ADD: dem/n30_w086_1arc_v3.tif -t texture/2.tif ADD: texture/2.tif -o output/out.osgb Adding terrainTile Error: vpbmaster can not run without all source data being in the correct destination coordinates system, please reproject them. Recieved signal 15, doing TERMINATE_RUNNING_TASKS_THEN_EXIT. Setting up MachinePool to use all 8 cores on this machine. MachinePool::signal(15) Machine::signal(15) Machine::cancelThreads() hostname=, threads=8 Cancel thread Cancel thread Cancel thread Cancel thread Cancel thread Cancel thread Cancel thread Cancel thread Completed Machine::cancelThreads() hostname=, threads=8 2. osgdem osgdem --geocentric -d dem/n30_w086_1arc_v3.tif -t texture/2.tif -o output/out.osgb answer: --geocentric -d dem/n30_w086_1arc_v3.tif ADD: dem/n30_w086_1arc_v3.tif -t texture/2.tif ADD: texture/2.tif -o output/out.osgb Adding terrainTile DataSet::_run() 0 0 Now checking for plug-in osgPlugins-3.3.8/osgdb_nvtt.dll osg::Registry::addImageProcessor(ImageProcessor) Loaded plug-in osgPlugins-3.3.8/osgdb_nvtt.dll and located ImageProcessor started DataSet::createDestination(30) reprojecting to file temporaryfile_2.tif ERROR 1: No PROJ.4 translation for source SRS, coordinate transformation initialization has failed. Failed to reproject texture/2.tif Time for after_reproject 0.003934 And here program crashes. 3. Manual reprojection using gdalwarp 3.1. gdalinfo for dem file: Driver: GTiff/GeoTIFF Files: n30_w086_1arc_v3.tif Size is 3601, 3601 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (-86.0001384,31.0001391) Pixel Size = (0.0002778,-0.0002778) Metadata: AREA_OR_POINT=Point DTED_CompilationDate=0002 DTED_DataEdition=02 DTED_DigitizingSystem=SRTM DTED_HorizontalAccuracy=0013 DTED_HorizontalDatum=WGS84 DTED_MaintenanceDate= DTED_MaintenanceDescription= DTED_MatchMergeDate= DTED_MatchMergeVersion=A DTED_NimaDesignator=DTED2 DTED_OriginLatitude=030N DTED_OriginLongitude=086W DTED_Producer=USCNIMA DTED_RelHorizontalAccuracy=NA DTED_RelVerticalAccuracy=0004 DTED_SecurityCode_DSI=U DTED_SecurityCode_UHL=U DTED_UniqueRef_DSI=H24 084 DTED_UniqueRef_UHL=H24 084
Re: [osg-users] [vpb] Correct way to get texture data from USGS or any other source?
Hello! My statement about the problem, that had been solved, looks a little premature. The problem: Terrain is displayed incorrectly. Results: 1. https://drive.google.com/file/d/0ByDDImhSolf6cGFyV21PRXZuZHM/view?usp=sharing 2. https://drive.google.com/file/d/0ByDDImhSolf6N3FvRkNJUW1nMlk/view?usp=sharing Step-by-step actions to make a terrain 0. Gathering required data 0.1. Choose texture: https://drive.google.com/file/d/0ByDDImhSolf6S3E0M1VmR2xDd1U/view?usp=sharing 0.2. Choose dem: https://drive.google.com/file/d/0ByDDImhSolf6cDNtWjlUa3VqdXc/view?usp=sharing 0.3. Downloaded texture: https://drive.google.com/file/d/0ByDDImhSolf6eXRpYlhxMFN3NnM/view?usp=sharing 0.4. Downloaded dem: https://drive.google.com/file/d/0ByDDImhSolf6MXVLUV9kOG1xR2c/view?usp=sharing 1. Straightforward vpbmaster --geocentric -d dem/n30_w086_1arc_v3.tif -t texture/2.tif -o output/out.osgb answer: --geocentric -d dem/n30_w086_1arc_v3.tif ADD: dem/n30_w086_1arc_v3.tif -t texture/2.tif ADD: texture/2.tif -o output/out.osgb Adding terrainTile Error: vpbmaster can not run without all source data being in the correct destination coordinates system, please reproject them. Recieved signal 15, doing TERMINATE_RUNNING_TASKS_THEN_EXIT. Setting up MachinePool to use all 8 cores on this machine. MachinePool::signal(15) Machine::signal(15) Machine::cancelThreads() hostname=, threads=8 Cancel thread Cancel thread Cancel thread Cancel thread Cancel thread Cancel thread Cancel thread Cancel thread Completed Machine::cancelThreads() hostname=, threads=8 2. osgdem osgdem --geocentric -d dem/n30_w086_1arc_v3.tif -t texture/2.tif -o output/out.osgb answer: --geocentric -d dem/n30_w086_1arc_v3.tif ADD: dem/n30_w086_1arc_v3.tif -t texture/2.tif ADD: texture/2.tif -o output/out.osgb Adding terrainTile DataSet::_run() 0 0 Now checking for plug-in osgPlugins-3.3.8/osgdb_nvtt.dll osg::Registry::addImageProcessor(ImageProcessor) Loaded plug-in osgPlugins-3.3.8/osgdb_nvtt.dll and located ImageProcessor started DataSet::createDestination(30) reprojecting to file temporaryfile_2.tif ERROR 1: No PROJ.4 translation for source SRS, coordinate transformation initialization has failed. Failed to reproject texture/2.tif Time for after_reproject 0.003934 And here program crashes. 3. Manual reprojection using gdalwarp 3.1. gdalinfo for dem file: Driver: GTiff/GeoTIFF Files: n30_w086_1arc_v3.tif Size is 3601, 3601 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (-86.0001384,31.0001391) Pixel Size = (0.0002778,-0.0002778) Metadata: AREA_OR_POINT=Point DTED_CompilationDate=0002 DTED_DataEdition=02 DTED_DigitizingSystem=SRTM DTED_HorizontalAccuracy=0013 DTED_HorizontalDatum=WGS84 DTED_MaintenanceDate= DTED_MaintenanceDescription= DTED_MatchMergeDate= DTED_MatchMergeVersion=A DTED_NimaDesignator=DTED2 DTED_OriginLatitude=030N DTED_OriginLongitude=086W DTED_Producer=USCNIMA DTED_RelHorizontalAccuracy=NA DTED_RelVerticalAccuracy=0004 DTED_SecurityCode_DSI=U DTED_SecurityCode_UHL=U DTED_UniqueRef_DSI=H24 084 DTED_UniqueRef_UHL=H24 084
Re: [osg-users] Ready to tag OpenSceneGraph-3.3.8 dev release, please test
Hi Rafa, I have reverted this problem typedef. Could you please test svn/trunk to make sure everything is looking good now? Cheers, Robert. On 9 June 2015 at 20:03, Rafa Gaitan wrote: > Hi Robert, > > I've just did an svn update and the error in android is still there. > > If we remove the line 35 ( typedef GLfloat GLdouble; ) of GLDefines file > then builds ok. And it does not affect to macosx build, and probably won't > affect to other desktop environments. > > I think this commit ( > http://trac.openscenegraph.org/projects/osg/changeset?new=14862%40OpenSceneGraph%2Ftrunk%2Finclude%2Fosg%2FGLDefines&old=14747%40OpenSceneGraph%2Ftrunk%2Finclude%2Fosg%2FGLDefines) > was not correctly tested at that moment and probably should be reverted. > > Regards and thank you for your efforts! > Rafa. > > El mar., 9 jun. 2015 a las 20:17, Robert Osfield > () escribió: >> >> Hi All, >> >> I have checked a couple of bug and build fixes today, could you please >> do an svn update and test again ;-) >> >> Robert. >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org