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