indexed draws instead of plain array draws to save some amount of main memory.
Draw performance does not change with the nvidia binary blob as well as with
the open source drivers."
My previous patch for Atomic Counter Uniform provide new template implementation
of Matrix{2,3,4}x{2,3,4}{fd}. This new implementation use Column-Major Matrix.
Original code define matrix as Row-Major matrix like other Matrix in OSG, and
my matrix implementation break compatibility with previous code.
For example osg_normalMatrix define in osg::State report by Roland Hill.
Thanks to Paul Martz to spot me when the bug appear."
Not sure why my system seems to be so sensitive to these problems.
But attached is a fix which seems to stabilise the example.
Note: it only seems to crash intermittently when spinning the object with
your mouse.
So I assume this is a threading issue because of the data variance missing
in some of the text node setups in the example.
"
- add non square matrix
- add double
- add all uniform type available in OpenGL 4.2
- backward compatibility for Matrixd to set/get an float uniform matrix
- update of IVE / Wrapper ReadWriter
implementation of AtomicCounterBuffer based on BufferIndexBinding
add example that use AtomicCounterBuffer and show rendering order of fragments,
original idea from geeks3d.com."
1) they use direct link to texture
-> this is already handle by current plugin : OK
2) they defined colors with only 3 color components
-> it leads to a crash when trying to acces to the fourth component
I fixed that
3) they contain empty primitive lists
-> reading is ok, but osgviewer crashes when trying to display the geometries
The reason is that osg assume that DrawElementsare never empty (blunt acces to DrawElements.front() in PrimitiveSet.cpp)
I corrected this (on the plugin side), but I wonder :
Is it the responsability of plugins to create non empty DrawElements, or of osg core not to crash when they occur ?
If the responsability is on the osg core side, I can submit a patch to PrimitiveSet.cpp regarding that aspect.
4) they use a material binding scheme not supported by the plugin
->I've implemented a mechanism to handle this binding scheme
You will also find in the patch an example of these evil dae and comments on the offending elements.
They seems to be produced by ComputaMaps (www.computamaps.com)
They load well in Google Earth
"
the following error:
Users/stephan/Documents/Projekte/cefix/cefix/ios/../../libs/ios/include/OpenThreads/Atomic:244:48:
error: cannot initialize a parameter of type 'void *' with an lvalue of
type 'const void *const'
return __sync_bool_compare_and_swap(&_ptr, ptrOld, ptrNew);
This can be solved by a cast to '(void*)ptrOld'. This should be benign since both
'ptrOld' and 'ptrNew' are only read and the cast is in fact in place for all other
implementations as well.
On OS X the cast compiles cleanly on both g++ (i686-apple-darwin11-llvm-g++-4.2 (GCC)
4.2.1) and clang++ (Apple clang version 3.1 (tags/Apple/clang-318.0.54)).
"
IF(${CMAKE_OSX_SYSROOT} STREQUAL "/Developer/SDKs/MacOSX10.7.sdk")
...
ELSEIF(${CMAKE_OSX_SYSROOT} STREQUAL "/Developer/SDKs/MacOSX10.5.sdk" OR ${CMAKE_OSX_SYSROOT} STREQUAL "/Developer/SDKs/MacOSX10.6.sdk")
...
ELSEIF(EXISTS /Developer/SDKs/MacOSX10.4u.sdk)
...
ELSE()
...
ENDIF()
Which is fragile because XCode could be installed into another directory than /Developer. (In case XCode is not installed into the /Developer directory CMake can automatically resolve the path via command line utility ${CMAKE_XCODE_SELECT} --print-path)
This issue bites me currently because the latest XCode (Version 4.3.1 - 4E1019) installed through the Mac App Store is per default installed in "/Applications/Xcode.app/Contents/Developer" and hence the 10.7 SDK in "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk"
Searching the web to find the proper way to determine the version of the Platform SDK programmatically, I found no standard way. I came up with 2 options myself:
1) Parse the path string to extract the version number
2) Read a value from the SDKSettings.plist found in the root of each SDK (e.g., "defaults read ${CMAKE_OSX_ROOT}/SDKSettings.plist CanonicalName" gives "macosx10.7")
I implemented the last option and verified that at least the following Mac OS SDKs (10.3.9, 10.4, 10.5, 10.6, 10.7) support this method. It also looks reasonably future proof. An additional benefit of this method is that it also seems to be compatible with iOS and iOS Simulator SDKs (at least for version 5.1, but I assume this also applies to older versions). This is interesting because the CMake infrastructure to build OSG for iOS currently still contains similar hard-coded paths and even requires you to manually change the cmake file to build for another iOS SDK version. In the near future I hope to address these issues, but I haven't been able to try this yet."
viewMatrix.makeLookAt(frustum.center+positionedLight.lightDir*zMin, frustum.center, lightUp);
to
viewMatrix.makeLookAt(frustum.center+positionedLight.lightDir*zMin, frustum.center+positionedLight.lightDir*zMax, lightUp);
The reason I've done such a change is that for huge scenes like a city on the earth, the values of frustum.center can be extremely large, but zMin may be very small (e.g., when model depth in light coords equals the model radius by chance) in some cases so the result of (eye - center) might jiggle while moving around the shadow scene and thus make the shadow map suddenly disappear some time. The small change here also considers the effect of zMax to avoid such problems.
"
I have also made changes to the RotateCylinderDragger to provide a cylinder ring with a thickness. It is totally optional, but IMHO makes the default behavior work better than a solid cylinder (which typically obscures the geometry you are trying to drag). Gives it a bit more to grab, especially in the case where eyepoint and cylinder axis are near parallel.
"
