CID 11812: Uninitialized scalar field (UNINIT_CTOR)
Non-static class member _lastFrameUsed is not initialized in this constructor nor in any functions that it calls.
Non-static class member _s is not initialized in this constructor nor in any functions that it calls.
Non-static class member _t is not initialized in this constructor nor in any functions that it calls.
CID 11813: Uninitialized scalar field (UNINIT_CTOR)
Non-static class member _endian is not initialized in this constructor nor in any functions that it calls.
CID 11814: Uninitialized scalar field (UNINIT_CTOR)
Non-static class member _updateCamera is not initialized in this constructor nor in any functions that it calls.
CID 11820: Uninitialized scalar field (UNINIT_CTOR)
Non-static class member _azAngle is not initialized in this constructor nor in any functions that it calls.
Non-static class member _elevAngle is not initialized in this constructor nor in any functions that it calls.
CID 11819: Uninitialized scalar field (UNINIT_CTOR)
Non-static class member _BoundaryAngle is not initialized in this constructor nor in any functions that it calls.
Non-static class member _planeOrientation is not initialized in this constructor nor in any functions that it calls.
CID 11818: Uninitialized scalar field (UNINIT_CTOR)
Non-static class member _BoundaryAngle is not initialized in this constructor nor in any functions that it calls.
Non-static class member _planeOrientation is not initialized in this constructor nor in any functions that it calls.
CID 11817: Uninitialized scalar field (UNINIT_CTOR)
Non-static class member _distance is not initialized in this constructor nor in any functions that it calls.
CID 11817: Uninitialized scalar field (UNINIT_CTOR)
Non-static class member _distance is not initialized in this constructor nor in any functions that it calls.
CID 11816: Uninitialized scalar field (UNINIT_CTOR)
Non-static class member _leftRightSurfaces is not initialized in this constructor nor in any functions that it calls.
SETUP_EXE, in order to have a unique entry point to build the
libraries. With this changes the android integration will be less
painful (currently is a big IF(ANDROID) for each CMakeLists.txt) and
more maintainable in the future. I hope next submissions will be for
supporting android from my colleague Jorge.
"
(de)allocation going on in OverlayNode::cut().
So instead creating inner-loop variables 'distances' and 'newVertices'
every time, I moved the creation out of the loop and just do a clear() +
reserve() inside the loop. This allows std::vector<> to reuse the old
memory instead allocating new when the new size <= oldsize."
Most notable the __hpux define stuff. The __hpux__ variant seems to be not
defined which resulted in a compile error at this time. Consequently I have
replaced all occurances of __hpux__ with __hpux. And huge surprise: now osg
plugins are found and loaded correctly ...
The next notable one is the MSVC_IDE fix which makes the nmake Makefiles cmake
generator target behave like the ide one. Showed up because I started to do
scripted builds with nmake instead of devenv...
The rest is the usual bunch of stuff that just happens during normal
coding ..."
of these methods in src/osgViewer/Renderer.cpp to make sure that the draw thread keeps references to all in scene graph Cameras
that are being used by the drawing threads, to keep the Camera's alive even when the main thread removes these Cameras from the scene graph.
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")
"
Rotation matrices were replaced with quaternions but incorrect contructor was used. There was a call to Quat(angle, xAxis, yAxis, zAxis ) but there is no such constructor in Quat class to create quaternion for rotation. As a result we got this values being written into quaternion directly.
I've replaced Quat contructor calls with the ones creating rotation quaternions Quat( angle, Vec3( axis ) )."
set.
The optimization is based on the observation that matrix matrix multiplication
with a dense matrix 4x4 is 4^3 Operations whereas multiplication with a
transform, or scale matrix is only 4^2 operations. Which is a gain of a
*FACTOR*4* for these special cases.
The change implements these special cases, provides a unit test for these
implementation and converts uses of the expensiver dense matrix matrix
routine with the specialized versions.
Depending on the transform nodes in the scenegraph this change gives a
noticable improovement.
For example the osgforest code using the MatrixTransform is about 20% slower
than the same codepath using the PositionAttitudeTransform instead of the
MatrixTransform with this patch applied.
If I remember right, the sse type optimizations did *not* provide a factor 4
improovement. Also these changes are totally independent of any cpu or
instruction set architecture. So I would prefer to have this current kind of
change instead of some hand coded and cpu dependent assembly stuff. If we
need that hand tuned stuff, these can go on top of this changes which must
provide than hand optimized additional variants for the specialized versions
to give a even better result in the end.
An other change included here is a change to rotation matrix from quaterion
code. There is a sqrt call which couold be optimized away. Since we divide in
effect by sqrt(length)*sqrt(length) which is just length ...
"
Attached is a fixed version of OverlayNode.cpp. I fixed CustomPolytope::cut( osg::Plane ) method. Bug was apparent in such scenario:
Let P1 be some random frustum polytope
Let P2 be the polytope that was created from P1 bounding box (P2 contains P1 entirely)
Then ignoring precision errors: P1.cut( P2 ) == P2.cut( P1 ) == P1. But this condition was not always met. Cut failed when some of the polytope reference points happened to lie exactly on some intersecting planes in both P1 & P2 (plane distance was = 0).
I only use CustomPolytope for my shadowing stuff so I did not test how this affects rest of OverlayNode.cpp.
----2----
Also attached is a minor precision improvement for osg::Plane intersect method (double version).
----3----
I have also one observation regarding osg::Plane - There are two intersect vertices methods (float and double flavour):
inline int intersect(const std::vector<Vec3>& vertices) const
inline int intersect(const std::vector<Vec3d>& vertices) const
I guess osg::Plane won't compile when someone changes default vec3 typedef to vec3d. Shouldn't the first method be changed to use vec3f explicitly ? Ie:
inline int intersect(const std::vector<Vec3f>& vertices) const"
to bugfixes in osg::Polytope.setToUnitFrustum and setToBoundingBox It was
sent at beginning of december. I read it when purging my Thrash emails and
found it there this because it was wrongly classified as SPAM.
What stroke me in this email was the fact that there was once an error in
Polytope class. Since I adopted CustomPolytope (osgSim OverlayNode.cpp) for
my minimal shadow area computations I checked my code for this error. And I
found it in CustomPolytope::setToUnitFrustum method.
CustomPolytope::setToBoundingBox seemed OK.
So I went back to the origin and fixed this error in OverlayNode.cpp as
well. I have not tested it in OverlayNode though (I don't know how) so
please look at this carefully. But it seems to work fine with my shadow
calculations."
of the OverlayNode.
I change the overlay subgraph dynamically and when I remove all the
subgraph nodes that is inside the current main camera FOV (others
outside still exist), the overlay texture does not update because of the
early return in the traversal. I then get a kind of ghost texture moving
around the terrain.
The attached file fixed the problem for me, but I'm not sure if it is
the best way to address the problem."
