"From I think that this piece of code in StateSet::setTextureAttributeAndModes is a copy&paste mistake:
OSG_NOTICE<<"Warning: non texture attribute '"<<attribute->className()<<"' passed to setTextureAttributeAndModes(unit,attr,value), "<<std::endl;
OSG_NOTICE<<" assuming setAttributeAndModes(attr,value) instead."<<std::endl;
OSG_NOTICE<<" please change calling code to use appropriate call."<<std::endl;
setAttribute(attribute,value);
As per the warning message it should be calling setAttributeAndModes(attribute,value); ."
The change I made is to check GL_QUERY_RESULT_AVAILABLE before retrieving the query, to ensure that there won't be a stall. If the query result is not available yet, we'll leave it alone and try again in the next frame.
Had to make a few more changes than I'd liked, mostly because the TestResult mechanism wasn't designed for holding on to query objects for more than one frame. As well, I'm thinking that RetrieveQueriesCallback and ClearQueriesCallback could be merged together, if we wanted to go for more refactoring. For though now my strategy is to make as little changes as possible. Let me know what you think of the patch."
Currently the code looks like this:
Code:
DrawElementsUByte* elems = new DrawElementsUByte(PrimitiveSet::TRIANGLES);
elems->push_back(0);
elems->push_back(1);
elems->push_back(2);
elems->push_back(2);
elems->push_back(3);
elems->push_back(0);
geom->addPrimitiveSet(elems);
geom->addPrimitiveSet(new DrawArrays(PrimitiveSet::QUADS,0,4));
The second condition looked really strange (note the ! sign), and results in pretty much all code paths uses the first code. The correct version should probably be that only people with GLES1 or GLES2 should use GL_TRIANGLES to simulate quads. And all others should use the native support for GL_QUADS.
"
E:\osg\osgSvnGit\OpenSceneGraph\src\osg\PrimitiveSet.cpp(364): error C2039: 'min' : is not a member of 'std'
E:\osg\osgSvnGit\OpenSceneGraph\src\osg\PrimitiveSet.cpp(364): error C3861: 'min': identifier not found
E:\osg\osgSvnGit\OpenSceneGraph\src\osg\PrimitiveSet.cpp(372): error C2039: 'min' : is not a member of 'std'
E:\osg\osgSvnGit\OpenSceneGraph\src\osg\PrimitiveSet.cpp(372): error C3861: 'min': identifier not found
E:\osg\osgSvnGit\OpenSceneGraph\src\osg\PrimitiveSet.cpp(381): error C2039: 'min' : is not a member of 'std'
E:\osg\osgSvnGit\OpenSceneGraph\src\osg\PrimitiveSet.cpp(381): error C3861: 'min': identifier not found
E:\osg\osgSvnGit\OpenSceneGraph\src\osg\PrimitiveSet.cpp(436): error C2039: 'min' : is not a member of 'std'
E:\osg\osgSvnGit\OpenSceneGraph\src\osg\PrimitiveSet.cpp(436): error C3861: 'min': identifier not found
I suggest to replace std::min by osg::minimum, attached is a (zipped) modified version of src/osg/PrimitiveSet.cpp
applies to the git reposetory only (updated 1 Feb 2016 ae6bade641ee4d8436ef69e7a7a347be81195a47 )
"
forcing users to use osgDB::readRef*File() methods. The later is preferable as it closes a potential threading bug when using paging databases in conjunction
with the osgDB::Registry Object Cache. This threading bug occurs when one thread gets an object from the Cache via an osgDB::read*File() call where only
a pointer to the object is passed back, so taking a reference to the object is delayed till it gets reassigned to a ref_ptr<>, but at the same time another
thread calls a flush of the Object Cache deleting this object as it's referenceCount is now zero. Using osgDB::readREf*File() makes sure the a ref_ptr<> is
passed back and the referenceCount never goes to zero.
To ensure the OSG builds when OSG_PROVIDE_READFILE is to OFF the many cases of osgDB::read*File() usage had to be replaced with a ref_ptr<> osgDB::readRef*File()
usage. The avoid this change causing lots of other client code to be rewritten to handle the use of ref_ptr<> in place of C pointer I introduced a serious of
templte methods in various class to adapt ref_ptr<> to the underly C pointer to be passed to old OSG API's, example of this is found in include/osg/Group:
bool addChild(Node* child); // old method which can only be used with a Node*
tempalte<class T> bool addChild(const osg::ref_ptr<T>& child) { return addChild(child.get()); } // adapter template method
These changes together cover 149 modified files, so it's a large submission. This extent of changes are warrent to make use of the Object Cache
and multi-threaded loaded more robust.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15164 16af8721-9629-0410-8352-f15c8da7e697
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
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
