This should have been fixed in my old submission from 2012 but was probably overlooked due to an alternative way of comparing to a fix number for this feature type.
Without this fix, the plugin will only read one PointZ feature even if multiple features exist."
Actually, if the option "readObjectRecordData" is set, ObjectRecordData will not be read and set.
With this submission, if the option "readObjectRecordData" is set, ObjectRecordData will be read and set."
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
The first leak is in the lib3ds module (yeah, I know that probably should be corrected at http://code.google.com/p/lib3ds/ but I'm assuming that as no commits have happened there since 2011 that it may be better to fix the copy we have in the OSG of that project) The leak is caused by lib3d's use of realloc(ptr, 0) to free up memory allocations, but realloc, when ptr==NULL returns malloc(0) rather than NULL and thus leaks a zero byte allocation. The solution here was to adjust the 'lib3ds_util_reserve_array' function so that it realloc is not used to release a NULL pointer.
The second leak is in ReaderWriter3DS.cpp and arises when any of the created StateSet objects added to the StateSetMap don't subsequently get applied to a Node. The solution here was just to simply use the osg::ref_ptr around the raw StateSet pointer that was used in the locally defined StateSetInfo struct."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14854 16af8721-9629-0410-8352-f15c8da7e697
If OSG_OPENGL_PROFILE="GLES3" =>
GraphicsWindowIOS will create gles3 context.
If failed, GraphicsWindowIOS will create gles2 context.
Multisampling also working.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14831 16af8721-9629-0410-8352-f15c8da7e697
