I believe the offending lines are in the osg::Geometry copy constructor:
if ((copyop.getCopyFlags() & osg::CopyOp::DEEP_COPY_ARRAYS))
{
if (_useVertexBufferObjects)
{
// copying of arrays doesn't set up buffer objects so we'll need to force
// Geometry to assign these, we'll do this by switching off VBO's then renabling them.
setUseVertexBufferObjects(false);
setUseVertexBufferObjects(true);
}
}
Toggling the vertex buffer objects off then on again actually touches not only the arrays controlled by DEEP_COPY_ARRAYS, but also the PrimitiveSets which are controlled by DEEP_COPY_PRIMITIVES. This means if the user has copyflags of only DEEP_COPY_ARRAYS, we are modifying arrays that belong to the original const Geometry& we are copying from. I believe this shouldn't be allowed to happen because we are using a const& specifier for the original Geometry.
In my case the osgUtil::IncrementalCompileOperation was trying to compile the geometry, while in the main thread a clone operation toggled the VBO's off and on, a crash ensues.
In the attached patch, you will find a more efficient handling of VBO's in the osg::Geometry copy constructor, so that only the Arrays that were actually deep copied have their VBO assigned, and no changes are made to Arrays that already had a valid VBO assigned. In addition, the DEEP_COPY_PRIMITIVES flag is now honored so that VBO's are set up correctly should a user copy a Geometry with only that flag.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15129 16af8721-9629-0410-8352-f15c8da7e697
setVertexAttribArrayList(array) with array containing NULL vertexAttrib.
I added a test in order to avoid it
Code:
void Geometry::setVertexAttribArrayList(const ArrayList& arrayList)
{
_vertexAttribList = arrayList;
dirtyDisplayList();
if (_useVertexBufferObjects)
{
for(ArrayList::iterator itr = _vertexAttribList.begin();
itr != _vertexAttribList.end();
++itr)
{
if(itr->get())//ADDED
addVertexBufferObjectIfRequired(itr->get());
}
}
}
"
and
"The bug i ran into is a crash reading osgt Geometry with null vertexattribs.
The only thing i added is a not nul check on array passed to setVertexAttribArrayList."
--------------------This line, and those below, will be ignored--
M src/osg/Geometry.cpp
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15121 16af8721-9629-0410-8352-f15c8da7e697
I used osgSetGLExtensionsFuncPtr to remove the symbols. I don't know how to test this path, but it did remove the symbols from libosgViewer.so. I have also not been able yet to see if that was sufficient for our customer.
I did this by looking at other cases, and I tried to follow some of the same practices in PixelBufferX11, like using _useSGIX in a similar way to the previous _useGLX1_3."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15041 16af8721-9629-0410-8352-f15c8da7e697
On a Intel HD graphics Linux system with Mesa 10.1.3, I found that osg's Extensions::isTextureCompressionS3TCSupported() returned false, even though S3TC compressed textures *are* in fact working. I tested this by loading and rendering various DXT1, DXT3 and DXT5 compressed textures in the OSG.
"glxinfo | grep s3tc" gives:
GL_S3_s3tc
Note, if I install the package "libtxc-dxtn-s2tc0", I get in addition:
glxinfo | grep s3tc
GL_EXT_texture_compression_s3tc
GL_S3_s3tc
However, S3TC compressed textures worked correctly within the OSG even without libtxc-dxtn-s2tc0 installed.
I'm not sure what the differences between these extensions are, but based on the description at https://www.opengl.org/registry/specs/S3/s3tc.txt I would assume that both will work for OSG's purposes. The attached patch changes isTextureCompressionS3TCSupported() to accept either extension."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15035 16af8721-9629-0410-8352-f15c8da7e697
This gives arise to the requirement that a static initialization of a QObject cannot occur for the Android platform, as Qt incorrectly considers that first thread the “main” one before a client application has even begun executing in its second thread.
The HeartBeat in GraphicsWindowQt.cpp is a QObject static global initialized at load time, causing the above issue. This changeset changes it to be a singleton that is constructed upon first access to its “instance” method.
I have:
- added the static method “instance”,
- moved its constructor to be private, and
- changed the one place it is accessed to access it through the “instance” method.
"
Changes by Robert are to adopt QPointer<HeartBeat> rather than use a C pointer to ensure that the HeartBeat object will be cleaned up automatically rather than leaked.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14963 16af8721-9629-0410-8352-f15c8da7e697
When an application is built with Qt4, but osgQt was built with Qt5 (or vice versa), upon #includeing osgQt users will receive an #error aborting the build.
This at least provides a proper error message rather than a crash, while we are working on better fixes for the problem."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14918 16af8721-9629-0410-8352-f15c8da7e697
