It would also be interested to see what the speed difference is from what Denis has to just averaging the vectors as operations like slerp are known to be slow. Test both and see what speed differences you get.

Note that what should be faster isn’t always. Add, subtract, multiply and divide are done in Max script where a function is done in C++. For instance I wanted a faster solution to calculating the Distance function that is using square root and should be slow. So in Max script I wrote what is call a taxi cab distance it isn’t as accurate but if you only need to compare distances it should be faster then using the true Distance. How ever because the math was being done in Max script it turned out to be far slower then the Distance function that is written in C++.

Just as far as Math functions go they would be slower then others. Like I said, that is relative to other operations in Max Script how ever and they could be faster then just adding in MXS.

I think what denisT might be implying is that he can’t envision a situation in which the tiny difference in speed between the two methods would become a practical concern.

As for myself, I came by the normal-averaging method more or less accidentally, and simply found it an easier process to visualize and understand.

could you please using the normal-averaging method average these two matrices and show how you do it?
matrix3 [-1,0,0] [0,1,0] [0,0,-1] [0,0,0]
matrix3 [1,0,0] [0,1,0] [0,0,1] [0,0,0]

Blending matrices by linearly interpreting the basis vectors is not accurate for any weighting other than 50%.

In a nutshell you are interpolating along the line between two points on the unit sphere and then projecting the interpolated point out to the surface of the sphere (when you re-normalize) --instead of interpolating along the arc of sphere between the points.

The key is to linearly interpolate the angular difference between the two rotations, not a line that connects the endpoints of unit vectors that are separated by that angle.

While the interpolated point moves at a constant (linear) rate along the line between the points (this point actually lies in the interior of the sphere) the resulting projection doesn’t move at a constant rate across the surface of the sphere.

Doing this 3 times (once for each axis) will cause distortion of your basis vectors and result in a matrix that is no longer orthonormal – and orthonormalizing a matrix is something to avoid if at all possible!

So if you need anything other than an exact 50/50 (‘average’) blend you’ll need to do it the way Denis suggested. 50/50 works because the projection onto the unit sphere of the midpoint of the line between the points is also the midpoint of the arc connecting the points.

If you are at all worried about speed then maintain the quat for each matrix so that you don’t have to continually call rotationpart() and recreate it just to slerp it.

I’m sure there must be a good diagram of this situation out there for the googling.

Ya something like that. Mine did a loop through any number of transforms to get the solution. Each vector needs to be normalized I find or you get small errors popping up.

The rotation portion of the matrix (first three rows) must be normalized, otherwise the scale will be off.

This average trick only works when both incoming matrices are orthonormal (ie. first three rows define vectors that are each of unit length and are all at right angles to each other)

You cannot get the correct average this way if the transforms are scaled.

A more ‘complete’ solution, where memory is traded for speed, would store the matrix too (and perhaps maintain it’s inverse too, if you find that you are inverting it a lot)

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.