[Bf-committers] matrix multiplication in Blender SVN of this morning (W32 Vista mingw compiled)

[Jim Williams]

This seems like the basis of a religious war...like endianness.

Even though I generally like to do things the way mathematicians do it,
I'd suggest leaving it the Blender traditional way by default and invite
anyone who strongly prefers it the other way to write an API function
to switch the sense to math_usual_order within a python routine -- or some
other scope that doesn't interact with other code. (This avoids
depreciation hassles.)  I do think a using very limited scope would make
it easier people to follow the code as otherwise they'll get confused
about which order.


On Wed, Jul 27, 2011 at 10:16 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
> This is definitely possible with the api (and probably not all that
> much work) but its quite a big change for some script authors - unlike
> multiplication order (trivial by comparison).
>
> I don't have a sense for whats normal here since I only use mathutils
> but if this is so confusing and most/all other apis do it ROW-MAJOR
> then perhaps?
>
> Interested to hear other blender devs opinions on this.
>
> On Wed, Jul 27, 2011 at 11:56 PM, Morten Mikkelsen <mikkelsen7 at gmail.com> wrote:
>> I am with you on this one. Memory layout is one thing. Abstraction is
>> something else entirely.
>> Afterall, one could choose the memory layout to be some crazy fixed random
>> layout or a swizzled
>> layout or whatever. And in both cases there is no reason why, at abstraction
>> level, either one could be considered
>> column or alternatively row major. As an example if the abstraction is
>> column major you'd set translation as a set_column
>> function (and set_row if the api is row major). This can work with any
>> memory layout. To me they are two separate things.
>>
>> (It's implied here that set_column refers to the abstract column).
>>
>> Cheers,
>>
>> Morten.
>>
>>
>>
>>
>>
>>
>> On Wed, Jul 27, 2011 at 6:05 AM, Paul Melis <paul.melis at sara.nl> wrote:
>>
>>> Just chiming in here....
>>>
>>> On 07/27/2011 12:47 PM, Benoit Bolsee wrote:
>>> > Hi, I repeat once more: mathutils matrices are COLUMN-MAJOR. This means
>>> > that the top elements in the definition list are columns, not rows,
>>> > despite the fact that they are printed horizontaly.
>>> > [...]
>>> > Mathutils matrices are column-major because that's how Blender stores
>>> > the matrices internal, and Blender uses that convention because openGL
>>> > uses it.
>>>
>>> Why would the textual (or any higher-level representation) have to
>>> follow the storage layout?
>>>
>>> For me those are two distinct concepts and it would be the least
>>> confusing to have the matrix representation follow the regular math
>>> convention. E.g.
>>> http://www.opengl.org/sdk/docs/man/xhtml/glLoadMatrix.xml shows
>>> multiplication with a matrix m being loaded as
>>>
>>>       / m[0]  m[4]  m[8]   m[12] \   / v[0] \
>>> M(v) = | m[1]  m[5]  m[9]   m[13] | x | v[1] |
>>>       | m[2]  m[6]  m[10]  m[14] |   | v[2] |
>>>       \ m[3]  m[7]  m[11]  m[15] /   \ v[3] /
>>>
>>> even though the actual storage order of the matrix is obviously
>>> column-major.
>>>
>>> Secondly, when creating a matrix with Matrix([e1, e2, e3, e4]) I was
>>> very surprised to see that the e_i represent columns! Again, this is the
>>> storage layout coming through on a higher level, which is confusing.
>>>
>>> Anyways, just my 2 cents.
>>>
>>> Regards,
>>> Paul
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
No essence.  No permanence.  No perfection.  Only action.