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

[Morten Mikkelsen]

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
>