Re: [osg-users] osgQt versioning problem
On Fri, Jun 12, 2015 at 1:00 AM, Jannik Heller scr...@baseoftrash.de wrote: 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. Then it cannot be a problem, because all distros recompile the applications they package for their repositories using their libraries. You can specify in the spec file (if you are building for RPM-based distro) or the manifest for .dpkg (for Debian/Ubuntu/...) which library version your application needs. Then the package will not build for the repository maintainer until the requirements are met. The only exception are binary-only, proprietary software packages - but there you are on your own and shipping everything needed is your problem. Sounds easy in principle, but will cause a waterfall of problems for package repositories. I don't see how - if you set up your package requirements properly, then there is no way the repository maintainer could build your package requiring one version of Qt and build OSG using another one. - 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. Well, there isn't really a way around that - you must have two versions of OSG installed side by side for this to work. That's the responsibility of the distro packager, IMHO, not yours. If they build the packages inconsistently, despite your specified requirements, well, things won't work, but only they are to blame in such case. OSG is no way special there - this is a common issue with software requiring e.g. specific version of Python, wxWindows toolkit, KDE/Gnome ... 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 ;) OK. I would say that the only thing you could do is to document this requirement. It is the packagers' job to deal with this. 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. You just have to build OSG twice using each version of Qt in turn. OSG respects the DESIRED_QT_VERSION already. cmake -DDESIRED_QT_VERSION=5 - use Qt 5.x cmake -DDESIRED_QT_VERSION=4 - use the Qt 4.x series Regards, J. ___ 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
Hi Jannik, On 12 June 2015 at 00:00, Jannik Heller scr...@baseoftrash.de wrote: Still, I'm convinced there's a bigger issue here. I'd be curious what Robert's thoughts are. Issue like dependencies on 3rd party libraries that keep changing versions/compatibility in major ways is painful for everyone. I miss the day when the OSG had very few external dependencies. For this particular issue I see a couple possible approaches: 1) Maintain two separate osgQt libraries, an osgQt4 and an osgQt5 2) Move the implementation in src/osgQt into the headers in include osgQt and have no osgQt library 3) User provides their own Qt integration. Thoughts? 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
Actually the default version Qt 5.4 dynamically selects what it thinks is the most appropriate version of OpenGL to use. You can force it to use desktop OpenGL by calling QCoreApplication::setAttribute(Qt::AA_UseDesktopOpenGL) on your app instance before you call exec on it. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.3.8 dev release tagged
hi robert, The biggest problem is the AMD Intel's OpenGL driver is still have many bugs,i prey let ATI dis appear ever day,one day ATI doesn't exist in the world,and the intel's driver is much better than ever! The OpenSceneGraph's newest version use opengl shaders more and more,but will encounter more and more AMD opengl driver bugs! zhuwan 06,12,2015 在2015-6-12 20:33:22，Robert Osfield robert.osfi...@gmail.com 写道: -原始邮件- 发件人: Robert Osfield robert.osfi...@gmail.com 发送时间: 2015-6-12 20:33:22 收件人: OpenSceneGraph Users osg-users@lists.openscenegraph.org 主题: [osg-users] OpenSceneGraph-3.3.8 dev release tagged Hi All, I have just tagged the OpenSceneGraph-3.3.8 developer release. Focus for this dev release has been a whole series of bug and build fixes. source package : OpenSceneGraph-3.3.8.zip svn tag: svn co http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-3.3.8 OpenSceneGraph Feature wise I'm pretty happy with where the dev series is at, so am now focused on readying OSG svn/trunk for the OSG-3.4 stable release, this dev release is another step in this process. Please test on as many platform combinations as you can and against your own applications. If there are problems with this dev release just post them here so we can can discuss how best to resolve them. If everything looks like a stable then I'll create the OSG-3.4 branch next week and start the OSG-3.4 release candidate series. Thanks to all who have contributed, Robert. -- ChangeLog since 3.3.7 2015-06-12 08:04 robert * src/osgText/TextBase.cpp: From Farshid Lashkari, I've modified some setter methods of TextBase to avoid unnecessary calls to computeGlyphRepresentation() if the value has not changed. 2015-06-11 08:44 robert * include/osg/GLDefines: Reverted the typdef GLfloat GLdouble for Andoid as this was causing conflicts. 2015-06-10 18:22 robert * AUTHORS.txt, ChangeLog: Updated ChangeLog and AUTHORS file for 3.3.8 dev release 2015-06-10 16:48 robert * CMakeModules/FindOpenEXR.cmake: From Laurens Voerman, attached is a zip with the files: OpenSceneGraph\CMakeModules\FindOpenEXR.cmake I introduced a bug in the previous submission pointed out by Dmitry Marakasov: looking for IlmIlf instead of IlmImf (as the previous version did - but using variable OPENEXR_IlmIlf_LIBRARY) For some reason google decided his message was spam, so I just noticed it, and I reply to confirm his remarks and attach a full file. 2015-06-10 16:47 robert * src/osg/GLExtensions.cpp, src/osg/Texture.cpp: From Colin McDonald, An earlier fix in OSG 3.2 has been inadvertently lost in 3.3.x. The glGenerateMipMap function is part of the GL_EXT_framebuffer_object extension. Just checking if the function is present before using it for texture mipmaps is not sufficient, as on remote X-windows displays the client side capability may be different from the display server. This can lead to mipmapped textures failing to render. I've restored a fbo extension check. I've also tided up the GL version checking a little. 2015-06-10 10:00 robert * src/osgGA/NodeTrackerManipulator.cpp: From Philippe Renon, Fixed potential divide by zero in NodeTrackerManipulator : The divide by zero happens when throwing a NodeTrackerManipulator. The infinite result trickles down and later causes NaN in culling. The fix was to use getThrowScale() as done everywhere else. 2015-06-09 16:49 robert * CMakeLists.txt, include/osgDB/Serializer, src/osgWrappers/serializers/osg/Camera.cpp: Added supoort for osg::CullSettings/Camera::InheritanceMaskActionOnAttributeSetting and InheritanceMask properties. 2015-06-09 12:51 robert * include/osg/GLDefines: Added namespace around typedef to avoid conflict issues 2015-06-09 10:49 robert * include/osg/Node, include/osg/NodeVisitor, include/osg/Object, include/osg/StateAttribute, include/osg/Uniform, src/osg/Callback.cpp: Introduce osg::Object::asNode(), asNodeVisitor(), asStateAttribute() and asUniform() to replace dynamic_cast usage in Callback.cpp. 2015-06-09 09:44 robert * examples/osghud/osghud.cpp: Added output of HUD scene graph to hud.osgt and hud.osgb for testing purposes. 2015-06-08 11:33 robert * AUTHORS.txt, ChangeLog: Updated AUTHORS and ChangeLog for dev release 2015-06-08 11:18 robert * include/osgDB/Options, src/osgDB/DatabasePager.cpp, src/osgDB/Options.cpp: From Mike Connell, Give ReadFileCallback access to parent location : These small changes to the database pager allow user code in the ReadFileCallback to safely determine where the file being loaded is destined to be inserted into the scenegraph. 2015-06-08 10:20 robert * src/osgUtil/SceneView.cpp: Addressed race condition where SceneView::setLightingMode() was setting a shread Master Camera's StateSet. 2015-06-07
Re: [osg-users] osgQt versioning problem
Hi, You just have to build OSG twice using each version of Qt in turn. OSG respects the DESIRED_QT_VERSION already. cmake -DDESIRED_QT_VERSION=5 - use Qt 5.x cmake -DDESIRED_QT_VERSION=4 - use the Qt 4.x series Yes, but then you won't be able to install those two OSG versions at the same time. Unless you renamed libraries or used a completely separate prefix for each OSG build, but there isn't an established pattern to do so, so what we'd end up with is each distribution inventing its own ways to cope with the versioning problem. That is what should be avoided at all cost. You can specify in the spec file (if you are building for RPM-based distro) or the manifest for .dpkg (for Debian/Ubuntu/...) which library version your application needs. Then the package will not build for the repository maintainer until the requirements are met. I don't see how - if you set up your package requirements properly, then there is no way the repository maintainer could build your package requiring one version of Qt and build OSG using another one. Speaking for some popular distro's that I've seen, there is a way to request a version of the OSG, but no way to request a Qt version of osgQt. No one bothered to add separate versioning for it, probably because the OSG itself doesn't provide one either so doesn't set a precedent on how it should be done. See my earlier comment w.r.t each distribution being forced to invent their own solutions. Yes, it can work, if you jump through some hoops and are careful in what you do. My point is: it *should* work out of the box. A framework is supposed to make the developer's job easier, not harder, after all. In my experience with packaged repositories, whatever can go wrong, *will* go wrong eventually. Thus having proper safeguards in place can safe you a lot of time. 1) Maintain two separate osgQt libraries, an osgQt4 and an osgQt5 That sounds good. It wouldn't have to be a separately maintained source tree, just building the same tree twice with different build parameters. Cheers, Jannik -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64071#64071 ___ 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
On Fri, Jun 12, 2015 at 2:51 PM, Jannik Heller scr...@baseoftrash.de wrote: Hi, You just have to build OSG twice using each version of Qt in turn. OSG respects the DESIRED_QT_VERSION already. cmake -DDESIRED_QT_VERSION=5 - use Qt 5.x cmake -DDESIRED_QT_VERSION=4 - use the Qt 4.x series Yes, but then you won't be able to install those two OSG versions at the same time. Unless you renamed libraries or used a completely separate prefix for each OSG build, but there isn't an established pattern to do so, so what we'd end up with is each distribution inventing its own ways to cope with the versioning problem. That is what should be avoided at all cost. Yes, correct. However, there are few applications that *need* OSG that are commonly packaged by Linux distros and that don't ship their own OSG. So you build the package against whatever OSG/Qt combo is on the machine. If someone then force installs the wrong version of Qt, breaking dependencies, that's not really something you can do much about. Speaking for some popular distro's that I've seen, there is a way to request a version of the OSG, but no way to request a Qt version of osgQt. No one bothered to add separate versioning for it, probably because the OSG itself doesn't provide one either so doesn't set a precedent on how it should be done. See my earlier comment w.r.t each distribution being forced to invent their own solutions. OSG does provide an option to choose the Qt version already. This problem is hardly unique and is commonly encountered - have a look at e.g. apps using OpenCV, wxWindows, or Gnome libraries. Typically these additional requirements are documented in the README/INSTALL file, so the packagers (or whoever is compiling the application) should pay attention to it. Again, that not something you, as the app developer, should be dealing with. Yes, it can work, if you jump through some hoops and are careful in what you do. My point is: it *should* work out of the box. A framework is supposed to make the developer's job easier, not harder, after all. In my experience with packaged repositories, whatever can go wrong, *will* go wrong eventually. Thus having proper safeguards in place can safe you a lot of time. Agreed. However, there isn't all that much that OSG can (or even should) do here. What are you going to do if the distro packagers decide to build OSG with no Qt support at all to reduce dependencies (completely legitimate thing from a packager's point of view)? It is an optional component, finally. 1) Maintain two separate osgQt libraries, an osgQt4 and an osgQt5 That sounds good. It wouldn't have to be a separately maintained source tree, just building the same tree twice with different build parameters. That could be an option, but probably you won't be able to build it from the same build folder by re-running cmake with different options - the CMake Qt variables conflict (not OSG specific, that's a CMake thing). So you would need to build in separate folders (or wipe the CMakeCache.txt, but that is equivalent - causes a full rebuild). J. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph-3.3.8 dev release tagged
Hi All, I have just tagged the OpenSceneGraph-3.3.8 developer release. Focus for this dev release has been a whole series of bug and build fixes. *source package :* OpenSceneGraph-3.3.8.zip http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-3.3.8.zip *svn tag:* svn co http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-3.3.8 OpenSceneGraph Feature wise I'm pretty happy with where the dev series is at, so am now focused on readying OSG svn/trunk for the OSG-3.4 stable release, this dev release is another step in this process. Please test on as many platform combinations as you can and against your own applications. If there are problems with this dev release just post them here so we can can discuss how best to resolve them. If everything looks like a stable then I'll create the OSG-3.4 branch next week and start the OSG-3.4 release candidate series. Thanks to all who have contributed, Robert. -- ChangeLog since 3.3.7 2015-06-12 08:04 robert * src/osgText/TextBase.cpp: From Farshid Lashkari, I've modified some setter methods of TextBase to avoid unnecessary calls to computeGlyphRepresentation() if the value has not changed. 2015-06-11 08:44 robert * include/osg/GLDefines: Reverted the typdef GLfloat GLdouble for Andoid as this was causing conflicts. 2015-06-10 18:22 robert * AUTHORS.txt, ChangeLog: Updated ChangeLog and AUTHORS file for 3.3.8 dev release 2015-06-10 16:48 robert * CMakeModules/FindOpenEXR.cmake: From Laurens Voerman, attached is a zip with the files: OpenSceneGraph\CMakeModules\FindOpenEXR.cmake I introduced a bug in the previous submission pointed out by Dmitry Marakasov: looking for IlmIlf instead of IlmImf (as the previous version did - but using variable OPENEXR_IlmIlf_LIBRARY) For some reason google decided his message was spam, so I just noticed it, and I reply to confirm his remarks and attach a full file. 2015-06-10 16:47 robert * src/osg/GLExtensions.cpp, src/osg/Texture.cpp: From Colin McDonald, An earlier fix in OSG 3.2 has been inadvertently lost in 3.3.x. The glGenerateMipMap function is part of the GL_EXT_framebuffer_object extension. Just checking if the function is present before using it for texture mipmaps is not sufficient, as on remote X-windows displays the client side capability may be different from the display server. This can lead to mipmapped textures failing to render. I've restored a fbo extension check. I've also tided up the GL version checking a little. 2015-06-10 10:00 robert * src/osgGA/NodeTrackerManipulator.cpp: From Philippe Renon, Fixed potential divide by zero in NodeTrackerManipulator : The divide by zero happens when throwing a NodeTrackerManipulator. The infinite result trickles down and later causes NaN in culling. The fix was to use getThrowScale() as done everywhere else. 2015-06-09 16:49 robert * CMakeLists.txt, include/osgDB/Serializer, src/osgWrappers/serializers/osg/Camera.cpp: Added supoort for osg::CullSettings/Camera::InheritanceMaskActionOnAttributeSetting and InheritanceMask properties. 2015-06-09 12:51 robert * include/osg/GLDefines: Added namespace around typedef to avoid conflict issues 2015-06-09 10:49 robert * include/osg/Node, include/osg/NodeVisitor, include/osg/Object, include/osg/StateAttribute, include/osg/Uniform, src/osg/Callback.cpp: Introduce osg::Object::asNode(), asNodeVisitor(), asStateAttribute() and asUniform() to replace dynamic_cast usage in Callback.cpp. 2015-06-09 09:44 robert * examples/osghud/osghud.cpp: Added output of HUD scene graph to hud.osgt and hud.osgb for testing purposes. 2015-06-08 11:33 robert * AUTHORS.txt, ChangeLog: Updated AUTHORS and ChangeLog for dev release 2015-06-08 11:18 robert * include/osgDB/Options, src/osgDB/DatabasePager.cpp, src/osgDB/Options.cpp: From Mike Connell, Give ReadFileCallback access to parent location : These small changes to the database pager allow user code in the ReadFileCallback to safely determine where the file being loaded is destined to be inserted into the scenegraph. 2015-06-08 10:20 robert * src/osgUtil/SceneView.cpp: Addressed race condition where SceneView::setLightingMode() was setting a shread Master Camera's StateSet. 2015-06-07 11:13 robert * src/osgViewer/CompositeViewer.cpp, src/osgViewer/Viewer.cpp: Fixed setReferenceTime() bug where a * eather than the correct / was being used. Bug and fix suggested Benjamin Richter. 2015-06-04 09:35 robert * AUTHORS.txt, ChangeLog, applications/osgversion/Contributors.cpp: Updated AUTHORS for dev release 2015-06-04 09:13 robert * src/osg/Transform.cpp: From Jannik Heller, Transform::computeBound() optimization. 2015-06-04 09:05 robert * include/osgViewer/ViewerEventHandlers: From Jannik Heller, Removed unused
Re: [osg-users] osgviewerQt integration required
On Fri, Jun 12, 2015 at 1:36 PM, Alistair Baxter alist...@mve.com wrote: Actually the default version Qt 5.4 dynamically selects what it thinks is the most appropriate version of OpenGL to use. You can force it to use desktop OpenGL by calling QCoreApplication::setAttribute(Qt::AA_UseDesktopOpenGL) on your app instance before you call exec on it. Ah interesting to know. That wasn't the case before. Thanks for the tip. J. ___ 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
Hi Robert, that's certainly an option, and it seems like the option that would place the least burden on developers. I like the idea. Counting the lines of code in osgQt we have just under 2000 lines in implementation files, having that much code in headers shouldn't be too much of a problem. I don't know how feasible it is, it'd require us to automatically select between Qt4 and Qt4 based in someway. Perhaps an osgQT/QT4 and osgQT/QT5 headers could include all the appropriate parts required, and then have 3rd party apps include which one they want, and have these set defines to select the different paths. Not even that is necessary, I think. The osgQt headers already have #if QT_VERSION_CHECK(...) macros to select the appropriate code. Users would be able to #include osgQt/... and automatically get the correct code for the Qt version that their application is using. It's a bit more work though to move that much code around, so for now I'm submitting the osgQt/Version fix. We can undo it later if the better fix comes around. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64078#64078 ___ 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
On 12 June 2015 at 20:58, Jannik Heller scr...@baseoftrash.de wrote: On second thought, I'm not sure how this solution would interact with the MOC (QT meta object compiler). osgQt::QGraphicsViewAdapter is a Q_OBJECT, meaning the MOC needs to run on it and produce an object file. If we move all code to the headers, then it would fall on the users responsibility to make sure they run the MOC on osg-headers. That's not too optimal. Bits of Qt are just crap with clever solutions like MOC that often just end up introducing their own problems. Perhaps one would just need to avoid using the whole MOC stuff and linking directly the callbacks in normal C++. Robert. ___ 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
On second thought, I'm not sure how this solution would interact with the MOC (QT meta object compiler). osgQt::QGraphicsViewAdapter is a Q_OBJECT, meaning the MOC needs to run on it and produce an object file. If we move all code to the headers, then it would fall on the users responsibility to make sure they run the MOC on osg-headers. That's not too optimal. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64079#64079 ___ 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
Hi Jannik, On 12 June 2015 at 18:24, Jannik Heller scr...@baseoftrash.de wrote: as a first step to rectify the problem I have introduced a version check within osgQt (include/osgQt/Version) to store the Qt version that osgQt has been compiled against. If there is a version mismatch, the build process will abort with an #error rather than crashing at runtime later on. Will post to osg-submissions in a second. Sounds like a reasonable improvement. Have you looked at the option of moving the implementation to the headers? I don't know how feasible it is, it'd require us to automatically select between Qt4 and Qt4 based in someway. Perhaps an osgQT/QT4 and osgQT/QT5 headers could include all the appropriate parts required, and then have 3rd party apps include which one they want, and have these set defines to select the different paths. I'm just throwing out ideas here - I have no clue what might actually work well. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.3.8 dev release tagged
Hi, Compiles and runs fine on Windows 7 + Qt 5.4.1 + MingW 4.9.1 Cheers, Philippe -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64082#64082 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.3.8 dev release tagged
hi robert, For example,i know a opengl engine,named C4 engine current URL is: http://www.terathon.com/ This engine from it's birthday,many years before,i always test their demos,and from the first days,found it's shadow use opengl shaders,so judged this engine will encounter many many problems,even the source code is correct and clean also very cheap. The openscenegraph's demos haven't many opengl shaders in the first day,infact many people like the light and smart program used less or no shaders. zhuwan 06,12,2015 在2015-6-12 20:33:22，Robert Osfield robert.osfi...@gmail.com 写道: -原始邮件- 发件人: Robert Osfield robert.osfi...@gmail.com 发送时间: 2015-6-12 20:33:22 收件人: OpenSceneGraph Users osg-users@lists.openscenegraph.org 主题: [osg-users] OpenSceneGraph-3.3.8 dev release tagged Hi All, I have just tagged the OpenSceneGraph-3.3.8 developer release. Focus for this dev release has been a whole series of bug and build fixes. source package : OpenSceneGraph-3.3.8.zip svn tag: svn co http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-3.3.8 OpenSceneGraph Feature wise I'm pretty happy with where the dev series is at, so am now focused on readying OSG svn/trunk for the OSG-3.4 stable release, this dev release is another step in this process. Please test on as many platform combinations as you can and against your own applications. If there are problems with this dev release just post them here so we can can discuss how best to resolve them. If everything looks like a stable then I'll create the OSG-3.4 branch next week and start the OSG-3.4 release candidate series. Thanks to all who have contributed, Robert. -- ChangeLog since 3.3.7 2015-06-12 08:04 robert * src/osgText/TextBase.cpp: From Farshid Lashkari, I've modified some setter methods of TextBase to avoid unnecessary calls to computeGlyphRepresentation() if the value has not changed. 2015-06-11 08:44 robert * include/osg/GLDefines: Reverted the typdef GLfloat GLdouble for Andoid as this was causing conflicts. 2015-06-10 18:22 robert * AUTHORS.txt, ChangeLog: Updated ChangeLog and AUTHORS file for 3.3.8 dev release 2015-06-10 16:48 robert * CMakeModules/FindOpenEXR.cmake: From Laurens Voerman, attached is a zip with the files: OpenSceneGraph\CMakeModules\FindOpenEXR.cmake I introduced a bug in the previous submission pointed out by Dmitry Marakasov: looking for IlmIlf instead of IlmImf (as the previous version did - but using variable OPENEXR_IlmIlf_LIBRARY) For some reason google decided his message was spam, so I just noticed it, and I reply to confirm his remarks and attach a full file. 2015-06-10 16:47 robert * src/osg/GLExtensions.cpp, src/osg/Texture.cpp: From Colin McDonald, An earlier fix in OSG 3.2 has been inadvertently lost in 3.3.x. The glGenerateMipMap function is part of the GL_EXT_framebuffer_object extension. Just checking if the function is present before using it for texture mipmaps is not sufficient, as on remote X-windows displays the client side capability may be different from the display server. This can lead to mipmapped textures failing to render. I've restored a fbo extension check. I've also tided up the GL version checking a little. 2015-06-10 10:00 robert * src/osgGA/NodeTrackerManipulator.cpp: From Philippe Renon, Fixed potential divide by zero in NodeTrackerManipulator : The divide by zero happens when throwing a NodeTrackerManipulator. The infinite result trickles down and later causes NaN in culling. The fix was to use getThrowScale() as done everywhere else. 2015-06-09 16:49 robert * CMakeLists.txt, include/osgDB/Serializer, src/osgWrappers/serializers/osg/Camera.cpp: Added supoort for osg::CullSettings/Camera::InheritanceMaskActionOnAttributeSetting and InheritanceMask properties. 2015-06-09 12:51 robert * include/osg/GLDefines: Added namespace around typedef to avoid conflict issues 2015-06-09 10:49 robert * include/osg/Node, include/osg/NodeVisitor, include/osg/Object, include/osg/StateAttribute, include/osg/Uniform, src/osg/Callback.cpp: Introduce osg::Object::asNode(), asNodeVisitor(), asStateAttribute() and asUniform() to replace dynamic_cast usage in Callback.cpp. 2015-06-09 09:44 robert * examples/osghud/osghud.cpp: Added output of HUD scene graph to hud.osgt and hud.osgb for testing purposes. 2015-06-08 11:33 robert * AUTHORS.txt, ChangeLog: Updated AUTHORS and ChangeLog for dev release 2015-06-08 11:18 robert * include/osgDB/Options, src/osgDB/DatabasePager.cpp, src/osgDB/Options.cpp: From Mike Connell, Give ReadFileCallback access to parent location : These small changes to the database pager allow user code in the ReadFileCallback to safely determine where the file being loaded is destined to be inserted into the scenegraph. 2015-06-08 10:20
Re: [osg-users] OpenSceneGraph-3.3.8 dev release tagged
Hi Zhuwan, On 12 June 2015 at 14:15, webmaster webmas...@3dvri.com wrote: The biggest problem is the AMD Intel's OpenGL driver is still have many bugs,i prey let ATI dis appear ever day,one day ATI doesn't exist in the world,and the intel's driver is much better than ever! The OpenSceneGraph's newest version use opengl shaders more and more,but will encounter more and more AMD opengl driver bugs! This is pretty off topic and a rather misguided. The OSG-3.3.x series does not use shaders any more than the OSG-3.2.x series. There is better support for use of shaders with support of #prama(tic) shader composition but this isn't forced any users. It's users application that choose to use fixed function pipeline or shaders, the OSG itself doesn't force this upon application developers. Finally driver quality isn't an OSG specific problem, there isn't anything much we can do about it save workaround problems when they do occur. This issue his little baring of the OSG-3.3.x dev series and the final OSG-3.4 series. I'm at lost why you raise these topics in the context of the OSG-3.3.8 release. Robert. ___ 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
Hi, as a first step to rectify the problem I have introduced a version check within osgQt (include/osgQt/Version) to store the Qt version that osgQt has been compiled against. If there is a version mismatch, the build process will abort with an #error rather than crashing at runtime later on. Will post to osg-submissions in a second. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64076#64076 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
