> > >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 <ideasma...@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 <mikkels...@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.me...@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@blender.org > >>> http://lists.blender.org/mailman/listinfo/bf-committers > >>> > >> _______________________________________________ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > > > > > > > > -- > > - Campbell > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > -- > No essence. No permanence. No perfection. Only action. > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers