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

[Morten Mikkelsen]

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

Then let's make sure we don't turn it into one. That being said I don't
think
this should keep us from discussing the subject. It's a relevant issue
and we have moderators to deal with spats.

Cheers,

Morten.






>
> 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.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>