mix( matrix, matrix, float )

mat /= float and mat *= float are defined for matrices. But its unclear why other component-wise built-in functions like mix aren’t. Seems like they easily could be. Would be useful and shorten shader code.

  mat3  m1 = mat3(1);
  mat3  m2 = mat3(1);
  mat3  m3 = mix( m1, m2, 0.5 );


tst_vert.glsl(100) : error C1115: unable to find compatible overloaded function "mix(mat3, mat3, float)"

mat3  m3;
m3.x = mix( m1.x, m2.x, 0.5 );
m3.y = mix( m1.y, m2.y, 0.5 );
m3.z = mix( m1.z, m2.z, 0.5 );

Focus for most ops (eg sqrt,sin,floor, min) generally is on vectors. Having them also support matrices seems redundant to me. Though interaction of matrices and floats doesn’t seem important enough, either.

Right. It’s not a huge deal. Just noticed while coding up some DQ skinning I had to break out the individual vectors and mix separately, but only for functions not operators.

mat3 m1;
mat3 m2;
mat3 m3 = (m1 * (1.0 - mixfactor)) + (m2 * mixfactor);

Compiles without error for me, should work.


mat3 m1;
mat3 m2;
mat3 m3 = (m1 * (1.0 - mixfactor)) + (m2 * mixfactor);

Compiles without error for me, should work.[/QUOTE]
Definitely an option. And that’s a perfect example of what seems odd to me. The built-in operators all support component-wise operation on matrices, but the built-in functions (that do component-wise operation on vectors) don’t do component-wise operation on matrices. Cg is like that too, so it’s not like GLSL needs to catch-up there. Also, the expression you provide above is the exact definition of mix(), and it works for matrices, …so why shouldn’t mix() “just work” in this case (aside from the language currently precludes it)? Anyway…

Seems odd for sure; HLSL specifies that it’s equivalent (lerp (matrix1, matrix2, factor)) is acceptable too (and has been since SM1 days), so while it’s not a show-stopper it would definitely be nice to clean up the GLSL spec with this.