The vtf plugin wasn't working in Windows due to OS differences in the byte-packing of the header structure (on Windows, the big block read was causing a buffer overrun). I fixed this by reading the structure from the file field by field. It's now happy on both Linux and Windows."
- 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."
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."
