Hi Benoit, yep v*=m too. Thinking about this and Id rather quaternions be changed too, mainly because I'd rather not have them work differently to matrices. Consider both a 3x3 matrix and a quaternion often represent rotation which may be applied to a vector -
If we keep quat's as-is you'd need to reverse the multiplication order to apply this rotation, which adds unnecessary confusion. >>> m * v >>> v * m.to_quaternion() I think this can be done at the same time as matrix deprecation without adding much extra hassles. On Sat, Jul 23, 2011 at 10:12 PM, Benoit Bolsee <benoit.bol...@online.be> wrote: > Hi Campbell, > > I agree on your depracation plan. Note that you should also deprecate > the in-place multiplication v*=m and replace it in 2.6 by the correct > result. > > Regarding the quaternions product, looking at mathutil code I see that > vec*qt is defined as applying the rotation coded inside the quaternion > to the vector. This operation is defined mathematically as Q*v*Q^-1, > where * is the ordinary multiplication given that v is expressed in the > quaternion base (i,j,k) as xi+yj+zk. So the mathutil expression v*Q only > a shortcut and I don't have a preference for the order. Better not > change it. > > @Wim: I totally agree with your math. When talking about a matrix (4x4), > the first 4 is the number of rows and the second 4 the number of > columns, so the valid product (4x4)x(4x1) indicates that a column vector > can only be on the right side of the matrix and the resulting vector is > made of dot products of the vector with rows of the matrix. My point is > that in Blender today, you get that result with the expression v*m, with > is the opposite order of the convention. The multiplication (1x4)x(4x4) > is perfectly valid and leads to a vector that is made of dot products of > the vector with columns of the matrix. Today this operation is not > possible with Blender, and it will be introduced in 2.6 as per Campbell > deprecation plan. > > Again, all the confusion about this order issue is coming from the fact > that mathutil matrices are column major (this decision was taken because > of openGL and Blender internals). So you when print a matrix is Blender, > the columns are printed horizontally, which is confusing. > > /Benoit > > On Fri, 22 Jul 2011 20:35:24 +1000, Campbell Barton > <ideasma...@gmail.com> wrote: >> >> Benoit, should we should apply this logic to quaternions too? >> (use Quaternion*Vector instead) Couldn't find which order is >> correct from looking online. >> >> On Fri, Jul 22, 2011 at 8:06 PM, Campbell Barton >> <ideasma...@gmail.com> wrote: >> > Thank for looking into this Benoit, >> > >> > This is not something I am knowledgeable on with so, taking you're >> > word that "vec * matrix" is wrong (why didn't anyone notice >> this???), >> > heres the upgrade path Sergy and I have agreed on that will >> not break >> > scripts. >> > >> > 1) deprecate "vec * matrix" immediately. print a warning which >> > includes the python line number, add support for "mat * vec". >> > >> > 2) after some weeks/months, drop support for "vec * >> matrix", print an >> > error instead, to ensure scripts are not using it and its >> developers >> > ignoring the warning. >> > >> > 3) for 2.60 release, add in "vec * matrix" which works >> correctly and >> > not like it does currently, leaving enough time that >> scripts from 2.58 >> > will have time to switch the multiplication order. >> > >> > On Fri, Jul 22, 2011 at 7:09 PM, Benoit Bolsee >> > <benoit.bol...@online.be> wrote: >> >> Hi, >> >> >> >> I changed the Matrix multiplication order beween 2.49 and >> 2.5 because >> >> it was simply incorrect in 2.49, in the sense that it was not >> >> matching the way you write matrix math on paper. >> >> >> >> In your example, >> >> >> >>>>> print (m1 * m2) >> >> Matrix((0.0, 0.0, 1.0, 0.0), >> >> (-1.0, 0.0, 0.0, 0.0), >> >> (0.0, -1.0, 0.0, 0.0), >> >> (0.62, 0.1, -0.05, 1.0)) >> >> >> >> is actually the correct answer if you remember that the matrix are >> >> column major. The order should not be changed again. I see >> Campbell >> >> reverted the patch, so that's ok. >> >> >> >> @Campbell: the reason why numpy returns a different result than >> >> Blender is because numpy matrix are row-major by default. The fact >> >> that Blender uses column major matrix may be confusing when the >> >> matrix is printed (columns are printed horizontally) but it's very >> >> convenient to extract vectors from the matrix (e.g. the position >> >> vector). >> >> >> >> While playing around I found something else that still >> doesn't work: >> >> in the scientific literature, vectors are single column >> matrix, this >> >> means that the only correct way to multiply a vector with >> a matrix is >> >> to put it on the right side of the matrix: v2 = m1 * v1 >> >> However, this doesn't work in Blender >> >> >> >>>>> m >> >> Matrix((1.0, 0.0, 0.0, 0.0), >> >> ? ? ? (0.0, 1.0, 0.0, 0.0), >> >> ? ? ? (1.0, 0.0, -1.0, 0.0), >> >> ? ? ? (0.0, 0.0, 0.0, 1.0)) >> >> >> >>>>> v >> >> Vector((0.5, 0.0, 0.5, 1.0)) >> >> >> >>>>> m*v >> >> Traceback (most recent call last): >> >> ?File "<blender_console>", line 1, in <module> >> >> TypeError: Matrix multiplication: not supported between >> >> 'mathutils.Matrix' and 'mathutils.Vector' types >> >> >> >> But the reverse expression gives the correct result (i.e >> the result >> >> of m >> >> * v) >> >> >> >>>>> v*m >> >> Vector((1.0, 0.0, -0.5, 1.0)) >> >> >> >> which is illogical and should be fixed. Note that this >> incorrect form >> >> has one benefit: it allows the use the shortcut expression >> "v*=m" to >> >> apply a transformation matrix on a vector. >> >> >> >> I pretty certain that I set the matrix*vector multiplication order >> >> correct at the same time I fixed the matrix*matrix multiplication >> >> order, so I don't know where this new error is coming >> from. Note that >> >> v*m is an acceptable expression if one considers that it >> turns v into >> >> a row vector, but then the result of the multiplication is >> different >> >> of course. In 2.49 it was possible to use both expressions m*v and >> >> v*m and they were producing different results, except that >> there were >> >> the exact opposite of what you should be by conventional >> matrix math. >> >> >> >> Campbell, can you trace back what happened with vector >> multiplication >> >> in Mathutils? >> >> >> >> /Benoit > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers