talking about in the LIB_POSTFIX thread. It is a bit verbose perhaps
and the message I emit during the make install step flashes by and
gets burried under all "installing..." and/or "up-to-date..."
messages. I have posted on the cmake mail list on ways to do this
better.
The submission adds:
* message to user during configuration that s/he's eventually going o
install to ${CMAKE_INSTALL_PREFIX}lib${LIB_POSTFIX}
* if system has /etc/ld.so.conf.d and it is a dir generates
packaging/ld.so.conf.d/openscenegraph.conf and creates a custom target
for installing it (target must be run explicitly of course). User is
notified of this during configuration (may not be necessary)
* emit a message during installation that libraries are put in
<same-as-above>. This message unfortunately gets emitted to soon for
the user to see it
* I added "COMPONENT libopenscenegraph-dev" to the pkgconfig.pc's
install command
* Moved the section with OSG_CONFIG_HAS_BEEN_RUN_BEFORE as close to
the end of CMakeLists.txt as I dared. This is the intent of this
construct I think."
- The text and dark background rectangles are now correctly placed, and
slightly resized here and there.
- All counters (vertices, etc) now use a fixed formatting with 0 digits
precision, to prevent the text from being shown in scientific notation
when the number get large (e.g. 6.34344e+6). I tested with a scene
containing roughly 4 million vertices, to make sure its stats would
display correctly.
I also made slight changes to osgcompositeviewer (attached) to aid in
testing the stats display, specifically displaying of camera and view
names."
circumstances under which this bug occur are rather specific, but the
basic problem occurs when one translation unit other than libosg.so
constructs an object that is a subclass of osg::Shape and another
translation unit other than libosg.so tries to perform a dynamic_cast or
other RTTI-based operation on that object. Under these circumstances,
the RTTI operation will fail. In my case, the translation units involved
were an application and osgdb_ive.so. The application constructed a
scene graph that included instantiations of subclasses of osg::Shape.
Depending on how the user ran the application, it would write the scene
graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast
operations in DataOutputStream::writeShape() would fail on the first
subclass of osg::Shape that was encountered. This is because there were
two different RTTI data objects for all osg::Shape subclasses being
compared: one in the application and one in osgdb_ive.so.
The fix for this is simple. We must ensure that at least one member
function of each of the subclasses of the polymorphic type osg::Shape is
compiled into libosg.so so that there is exactly one RTTI object for
that type in libosg.so. Then, all code linking against libosg.so will
use that single RTTI object. The following message from a list archive
sort of explains the issue and the solution:
http://aspn.activestate.com/ASPN/Mail/Message/1688156
While the posting has to do with Boost.Python, the problem applies to
C++ libraries in general."
openscenegraph.pc and openthreads.pc files with OSG's installation values.
Then I install those files into the expected path for pkg-config (this can
also be modified through PKG_CONFIG_PATH environment variable). Therefore
those of us who are using pkg-config for linking can easily select which
version of OSG we want to use."
openscenegraph.pc and openthreads.pc files with OSG's installation values.
Then I install those files into the expected path for pkg-config (this can
also be modified through PKG_CONFIG_PATH environment variable). Therefore
those of us who are using pkg-config for linking can easily select which
version of OSG we want to use."
The fix was to convert the osg::State to use C pointers for the set of applied PerContexProgram objects, and use the osg::Oberver mechanism to avoid dangling pointers for being maintained in osg::State.
working with that thing.
This is what was missing so far:
Make win32 threads behave like the posix implementation when setting thread
cpu affinity. That includes avoid setting thread affininty on a non running
thread. Set that once it is running."
osgVolume/Property
added OSGVOLUME_EXPORT to PropertyAdjustmentCallback
osgVolume/VolumeTile.cpp
in copy constructor, removed ';' on if (volumeTile.getVolumeTechnique())"
examples/osganimationviewer/AnimtkViewer.cpp:
- add option to display bone (--drawbone)
- dont crash if the file does not contains a AnimationManagerBase, display the content only
examples/osganimationviewer/AnimtkViewerGUI.cpp:
- adjust the path of image for the gui
include/osgAnimation/Interpolator:
- add warn message instead of old assert
include/osgAnimation/Bone:
src/osgAnimation/Skeleton.cpp:
- change a method name to fit better with what it does. setMatrixInSkeletonSpace instead of setBoneInSkeletonSpace
include/osgAnimation/Skinning:
src/osgAnimation/RigGeometry.cpp:
- add patch from Fabien Lavignotte to compute normal correctly
include/osgAnimation/Sampler:
- adjust behviour without assert, return 0 instead of crashing
"
1. Support for ambient occlusion maps.
2. A fix for the incorrect handling of normals on all geometries. The optimizer usually fixed this bug so it probably was not noticed very often.
3. A new option flag on the reader. "StrictTransparency"
// Process transparent and transparency settings according to a strict interpretation of the spec
// See https://collada.org/public_forum/viewtopic.php?f=12&t=1210
otherwise
// Jump through various hoops to accomodate the multiplicity of different ways
// that various people have interpreted the specification
4. Handling of texures in the transparent channel. This is allowed provided that they are the same texture that is specified in the diffuse channel. Accomodating a different texture would require use of programmable pipeline functionality which I have tried to avoid.
5. Handling of <bind_vertex_input> elements.
""
name of the top folder in each package to OpenSceneGraph-x.y.z
Noone else has had an opinion on whether compiler and it's version
should be part of the package filename on their platform/setup so I'll
leave it as is. That is - No action is taken for compilers other than
msvc but one can easily add this information to the cmake cache
regardless of platform.
"
The code works fine as is if the format plugin is not already loaded in memory.
If a plugin is already in memory, say the PNG plugin for example, then a call to readImageFile("http://server.com/image.png") will return FILE_NOT_FOUND because osgDB::findDataFile will not be able to locate the file. So the Registry::read method is returning before the CURL plugin is given a chance to download the file.
I've made a few changes to the Registry to not return FILE_NOT_FOUND if the filename contains a URL that fix the issue."
