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

[Morten Mikkelsen]

well actually I am used to column major myself (at the abstraction level).
I only meant I agree that memory layout and abstraction does not have to be
the same when it comes
to row vs, column major.

cheers,

Morten.


On Wed, Jul 27, 2011 at 7: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
>