order, and not in the order they are listed in the constructor. To
avoid possible trouble, gcc warns about this. Attached modification
fixes the initializer order to silence this warning."
Also, there was also a small bug in osgDB's CMakeLists.txt that was causing an error when I tested with CMake 2.4.4.
IF(${OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX} STREQUAL "quicktime")
was changed to
IF(OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX STREQUAL "quicktime")
"
Very simple cases of state configuration are supported (all the ones I really need):
- single per pixel not attenuated non spot light source ON/OFF
- exp2 fog ON/OFF
- diffuse texture in rgb + optional specular gloss in alpha (Texture unit 0) ON/OFF
- normal map texture (Texture unit 1 and Tangent in VertexAttribArray 6) ON/OFF
- blending and alpha testing (not in shader pipeline)
To view fixed function pipeline files and paged databases simply run >osgshadergen myfile.osg"
the filename extension is "vert" or "frag" but still lets this be
overridden by the Options (for those crazy people who store their
fragment shaders in .vert files :) )."
ADD_LIBRARY(${TARGET_TARGETNAME} MODULE ${TARGET_SRC} ${TARGET_H})
which gives them .so extensions. Since ".so" != ".dylib" osgDB::listAllAvailablePlugins finds no plug-ins. I believe the correct solution is to use CMAKE_SHARED_MODULE_SUFFIX instead. This builds and runs correctly on OS X but I have not tested on other platforms.
Attached is an updated src/osgDB/CMakeLists.txt based on rev 9915. The change is at line 108. To validate: build and then run bin/osgconv --formats. You should get many screenfuls of plug-in features, extensions and options."
In my example case, there are 2 threads - one is a worker thread created by OpenThreads::Thread. The other thread is the main thread i.e. the thread that is intrinsically created when you execute the application. The crucial problem is that for the main thread, OpenThreads::Thread::CurrentThread() will return null.
I'll demonstrate this by breaking ReentrantMutex::lock() into sub-statements:
1.) if (_threadHoldingMutex==OpenThreads::Thread::CurrentThread())
2.) if (_lockCount>0){
3.)
OpenThreads::ScopedLock<OpenThreads::Mutex> lock(_lockCountMutex);
++_lockCount;
return 0;
4.)
int result = Mutex::lock();
if (result==0)
{
OpenThreads::ScopedLock<OpenThreads::Mutex> lock(_lockCountMutex);
5.)
_threadHoldingMutex = OpenThreads::Thread::CurrentThread();
_lockCount = 1;
return result;
An error will occur in the following case:
1) The worker thread calls lock(), it gets to the start of statement 5.
2) The main thread calls lock(). Statement 1 is evaluated as true as _threadHoldingMutex is null, and OpenThreads::Thread::CurrentThread() returns null.
3) The worker thread executes statement 5.
4) The main thread executes statement 2 and evaluates it as true, because the worker thread has set _lockCount to 1. The main thread executes statement 3, and now can access the mutexed-data at the same time as the worker thread!
The simple solution to this is to always protect access to _lockCount and _threadHoldingMutex using _lockCountMutex. I have done this in the file I am submitting."
Added handling of Image::getPixelAspectRatio() in geometry sizing.
Added scaling of the projection matrix to ensure that aspect ratio is honoured with running in fullscreen mode
1. Makes IF/ELSE/ENDIF code blocks easier to read by replacing code like this:
IF(FOO)
MESSAGE("FOO is true")
ELSE(FOO)
MESSAGE(" ??? ELSE(FOO)??? ")
ENDIF(FOO)
with this:
IF(FOO)
MESSAGE("FOO is true")
ELSE()
MESSAGE("FOO is clearly false")
ENDIF()
2. Also adds an ELSEIF() where it makes sense to do so (safe to use as of CMake 2.4.4)"
At the company where I work we model literally thousands of 3DS models for all types of objects. Most don't have transparent textures applied to them, but a few do. The issue is that a texture may have an alpha channel defined, yet its 3DS material definition is not marked as being an alpha source, or transparent. This can happen for any number of modelling reasons (so I'm told) but the net effect is that when a 3DS object is loaded with such a material applied, the stateset creation for the 3DS geometry omits to add the GL_BLEND attribute as neither of the conditions that it currently tests for are satisfied under this scenario.
However, one thing that is apparently an indication of transparency/alpha information that we do make use of when modelling, but that the 3DS reader omits to test, is that we assign to the transparent texture to the opacity_map of the 3DS material structure.
Now, having discussed with our modellers the theory behind the opacity map, it seems that it is safe to say that if an opacity map is specified, then the reader should really apply the GL_BLEND attribute as it is an indication of some form of blending being required between materials.
With this in mind, I have made a minor change to the function createStateSet below, from the ReaderWriter3DS.cpp file, that checks for an opacity map having been specified, and in such a scenario the GL_BLEND attribute is applied to the geometry. This fixed our issue, and thought it might be helpful to others."
When 2 geometries are merged, the primitive sets of the second geometry
are copied to the first geometry.
The primitive sets were copied with a std::insert into the first geometry
primitive set vector. It doesn't work when the geometry is using VBOs (because
the element buffer object of the primitive set is not updated).
The correction replaces
lhs.getPrimitiveSetList().insert( lhs.getPrimitiveSetList().end(),
rhs.getPrimitiveSetList().begin(),
rhs.getPrimitiveSetList().end() );
by
for( primItr=rhs.getPrimitiveSetList().begin();
primItr!=rhs.getPrimitiveSetList().end();
++primItr )
{
lhs.addPrimitiveSet(primItr->get());
}"
