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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
