This approach unifies much of the code handling the clean up of OpenGL graphics data, avoids lots of local mutexes and static variables that were previously required,
and enables the clean up scheme to be easily extended by users providing their own GraphicsObjectManager subclasses.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15130 16af8721-9629-0410-8352-f15c8da7e697
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
