databasePager->setUpThreads(16, 1);
We experienced problems with multiple databasepagers loading files in parallel, when two threads start to load the same file (usually a texture referenced by multiple models). The second thread to add the file to the cache (sometimes) manages to do so while the refcount from the cached object still is zero, causing the object loaded to be destroyed.
Sometimes the second thread manages to ref() the object before Referenced::signalObserversAndDelete does the final recount check, causing a warning:
"Warning Referenced::signalObserversAndDelete(,,) doing delete with _refCount=1"
With a deleted object added to the scenegraph we get some undesired results, I think the program only crashes if the object was a Node, and just has some untextured surfaces if it was a texture, but I'm not completely sure.
Attached is a modified version of the Registry.cpp, returning the object in cache and let the duplicate loaded object to be destroyed.
A more efficient option would be to add some sort of blocking entry to the objectcache to stop the second thread from reading the file, and just wait until the first thread added it to the cache. If you think that's worthwile we would be happy to implement that version. A bit tricky to implement and test, that's why I submit a simple version that stops my program from crashing.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/branches/OpenSceneGraph-3.2@14299 16af8721-9629-0410-8352-f15c8da7e697
"I noticed that Text3D objects would change there z alignment depending on the alignment mode. I'm not sure if this was intentional or just a simple mistake. My expectation was that the front of the object would always stay aligned to the 0 z-plane, regardless of the alignment mode. I've attached an updated version that retains a consistent z-alignment."
"I just now noticed another issue with Text3D objects. It was not properly computing the bounding box when non-axis aligned rotations were being applied. In this case all corners of the bounding box need to be transformed in order to get the correct containing box. I've attached the updated file."
"The incorrect bounding box problem also applies to regular Text objects. I've attached the fix for that as well as the original Text3D fix."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/branches/OpenSceneGraph-3.2@14295 16af8721-9629-0410-8352-f15c8da7e697
From Robert Osfield, add check to only apply Options object when a valid Option object is assigned.
src\osgPlugins\ive\ImageSequence.cpp
src\osgWrappers\deprecated-dotosg\osg\ImageSequence.cpp
src\osgWrappers\serializers\osg\ImageSequence.cpp"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/branches/OpenSceneGraph-3.2@14291 16af8721-9629-0410-8352-f15c8da7e697
debug message it prints out on the console.
Around line 1040 of Registry.cpp (see code below) the method returns
"simpleFileName" but prints about returning "filename".
In attachment the modified file, based on osg 3.2.0
ricky
<code>
if(fileExists(simpleFileName))
{
OSG_DEBUG << "FindFileInPath(" << filename << "): returning " <<
filename << std::endl;
return simpleFileName;
}
</code>
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/branches/OpenSceneGraph-3.2@14284 16af8721-9629-0410-8352-f15c8da7e697
We were running into issues occasionally in osgEarth where multiple threads were writing out files like /1/2/3.jpg and /1/3/4.jpg. Both threads would try to create the /1 directory and only one of them would succeed. So the first thread would write out the full /1/2/3.jpg while the second thread wouldn't create the /1/3 directory b/c /1 was already created and the writing of /1/3/4.jpg would fail.
"
format. Turned out that the serializer didn't handle bone names with
spaces very well (the 3ds studio max biped for instance has spaces by
default). Here is a small fix for the problem."
- materialName used to be not stripped of whitespace, making number of models
fail to load materials; now fixed
- stripping was considering spaces only, thus models using tabs had problems
to load correctly; fixed
- fixed references to textures; they did not performed conversion to native
directory separators
- make d (dissolve) takes precedence over Tr (transparency); there seems to be
a confusion about the Tr item - some claiming 1 to be opaque and 0
transparent, while number of models uses exactly the opposite. d (dissolve),
if present in the model, does not suffer from this confusion, thus using it
instead fixes the problem for many many models.
I put many comments to the file concerning d and Tr item as others may further
investigate. Let me know in the case of any problems."
This behavior is also described in the pthreads man page (http://man7.org/linux/man-pages/man3/pthread_create.3.html):
>
> Linux-specific details
> The new thread inherits copies of the calling thread's capability
> sets (see capabilities(7)) and CPU affinity mask (see
> sched_setaffinity(2)).
>
To prevent this behaviour I wrote a patch that explicitly sets the affinity mask to all cores of the system, if no specific affinity was defined with PThread::setProcessorAffinity(unsigned int) .
Thank you!
"
There are two problems:
1> for DrawElementsUShortPrimitiveType (and UInt) the source_pindex still equals -1 and causes a crash
in DrawElementsUBytePrimitiveType source_pindex is incremented, and in DrawElementsU(Short/Int)PrimitiveType primitiveNum is incremented, but never used
2> The drawelements need to be rewritten as the vertices are reordered.
created a patch for osg stable branch(r14038): attached as Geometry-osg-3.2.zip
and for svn brach(r14044): attached as Geometry_osg_svn.zip"
This can lead to inconsistency if you bind a framebuffer with multiple attachments in DRAW mode and then a framebuffer with different attachment count in READ mode (for example to manually "blit" from a FBo to another).
On some ATI cards (at least RADEON HD) this also leads to an "incomplete " FBO status
I've added a test to enable drawbuffers only if target is "DRAW" or "READ_DRAW", this solves my problems on ATI cards."
I have tested this on:
mac/qt5.2
linux/qt5.2
windows/qt5.2, and
mac/qt5.1
All platforms perform as expected.
The previous fix removed the -f flag to the moc-pre-processor, but on windows, it turned out that -f "osgQt/QGraphicsViewer" was needed.
This becomes an include-statement in the file generated by moc which is needed for compiling it. I ask you consider this patch for the trunk and the 3.2 branch.
Secondly, I wonder if it would be possible to apply my patch for FindRSVG.cmake from 22nd November in the 3.2 branch.
In short, the version of librsvg must be equal or higher to 2.35:
PKG_CHECK_MODULES(RSVG librsvg-2.0>=2.35)
"
