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)
"
Hence, moc will complain when osg throws in a -f without anything after it. Hence I propose removing the -f on Qt5 builds. I have tested building without -f on both qt520 and qt511, and that works well.
The attached src/osgQt/CMakeLists.txt that can be patched into 3.2 safely. For the trunk, I would consider dropping the check on the version, and simply remove the option on qt5. I have tested that on qt5.1.1, and that worked fine. Question is however if it works on qt5.0. Probably it does, so the question is simplicity of CMakeList.txt vs safety."
* force _OPENTHREADS_ATOMIC_USE_BSD_ATOMIC for IOS device + simulator as the test does not pick the right implementation
* fixed a small compile-bug for iphone-example
* added a check to prevent multiple realization of a GraphicsWindowIOS-object
"
I'm not sure if the IVE was simply generated incorrectly, or if the Image::getTotalSizeInBytesIncludingMipmaps() was modified since the file was generated. Either way, I added a simple check in the IVE loader so that it clears the mipmap offsets if the actual data size does not match the computed data size. This seems like a safe fallback since the mipmap data can be automatically generated, and it fixes the problem in my case.
Also, while looking into this issue, I noticed that the osgDB::InputStream class applies the serialized image allocation mode. However, since the serializer is allocating the image data itself, it seems like it should force the allocation mode to USE_NEW_DELETE.
"
