---------------------------
function FltExportVisitor::writeExternalReference( const osg::ProxyNode& proxy ):
Line 423 in file expPrimaryRecords.cpp has to be changed from
const ParentPools* pp = static_cast<const ParentPools*>(proxy.getUserData() );
to
const ParentPools* pp = dynamic_cast<const ParentPools*>(proxy.getUserData() );
"
The semantic change that went into the ac loader with the past patch was
incorrect wrt the document describing the behaviour of ac files and
inconsistent with what ac3d itself displays for that files.
This attached change reverts the behaviour to the original one. The
infrastructure to change this is left in place.
The change is based on rev 9045."
"
and a later post the same osg-submissions thread:
"it's been a while since I have made the changes but I think it was due to problems with static builds of OpenThreads on windows. I was using
OpenThreads in a communication/synchronisation library (without
OpenSceneGraph). It seems I forgot to post a small change in the CMakeLists file of OpenThreads. If a user turns DYNAMIC_OPENTHREADS to OFF (static build) OT_LIBRARY_STATIC will be defined in the Config.
Without these changes a windows user will always end up with a "__declspec(dllexport)" or "__declspec(dllimport)" which is a problem for static builds."
And another post from Blasius on this topic:
"I tested with VS2005 and VS2008. For 32 bit everything works as expected. For x64 and VS2008 I could successfully do the cmake-configure and then the compilation but I had occasional crashes of cmTryCompileExec.exe (during the cmake-configure phase) which seems to be a cmake bug. With VS2005 and 64bit cmake does not set _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED although the interlocked functionality should be there. If I place the source snippet from the CHECK_CXX_SOURCE_RUNS macro to a separate sourcefile I can compile and run the resulting executable successfully. Forcing OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED (on VS2005/x64) reveals a bug in "intrin.h" which seems to be fixed in VS2008 but not in VS2005.
In case anyone is interested the lines:
__MACHINEI(unsigned char _interlockedbittestandset(long *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64 *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 *a, __int64 b))
should be changed to:
__MACHINEI(unsigned char _interlockedbittestandset(long volatile *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long volatile *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64 volatile *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 volatile *a, __int64 b))
The worst thing that can happen is that interlocked funtionality is not detected during cmake-configure and the mutex fallback is used.
Which reminds me another small glitch in the Atomic header so I attached a corrected version.
Why is the OT_LIBRARY_STATIC added to the config file? It is not needed anywhere.
OT_LIBRARY_STATIC is needed if you are doing static-builds on Windows. See my previous post on that.
"
- Matrix transform nodes were stripped out, and the
vertices and normals of each node were
transposed by the modelling matrix. My change preserves
the matrix transform nodes, so that
models can still be articulated by changing the matrices.
- Lights were copied from the COIN scenegraph to the OSG
scenegraph, but they were not associated
with a LightSource node. My change for this creates a
Group and adds a LightSource for each Light.
- If VRML textures have names, the name is now copied to
--
Form Robert Osfild, changed SbString to std::string usage
M Inventor/ConvertFromInventor.h
M Inventor/ConvertFromInventor.cpp
a capping the number of PagedLOD to a sepcified maximum, with pruning of inactive
PagedLOD when the total number of inactive and active PagedLOD goes above the maximum.
To enable the mode set the env var OSG_MAX_PAGEDLOD to a value something like 1000.
support. While testing the pluggin we found a small bug and we are
submitting a patch.
The first attachment is a small program that creates a scene with two
pyramids, transformed by two instances of
osg::PositionAttitudeTransform. One of them is rotated 90 degrees in
the X axis, and the scene is exported both in the native OSG (.osg)
and COLLADA (.dae) formats. In the first case the rotated pyramid is
displayed correctly whereas in the second the pyramid seems not to be
rotated.
In the COLLADA 1.4.1 specification (found at
http://www.khronos.org/collada/) it is specified that
"The <rotate> element contains a list of four floating-point values
[...] followed by an angle in degrees" but the plugin seems to write
the value in radians.
The problem seems to be in the method daeWriter::apply() that seems to
be writing the angle value in radians to the COLLADA file. The patch
can be found in the second attachment and is simply a call to
RadiansToDegrees wrapped around the angle.
"
It assumes that inverse(_inverseMatrix * _offset) = _offset * _matrix
This is only true when _offset=identity, so I think it should be inverse(_offset) * _matrix
This inconsistency can cause problems when switching from UFO to other manipulators, because the UFO:Manipulator::getMatrix function is not necessarily returning a correct inverse of the currently set ModelViewTransform.
It was tempting to change the name of the _offset member to _inverseOffset, or to maintain both variables, but in the end went for the minimal change."
If a 400 level error occurs, a FILE_NOT_FOUND ReadResult is appropriate.
If a 500 level error occurs (such a 503, Service unavailable), the application might want to try to load the file again in a few seconds/minutes. This submission returns ERROR_IN_READING_FILE if a 500 level error occurs so that clients can easily distinguish between the errors.
The actual error code is also added to the "message" of the ReadResult so if a client needs more information, they can just parse the message to retrieve the error code."
The graph is displayed "under" (behind) the normal bar chart you get when you press 's' twice. It doesn't hide the normal stats, you can still read them without any trouble, and that way, it doesn't take any more screen space. It starts from the left, and will scroll left when there is enough data to fill the screen width. The graph lines have the same colors we're used to (except I made the event color a bit bluer, so it's not exactly the same as the update color). A screen shot is attached.
The lines get a bit confused when they're all overlapping at the bottom of the graph, but I think that's the least of our concerns (if they're all at the bottom of the graph - except FPS of course - then great!).
The only thing I'm not very keen about is that to make things simple, I clamp the values to a given maximum. Right now, the maximums I have set are:
* Frame rate: 100 fps (people have 60, 75, 85Hz refresh rates, so there's no one right value, but I think 100 is OK)
* Stats: 0.016 seconds (what you need to get 60Hz minimum)
This could be changed so that the scale of the graph changes according to the maximum value in the last screenful of the graph instead of clamping values. We would then need to display the scale for each value on the side of the graph, because if the scale changes, you need to know what it is at this moment.
I tried to make things easy to change, so for example if you don't like that the graph is in the same space as the normal stats bars, it's easy to move it anywhere else, and make it have other dimensions. The maximums and colors are also easy to change.
The impact on performance should be minimal, since it's one vertex per graph line that's added per frame, and vertices are removed when they scroll off the screen, so you'll never have more than say 1280 * (3 + ncameras) vertices on the screen at one time. No polygons, I used line strips. The scrolling is done with a MatrixTransform."
