Objects with the same filename may be different from others based on the provided
plugin options. Using filename *and* the provided options as object cache key
helps to avoid fetching the wrong object.
(cherry picked from commit 85cd1c456f)
Only export the osgDB method implementations, instead of the entire
class, and hence avoid exporting symbols from the base class, which
then conflict with other compilation units when linking.
This avoids the need for /FORCE:MULTIPLE linker option with MSVC.
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
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
//GLbitfield mask = GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT;
This line was problematic since it produced incorrect result when let's say COLOR flag is serialized
it should be null as in Camera serializer or in a proposed BitFlagsSerializer
This line of code caused that whenever only GL_COLOR_BUFFER_BIT bit was written and on value read GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT was restored instead of GL_COLOR_BUFFER_BIT only.
//GLbitfield mask = 0; //this resolves the issue same as in camera
Also same bit-wise comparison bug was also present in write method.
-------------------------------------------------------------------------------------
As you can see there are total 3 bit mask serializers in OSG and all 3 had bugs so I decided to add ADD_BITFLAGS_SERIALIZER and replace USER serializers in osg::Camera, osg::ClearNode and osgText::TextBase. I have made sure that bitflags serializer does not break backwards-compatibility since it uses same code as user serializer does in all 3 cases. (see tester.cpp on how compatibility test was performed)"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14752 16af8721-9629-0410-8352-f15c8da7e697
attributes in vec3b format. It looks like my compiler takes the wrong
overload and outputs integers instead of characters. The problem is
that vec3b is of type signed char and that is not the same as char (
see http://stackoverflow.com/questions/436513/char-signed-char-char-unsigned-char
) and visual studio 2013 will promote it to integer when choosing an
overload.
It looks like that the InputStream class already takes care of this
issue (if it didn't it would have read everything ok and I would have
not even stumbled upon this bug. :) )"
