Re: [Bf-committers] matrix multiplication in Blender SVN of this morning (W32 Vista mingw compiled)
I forgot to mention the meaning of m1 *= m2 (it should be mathematically correct as it look like not to be so) (see start of this thread) Peter ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] matrix multiplication in Blender SVN of this morning (W32 Vista mingw compiled)
I just played with numpy and the numpy matrix behaves in print and operation as is (for me at least) normally done in mathematics and so is done in the wikipedia.org about matrices!!! So eventually one could look there how it is done, that layout and mathematical interpretation is the same ... the internal ordering of matrix elemens is more or less irrelevant. Starting point too are vectors and an n-dimensional vector is an object with ordered n numbers, and one says (makes!) an element of a linear space R(n). In combination with matrices rather often vectors are viewed as matrices with either one row or one column R(n,1) or R(1, n) whereas matrices with n rows and m columns are elements of R(n,m). Then matrix multiplication between those matrix spaces are only possible with m1 element R(n,m) and m2 R(p,q) ==> m1 * m2 if and only if m = p with result an element of R(n,q) now take a normal world_matrix of Blender which is an element of R(4,4), e.g. mat. Multiplication with a vector one has to defined by thinking a vector as being a matrix! And that is very often done. But you than have a choice: a vector vec , element R(n), look at it as element of R(n,1) (column vector) or element of R(1,n) row vector! At THIS moment Vectors are printed in the console as row, so it would, my opinion, be wise to say vectors in Blender are elemens of R(1,n) (row-vectors!) with as consequence that the multiplication of (world!!!) matrix with a vector has to be vec * mat, delivering again an element of R(1,n) Meaning: mat * vec is FORBIDDEN! Probably this is suitable too to the internal column first ordering of matrices (but not essential) as far as mathematically good results occur in operation but too in layout! Now the print at THIS moment of the a (world) matrix in the Python console as well defining a matrix is row-wise (am I right?, I think so because >From an 2 x 3 numpy matrix m1 >>> m1 matrix([[1, 2, 3], [4, 5, 6]]) Now Mathutils: >>> M1 = Matrix(((m1[0,0],m1[0,1],m1[0,2]),(m1[1,0],m1[1,1],m1[1,2]))) >>> M1 Matrix(((1.0, 2.0, 3.0), (4.0, 5.0, 6.0))) Same layout should mean same mathematical interpretation Result: the Blender a week ago or so was correct, not allowing Matrix * Vector but only Vector * Matrix. How matrices and or vectors are stored is not so important, maybe the execution time prefers column first? Greets Peter ( a retired mathematician ;-) ) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] matrix multiplication in Blender SVN of this morning (W32 Vista mingw compiled)
> > >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 > 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 > 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 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
Re: [Bf-committers] matrix multiplication in Blender SVN of this morning (W32 Vista mingw compiled)
This seems like the basis of a religious war...like endianness. 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 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 > 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 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
Re: [Bf-committers] matrix multiplication in Blender SVN of this morning (W32 Vista mingw compiled)
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 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 > 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 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
Re: [Bf-committers] matrix multiplication in Blender SVN of this morning (W32 Vista mingw compiled)
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 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 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
Re: [Bf-committers] matrix multiplication in Blender SVN of this morning (W32 Vista mingw compiled)
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 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
Re: [Bf-committers] matrix multiplication in Blender SVN of this morning (W32 Vista mingw compiled)
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
Re: [Bf-committers] matrix multiplication in Blender SVN of this morning (W32 Vista mingw compiled)
I'll be sure to include this in the API docs, possibly my change to
repr caused more confusion since the string output of a matrix is:
>>> Matrix()
Matrix(((1.0, 0.0, 0.0, 0.0),
(0.0, 1.0, 0.0, 0.0),
(0.0, 0.0, 1.0, 0.0),
(0.0, 0.0, 0.0, 1.0)))
We could remove \n's
Matrix(((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (0.0, 0.0, 1.0,
0.0), (0.0, 0.0, 0.0, 1.0)))
... for __repr__ and have a __str__ method that gives a more typical
math style print.
Either way, notes in docs explaining this would be good so we can
point devs here since its a re-occurring topic.
On Wed, Jul 27, 2011 at 8: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. So the following
> code:
>
> m1 = Matrix([[ 1, 0, 2], [-1, 3, 1]])
> m2 = Matrix([[3, 1],[2, 1],[1, 0]])
> print(m1*m2)
>
> Translates into this in ordinary notation:
>
> (1 -1) X (3 2 1) = (2 1 1)
> (0 3) (1 1 0) (3 3 0)
> (2 1) (7 5 2)
>
> Which is exactly what blender returns.
>
> Mathutils matrices are column-major because that's how Blender stores
> the matrices internal, and Blender uses that convention because openGL
> uses it.
>
>
>> -Original Message-
>> From: bf-committers-boun...@blender.org
>> [mailto:bf-committers-boun...@blender.org] On Behalf Of
>> bf-committers-requ...@blender.org
>> Sent: mercredi 27 juillet 2011 12:00
>> To: bf-committers@blender.org
>> Subject: Bf-committers Digest, Vol 84, Issue 26
> On Tue, 26 Jul 2011 16:49:54 +0200, "Peter K.H. Gragert"
> wrote:
>>
>> Hallo,
>> First try ...
>>
>> Put this text in the console and run it
>> code start=
>> import bpy
>> from mathutils import Matrix
>> print("\nSTART---")
>> m1 = Matrix([[ 1, 0, 2],
>> [-1, 3, 1]])
>> print(m1, "\nelement R(2,3)")
>>
>> m2 = Matrix([[3, 1],
>> [2, 1],
>> [1, 0]])
>> print(m2, "\nelement R(3,2)")
>>
>> print("m1 * m2 =", m1*m2, " should be element R(2,3) * R(3,2)
>> => R(2,2) but is R(3,3) so math it looks like m2 * m1 so it
>> is STRANGE!")
>>
>> print("m2*m1 = ", m2*m1, " should be element R(3,2) * R( 2,3)
>> => R(3,3) but is R(2,2) so math it looks like m1 *
>> m2,(consistantly) STRANGE")
>>
>> # checking what *= means
>> m1_Copy = m1.copy()
>> m1_Copy *= m2
>> m1_BlStar_m2 = m1_Copy
>> print("m1 BLender *= m2", m1_BlStar_m2 ,"should be element
>> dependant of what *= means , right or left multiplication")
>> print("result shows it is interpretated as math: m1 * m2,
>> \n\n ==> so math RIGHT multiplication!")
>> print( "check:", m1 * m2 == m1_BlStar_m2 )
>> print("\n+ now again?!!??? ")
>> m1_BlStarm_m2_Copy = m1_BlStar_m2.copy()
>> m1_BlStarm_m2_Copy *= m2
>> m1_BlStar_m2_BlStar_m2 = m1_BlStarm_m2_Copy
>> print(" m1 BlStar_m2_BlStar_m2 =\n", m1_BlStar_m2_BlStar_m2,
>> "\nshould be ERROR R(3,3) * R(3,2) => R(3,2) but is R(3,3) ERROR!")
>>
>> code end=
>>
>>
>> ==> matrix multiplication is NOT like math matrix multiblication
>>
>> m1 * m2 in Blender correspondent with m2 * m1 in math
>> (STRANGE not nice but ... let it be so)
>>
>> But THEN *=
>> m2 *= m1 behaves very strange and to my opinion wrong!
>>
>> Greetings
>> Peter K.H. Gragert
>>
>
>
> ___
> 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
Re: [Bf-committers] matrix multiplication in Blender SVN of this morning (W32 Vista mingw compiled)
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. So the following
code:
m1 = Matrix([[ 1, 0, 2], [-1, 3, 1]])
m2 = Matrix([[3, 1],[2, 1],[1, 0]])
print(m1*m2)
Translates into this in ordinary notation:
(1 -1) X (3 2 1) = (2 1 1)
(0 3) (1 1 0) (3 3 0)
(2 1) (7 5 2)
Which is exactly what blender returns.
Mathutils matrices are column-major because that's how Blender stores
the matrices internal, and Blender uses that convention because openGL
uses it.
> -Original Message-
> From: bf-committers-boun...@blender.org
> [mailto:bf-committers-boun...@blender.org] On Behalf Of
> bf-committers-requ...@blender.org
> Sent: mercredi 27 juillet 2011 12:00
> To: bf-committers@blender.org
> Subject: Bf-committers Digest, Vol 84, Issue 26
On Tue, 26 Jul 2011 16:49:54 +0200, "Peter K.H. Gragert"
wrote:
>
> Hallo,
> First try ...
>
> Put this text in the console and run it
> code start=
> import bpy
> from mathutils import Matrix
> print("\nSTART---")
> m1 = Matrix([[ 1, 0, 2],
> [-1, 3, 1]])
> print(m1, "\nelement R(2,3)")
>
> m2 = Matrix([[3, 1],
> [2, 1],
> [1, 0]])
> print(m2, "\nelement R(3,2)")
>
> print("m1 * m2 =", m1*m2, " should be element R(2,3) * R(3,2)
> => R(2,2) but is R(3,3) so math it looks like m2 * m1 so it
> is STRANGE!")
>
> print("m2*m1 = ", m2*m1, " should be element R(3,2) * R( 2,3)
> => R(3,3) but is R(2,2) so math it looks like m1 *
> m2,(consistantly) STRANGE")
>
> # checking what *= means
> m1_Copy = m1.copy()
> m1_Copy *= m2
> m1_BlStar_m2 = m1_Copy
> print("m1 BLender *= m2", m1_BlStar_m2 ,"should be element
> dependant of what *= means , right or left multiplication")
> print("result shows it is interpretated as math: m1 * m2,
> \n\n ==> so math RIGHT multiplication!")
> print( "check:", m1 * m2 == m1_BlStar_m2 )
> print("\n+ now again?!!??? ")
> m1_BlStarm_m2_Copy = m1_BlStar_m2.copy()
> m1_BlStarm_m2_Copy *= m2
> m1_BlStar_m2_BlStar_m2 = m1_BlStarm_m2_Copy
> print(" m1 BlStar_m2_BlStar_m2 =\n", m1_BlStar_m2_BlStar_m2,
> "\nshould be ERROR R(3,3) * R(3,2) => R(3,2) but is R(3,3) ERROR!")
>
> code end=
>
>
> ==> matrix multiplication is NOT like math matrix multiblication
>
> m1 * m2 in Blender correspondent with m2 * m1 in math
> (STRANGE not nice but ... let it be so)
>
> But THEN *=
> m2 *= m1 behaves very strange and to my opinion wrong!
>
> Greetings
>Peter K.H. Gragert
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
