The file osg-OpenSceneGraph-3.4.0\include\osg\Types
typedefs int8_t, int16_t, int32_t and int64_t
These are typedefed as signed __intX in several other places.
With VS2008, this causes an error "int8_t redifined, different basic types"
Explicitly declaring them signed fixes the error."
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.
"
/usr/local/include/collada-dom2.4
/usr/local/include/collada-dom2.2
/opt/local/include/collada-dom2.4
/opt/local/include/collada-dom2.2
/usr/include/collada-dom2.4
/usr/include/collada-dom2.2
To enable recent versions of the DOM to be found in their new install locations.
Removed old code intended to check the Geode parent of a Drawable to see if it's CullingActive is true as this was broken by the change osg::Drawable being derived from osg::Node rather than osg::Object.
Two fixed files:
osgPlugins/osgjs/JSON_Objects
osgPlugins/stl/ReaderWriterSTL.cpp.
They did not compile with VS 2008 (recent master from Github). It looks like they defined stdint types (missing in VS 2008) but code using them also included <osg/Types> header. Errors were caused by minor differences in signed int definitions. I just removed own definitions and added include<osg/Types> instead. It solves the problem and makes the code clearer now.
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/branches/OpenSceneGraph-3.4@15165 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/branches/OpenSceneGraph-3.4@15128 16af8721-9629-0410-8352-f15c8da7e697
It should stop and wait for a signal on either of those two. Due to a few logical inversions it boils down to replacing || with &&
OLD _block->set((!_requestList.empty() || !_pager->_databasePagerThreadPaused));
NEW _block->set((!_requestList.empty() && !_pager->_databasePagerThreadPaused));//release the threads to run IF (work_to_be_done && not_paused)
This bug is present since svn rev 8663 (just before 2.6.0 release)
attached is a zip with the files:
OpenSceneGraph\include\osgDB\ImagePager
This file is valid for svn branch and stable 3.2 and 3.4
branches 2.6 - 3.0 have the same bug, but other differences in the file."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/branches/OpenSceneGraph-3.4@15126 16af8721-9629-0410-8352-f15c8da7e697
