[Bf-committers] Patches Submitted

[Campbell Barton]

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.bolsee at 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
> <ideasman42 at 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
>> <ideasman42 at 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.bolsee at 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 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell