I want to take several transformation matrices and average them out into a new orthogonal matrix (i.e. all 3 sides perpendicular). I tried the following, but the resulting scale values do not come even.
fn getAvgMatrix matrixArray =
(
avgMatrix = (matrix3 [0,0,0] [0,0,0] [0,0,0] [0,0,0])
for m in matrixArray do avgMatrix = avgMatrix + m
for t = 1 to 4 do avgMatrix[t] = avgMatrix[t] / matrixArray.count
avgMatrix
)
The easiest way I found to test this visually is to create several plane objects with various rotations, and use
p = plane()
p.transform = getAvgMatrix #($Plane01.transform, $Plane02.transform, ...etc)
I admit that I have never really been good with matrices. Hopefully someone can tell me what I’m doing wrong and how to fix it.
couple weeks ago I posted “blend two matrices” function.
fn dotQuat q q_prev =
(
(q.w * q_prev.w + q.x * q_prev.x + q.y * q_prev.y + q.z * q_prev.z) < 0
)
fn blendMatrix m1: m2: weight:0.5 =
(
r1 = m1.rotationpart
r2 = m2.rotationpart
if (dotQuat r1 r2) do r1 *=-1
r = slerp (normalize r1) (normalize r2) weight
t = m1.translationpart + (m2.translationpart - m1.translationpart) * weight
s = m1.scalepart
translate (rotate (scale (matrix3 1) s true) r) t -- ignores scale
)
an averaging of positions does make sense but the averaging of rotations doesn’t. It’s only way to average them is to define your own rule how to blend multiple matrices.
Hi, thanks for that, I’ll give it a try!
I was just working on a similar but unrelated script and found another solution, which is is to get the normals of each of the matrices, average those out, and then use those normals to build a new matrix. It seems to do what I need. I’ll play around with it a bit more and post here if I discover anything interesting.
That is how I did it. Use the four vectors and average them to build the new. Make sure that you are normalizing the vectors as you go.
what is the function for the averaging matrices? is it something like:
fn averageMatrix m1: m2: =
(
row1 = (m1[1] + m2[1])/2
row2 = (m1[2] + m2[2])/2
row3 = (m1[3] + m2[3])/2
row4 = (m1[4] + m2[4])/2
matrix3 row1 row2 row3 row4
)
?
what has to be normalized?
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.
fn averageMatrix m1: m2: =
(
row1 = normalize ((m1[1] + m2[1])/2)
row2 = normalize ((m1[2] + m2[2])/2)
row3 = normalize ((m1[3] + m2[3])/2)
row4 = (m1[4] + m2[4])/2
matrix3 row1 row2 row3 row4
)
EDIT: and of course you need to check for degenerate normals by ensuring that the length of (m1[i] + m2[i]) is greater than some suitably small value.
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++.
why slerp and distance are slow? 100000 operations takes 0.2 sec on my machine. Is it slow?
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.
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.
.biddle