- using m.getPerspective( fovy, tmp, tmp, tmp ) to get only FOV does not work.
The reason is that getPerspective is taking tmp as reference - thus all the three variables points to the same memory location. Then, zNear (third parameter) is used inside the method, while zNear content was spoiled by zFar that was written to the same place, resulting in fovy set to nan. I consider that it is the right of programmers to use 3 times tmp as parameter and I fixed the code in the method. I have done the same for getFrustum and getLookAt.
- I fixed makeFrustum to accept infinite zFar. (Some graphics techniques like shadow volumes require placing zFar to infinity to avoid visual artifacts.)"
Note from Robert Osfield, change the local near & far variable names to temp_near and temp_far MS Visual Studio has a record of using near and far names.
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 ...
"
Note that firstly it always returns the positive real quaternion (positive w)
Note also that it will sometimes slightly differ from the results of the other methods because it assumes that the input matrix really is a rotation matrix - if it isn't, e.g. because of rounding error, then the output quaternion will be very slightly different. For example, the test matrix
0 1 0 0
1 0 0 0
0 0 0.999999 0
0 0 0 1
will return 0.707107 0.707107 0.0005033 0.0005033
whereas the previous methods return 0.707107 0.707107 0.0 0.0
However, since quaternions are rotations, the meaning of how to convert a matrix that isn't a rotation is a little unclear..."
change of ' ' to GUIEventAdapter::KEY_Space, fix to url in Matrix_implementation.cpp.
Syntax fixes by Robert Osfield to above submission fix inconsistencies with normal
OSG coding style.
matrixd. It was returning the values of the diagonal
of the matrix, which only returns the scale if there
is not a rotation. I fixed this by returning the
length of the vectors that form the basis.
I also added a function to orthonormalize the
rotation component of the matrix. I seem to always run
into situations where non uniform (or even uniform)
scale complicate my calculations, and I thought other
members of the community could use this function as
well."
