Re: [Bf-committers] Patches Submitted
Committed deprecation, enabling the CMake build option 'WITH_ASSERT_ABORT' turns the warning into an error (which I prefer to ensure I don't miss any errors when testing). Went over all blender scripts and addons today and in svn, and swapped all vector multiplications. The contrib addons still need to be updated but I'll leave this to someone else. On Sun, Jul 24, 2011 at 10:38 PM, Campbell Barton ideasma...@gmail.com wrote: Hi Benoit, yep v*=m too. Thinking about this and Id rather quaternions be changed too, mainly because I'd rather not have them work differently to matrices. Consider both a 3x3 matrix and a quaternion often represent rotation which may be applied to a vector - If we keep quat's as-is you'd need to reverse the multiplication order to apply this rotation, which adds unnecessary confusion. m * v v * m.to_quaternion() I think this can be done at the same time as matrix deprecation without adding much extra hassles. On Sat, Jul 23, 2011 at 10:12 PM, Benoit Bolsee benoit.bol...@online.be wrote: Hi Campbell, I agree on your depracation plan. Note that you should also deprecate the in-place multiplication v*=m and replace it in 2.6 by the correct result. Regarding the quaternions product, looking at mathutil code I see that vec*qt is defined as applying the rotation coded inside the quaternion to the vector. This operation is defined mathematically as Q*v*Q^-1, where * is the ordinary multiplication given that v is expressed in the quaternion base (i,j,k) as xi+yj+zk. So the mathutil expression v*Q only a shortcut and I don't have a preference for the order. Better not change it. @Wim: I totally agree with your math. When talking about a matrix (4x4), the first 4 is the number of rows and the second 4 the number of columns, so the valid product (4x4)x(4x1) indicates that a column vector can only be on the right side of the matrix and the resulting vector is made of dot products of the vector with rows of the matrix. My point is that in Blender today, you get that result with the expression v*m, with is the opposite order of the convention. The multiplication (1x4)x(4x4) is perfectly valid and leads to a vector that is made of dot products of the vector with columns of the matrix. Today this operation is not possible with Blender, and it will be introduced in 2.6 as per Campbell deprecation plan. Again, all the confusion about this order issue is coming from the fact that mathutil matrices are column major (this decision was taken because of openGL and Blender internals). So you when print a matrix is Blender, the columns are printed horizontally, which is confusing. /Benoit On Fri, 22 Jul 2011 20:35:24 +1000, Campbell Barton ideasma...@gmail.com wrote: Benoit, should we should apply this logic to quaternions too? (use Quaternion*Vector instead) Couldn't find which order is correct from looking online. On Fri, Jul 22, 2011 at 8:06 PM, Campbell Barton ideasma...@gmail.com wrote: Thank for looking into this Benoit, This is not something I am knowledgeable on with so, taking you're word that vec * matrix is wrong (why didn't anyone notice this???), heres the upgrade path Sergy and I have agreed on that will not break scripts. 1) deprecate vec * matrix immediately. print a warning which includes the python line number, add support for mat * vec. 2) after some weeks/months, drop support for vec * matrix, print an error instead, to ensure scripts are not using it and its developers ignoring the warning. 3) for 2.60 release, add in vec * matrix which works correctly and not like it does currently, leaving enough time that scripts from 2.58 will have time to switch the multiplication order. On Fri, Jul 22, 2011 at 7:09 PM, Benoit Bolsee benoit.bol...@online.be wrote: Hi, I changed the Matrix multiplication order beween 2.49 and 2.5 because it was simply incorrect in 2.49, in the sense that it was not matching the way you write matrix math on paper. In your example, print (m1 * m2) Matrix((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.62, 0.1, -0.05, 1.0)) is actually the correct answer if you remember that the matrix are column major. The order should not be changed again. I see Campbell reverted the patch, so that's ok. @Campbell: the reason why numpy returns a different result than Blender is because numpy matrix are row-major by default. The fact that Blender uses column major matrix may be confusing when the matrix is printed (columns are printed horizontally) but it's very convenient to extract vectors from the matrix (e.g. the position vector). While playing around I found something else that still doesn't work: in the scientific literature, vectors are single column matrix, this means that the only correct way to multiply a vector with a matrix is to put it on the right side of the matrix: v2 = m1
Re: [Bf-committers] Patches Submitted
Hi Benoit, yep v*=m too. Thinking about this and Id rather quaternions be changed too, mainly because I'd rather not have them work differently to matrices. Consider both a 3x3 matrix and a quaternion often represent rotation which may be applied to a vector - If we keep quat's as-is you'd need to reverse the multiplication order to apply this rotation, which adds unnecessary confusion. m * v v * m.to_quaternion() I think this can be done at the same time as matrix deprecation without adding much extra hassles. On Sat, Jul 23, 2011 at 10:12 PM, Benoit Bolsee benoit.bol...@online.be wrote: Hi Campbell, I agree on your depracation plan. Note that you should also deprecate the in-place multiplication v*=m and replace it in 2.6 by the correct result. Regarding the quaternions product, looking at mathutil code I see that vec*qt is defined as applying the rotation coded inside the quaternion to the vector. This operation is defined mathematically as Q*v*Q^-1, where * is the ordinary multiplication given that v is expressed in the quaternion base (i,j,k) as xi+yj+zk. So the mathutil expression v*Q only a shortcut and I don't have a preference for the order. Better not change it. @Wim: I totally agree with your math. When talking about a matrix (4x4), the first 4 is the number of rows and the second 4 the number of columns, so the valid product (4x4)x(4x1) indicates that a column vector can only be on the right side of the matrix and the resulting vector is made of dot products of the vector with rows of the matrix. My point is that in Blender today, you get that result with the expression v*m, with is the opposite order of the convention. The multiplication (1x4)x(4x4) is perfectly valid and leads to a vector that is made of dot products of the vector with columns of the matrix. Today this operation is not possible with Blender, and it will be introduced in 2.6 as per Campbell deprecation plan. Again, all the confusion about this order issue is coming from the fact that mathutil matrices are column major (this decision was taken because of openGL and Blender internals). So you when print a matrix is Blender, the columns are printed horizontally, which is confusing. /Benoit On Fri, 22 Jul 2011 20:35:24 +1000, Campbell Barton ideasma...@gmail.com wrote: Benoit, should we should apply this logic to quaternions too? (use Quaternion*Vector instead) Couldn't find which order is correct from looking online. On Fri, Jul 22, 2011 at 8:06 PM, Campbell Barton ideasma...@gmail.com wrote: Thank for looking into this Benoit, This is not something I am knowledgeable on with so, taking you're word that vec * matrix is wrong (why didn't anyone notice this???), heres the upgrade path Sergy and I have agreed on that will not break scripts. 1) deprecate vec * matrix immediately. print a warning which includes the python line number, add support for mat * vec. 2) after some weeks/months, drop support for vec * matrix, print an error instead, to ensure scripts are not using it and its developers ignoring the warning. 3) for 2.60 release, add in vec * matrix which works correctly and not like it does currently, leaving enough time that scripts from 2.58 will have time to switch the multiplication order. On Fri, Jul 22, 2011 at 7:09 PM, Benoit Bolsee benoit.bol...@online.be wrote: Hi, I changed the Matrix multiplication order beween 2.49 and 2.5 because it was simply incorrect in 2.49, in the sense that it was not matching the way you write matrix math on paper. In your example, print (m1 * m2) Matrix((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.62, 0.1, -0.05, 1.0)) is actually the correct answer if you remember that the matrix are column major. The order should not be changed again. I see Campbell reverted the patch, so that's ok. @Campbell: the reason why numpy returns a different result than Blender is because numpy matrix are row-major by default. The fact that Blender uses column major matrix may be confusing when the matrix is printed (columns are printed horizontally) but it's very convenient to extract vectors from the matrix (e.g. the position vector). While playing around I found something else that still doesn't work: in the scientific literature, vectors are single column matrix, this means that the only correct way to multiply a vector with a matrix is to put it on the right side of the matrix: v2 = m1 * v1 However, this doesn't work in Blender m Matrix((1.0, 0.0, 0.0, 0.0), ? ? ? (0.0, 1.0, 0.0, 0.0), ? ? ? (1.0, 0.0, -1.0, 0.0), ? ? ? (0.0, 0.0, 0.0, 1.0)) v Vector((0.5, 0.0, 0.5, 1.0)) m*v Traceback (most recent call last): ?File blender_console, line 1, in module TypeError: Matrix multiplication: not supported between 'mathutils.Matrix' and 'mathutils.Vector' types But the reverse expression gives the
Re: [Bf-committers] Patches Submitted
Hi Campbell, I agree on your depracation plan. Note that you should also deprecate the in-place multiplication v*=m and replace it in 2.6 by the correct result. Regarding the quaternions product, looking at mathutil code I see that vec*qt is defined as applying the rotation coded inside the quaternion to the vector. This operation is defined mathematically as Q*v*Q^-1, where * is the ordinary multiplication given that v is expressed in the quaternion base (i,j,k) as xi+yj+zk. So the mathutil expression v*Q only a shortcut and I don't have a preference for the order. Better not change it. @Wim: I totally agree with your math. When talking about a matrix (4x4), the first 4 is the number of rows and the second 4 the number of columns, so the valid product (4x4)x(4x1) indicates that a column vector can only be on the right side of the matrix and the resulting vector is made of dot products of the vector with rows of the matrix. My point is that in Blender today, you get that result with the expression v*m, with is the opposite order of the convention. The multiplication (1x4)x(4x4) is perfectly valid and leads to a vector that is made of dot products of the vector with columns of the matrix. Today this operation is not possible with Blender, and it will be introduced in 2.6 as per Campbell deprecation plan. Again, all the confusion about this order issue is coming from the fact that mathutil matrices are column major (this decision was taken because of openGL and Blender internals). So you when print a matrix is Blender, the columns are printed horizontally, which is confusing. /Benoit On Fri, 22 Jul 2011 20:35:24 +1000, Campbell Barton ideasma...@gmail.com wrote: Benoit, should we should apply this logic to quaternions too? (use Quaternion*Vector instead) Couldn't find which order is correct from looking online. On Fri, Jul 22, 2011 at 8:06 PM, Campbell Barton ideasma...@gmail.com wrote: Thank for looking into this Benoit, This is not something I am knowledgeable on with so, taking you're word that vec * matrix is wrong (why didn't anyone notice this???), heres the upgrade path Sergy and I have agreed on that will not break scripts. 1) deprecate vec * matrix immediately. print a warning which includes the python line number, add support for mat * vec. 2) after some weeks/months, drop support for vec * matrix, print an error instead, to ensure scripts are not using it and its developers ignoring the warning. 3) for 2.60 release, add in vec * matrix which works correctly and not like it does currently, leaving enough time that scripts from 2.58 will have time to switch the multiplication order. On Fri, Jul 22, 2011 at 7:09 PM, Benoit Bolsee benoit.bol...@online.be wrote: Hi, I changed the Matrix multiplication order beween 2.49 and 2.5 because it was simply incorrect in 2.49, in the sense that it was not matching the way you write matrix math on paper. In your example, print (m1 * m2) Matrix((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.62, 0.1, -0.05, 1.0)) is actually the correct answer if you remember that the matrix are column major. The order should not be changed again. I see Campbell reverted the patch, so that's ok. @Campbell: the reason why numpy returns a different result than Blender is because numpy matrix are row-major by default. The fact that Blender uses column major matrix may be confusing when the matrix is printed (columns are printed horizontally) but it's very convenient to extract vectors from the matrix (e.g. the position vector). While playing around I found something else that still doesn't work: in the scientific literature, vectors are single column matrix, this means that the only correct way to multiply a vector with a matrix is to put it on the right side of the matrix: v2 = m1 * v1 However, this doesn't work in Blender m Matrix((1.0, 0.0, 0.0, 0.0), ? ? ? (0.0, 1.0, 0.0, 0.0), ? ? ? (1.0, 0.0, -1.0, 0.0), ? ? ? (0.0, 0.0, 0.0, 1.0)) v Vector((0.5, 0.0, 0.5, 1.0)) m*v Traceback (most recent call last): ?File blender_console, line 1, in module TypeError: Matrix multiplication: not supported between 'mathutils.Matrix' and 'mathutils.Vector' types But the reverse expression gives the correct result (i.e the result of m * v) v*m Vector((1.0, 0.0, -0.5, 1.0)) which is illogical and should be fixed. Note that this incorrect form has one benefit: it allows the use the shortcut expression v*=m to apply a transformation matrix on a vector. I pretty certain that I set the matrix*vector multiplication order correct at the same time I fixed the matrix*matrix multiplication order, so I don't know where this new error is coming from. Note that v*m is an acceptable expression if one considers that it turns v into a row vector, but
Re: [Bf-committers] Patches Submitted
Hi, I changed the Matrix multiplication order beween 2.49 and 2.5 because it was simply incorrect in 2.49, in the sense that it was not matching the way you write matrix math on paper. In your example, print (m1 * m2) Matrix((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.62, 0.1, -0.05, 1.0)) is actually the correct answer if you remember that the matrix are column major. The order should not be changed again. I see Campbell reverted the patch, so that's ok. @Campbell: the reason why numpy returns a different result than Blender is because numpy matrix are row-major by default. The fact that Blender uses column major matrix may be confusing when the matrix is printed (columns are printed horizontally) but it's very convenient to extract vectors from the matrix (e.g. the position vector). While playing around I found something else that still doesn't work: in the scientific literature, vectors are single column matrix, this means that the only correct way to multiply a vector with a matrix is to put it on the right side of the matrix: v2 = m1 * v1 However, this doesn't work in Blender m Matrix((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (1.0, 0.0, -1.0, 0.0), (0.0, 0.0, 0.0, 1.0)) v Vector((0.5, 0.0, 0.5, 1.0)) m*v Traceback (most recent call last): File blender_console, line 1, in module TypeError: Matrix multiplication: not supported between 'mathutils.Matrix' and 'mathutils.Vector' types But the reverse expression gives the correct result (i.e the result of m * v) v*m Vector((1.0, 0.0, -0.5, 1.0)) which is illogical and should be fixed. Note that this incorrect form has one benefit: it allows the use the shortcut expression v*=m to apply a transformation matrix on a vector. I pretty certain that I set the matrix*vector multiplication order correct at the same time I fixed the matrix*matrix multiplication order, so I don't know where this new error is coming from. Note that v*m is an acceptable expression if one considers that it turns v into a row vector, but then the result of the multiplication is different of course. In 2.49 it was possible to use both expressions m*v and v*m and they were producing different results, except that there were the exact opposite of what you should be by conventional matrix math. Campbell, can you trace back what happened with vector multiplication in Mathutils? /Benoit On Wed, 20 Jul 2011 20:12:50 -0500, Scott Giese scott.gi...@comcast.net wrote: My reasoning for assuming this was a bug: 1. Previously working scripts (2.49) broke. 2. m1 *= m2 is equivalent to m1 = m1 * m2, where m1 represents the Base matrix and m2 represents the Influencing matrix. This is more intuitive to me. There is no equivalent shorthand for m1 = m2 * m1. e.g. Apply a series of transforms to produce a single transformation matrix contextMatrix = mathutils.Matrix() for part in parts: contextMatrix *= data.tran.matrix[part.matrix_index] contextMatrix *= data.tran.matrix[part.parent.matrix_index] ... newObject.matrix_basis = contextMatrix 3. Treating leftMatrix as the Base and rightMatrix as the Influencing facilitates a hypothetical method of varying argument counts. e.g. resultMatrix = Matrix.Combine(baseMatrix, translateMatrix, rotationMatrix, scaleMatrix, ...) The above outlines my thought process. I was not aware that the change was intentional. In light of the ... stop breaking APIs? discussion, we may be better served by leaving it as-is. Scott -Original Message- From: Campbell Barton [mailto:ideasma...@gmail.com] Sent: Wednesday, July 20, 2011 2:16 AM To: bf-blender developers Subject: Re: [Bf-committers] Patches Submitted On Wed, Jul 20, 2011 at 3:37 PM, Scott Giese scott.gi...@comcast.net wrote: Hi Gang, FYI. I submitted 3 patches for your review. ?I'm new to the list and I wanted to give back to the Blender community. 28030 ?SCONS Build: Build Date reflects http://projects.blender.org/tracker/index.php?func=detailaid =28030group_i d=9atid=127 1 instead of actual date of build 28031 ?Minor typo in Blenlib http://projects.blender.org/tracker/index.php?func=detailaid =28031group_i d=9atid=127 28032 ?Python Mathutils: Matrix Multiplication Error http://projects.blender.org/tracker/index.php?func=detailaid =28032group_i d=9atid=127 Great work guys! ?Appreciate the great product. Scott Thanks for the fixes, committed all patches however you're changes to mathutils effectively only change the order of multiplication, http://projects.blender.org/tracker/index.php?func=detailaid= 28032group_id =9atid=127 In you're example print (m1 * m2) Change to... print (m2 * m1) This is a bit confusing because in C we have
Re: [Bf-committers] Patches Submitted
Thank for looking into this Benoit, This is not something I am knowledgeable on with so, taking you're word that vec * matrix is wrong (why didn't anyone notice this???), heres the upgrade path Sergy and I have agreed on that will not break scripts. 1) deprecate vec * matrix immediately. print a warning which includes the python line number, add support for mat * vec. 2) after some weeks/months, drop support for vec * matrix, print an error instead, to ensure scripts are not using it and its developers ignoring the warning. 3) for 2.60 release, add in vec * matrix which works correctly and not like it does currently, leaving enough time that scripts from 2.58 will have time to switch the multiplication order. On Fri, Jul 22, 2011 at 7:09 PM, Benoit Bolsee benoit.bol...@online.be wrote: Hi, I changed the Matrix multiplication order beween 2.49 and 2.5 because it was simply incorrect in 2.49, in the sense that it was not matching the way you write matrix math on paper. In your example, print (m1 * m2) Matrix((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.62, 0.1, -0.05, 1.0)) is actually the correct answer if you remember that the matrix are column major. The order should not be changed again. I see Campbell reverted the patch, so that's ok. @Campbell: the reason why numpy returns a different result than Blender is because numpy matrix are row-major by default. The fact that Blender uses column major matrix may be confusing when the matrix is printed (columns are printed horizontally) but it's very convenient to extract vectors from the matrix (e.g. the position vector). While playing around I found something else that still doesn't work: in the scientific literature, vectors are single column matrix, this means that the only correct way to multiply a vector with a matrix is to put it on the right side of the matrix: v2 = m1 * v1 However, this doesn't work in Blender m Matrix((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (1.0, 0.0, -1.0, 0.0), (0.0, 0.0, 0.0, 1.0)) v Vector((0.5, 0.0, 0.5, 1.0)) m*v Traceback (most recent call last): File blender_console, line 1, in module TypeError: Matrix multiplication: not supported between 'mathutils.Matrix' and 'mathutils.Vector' types But the reverse expression gives the correct result (i.e the result of m * v) v*m Vector((1.0, 0.0, -0.5, 1.0)) which is illogical and should be fixed. Note that this incorrect form has one benefit: it allows the use the shortcut expression v*=m to apply a transformation matrix on a vector. I pretty certain that I set the matrix*vector multiplication order correct at the same time I fixed the matrix*matrix multiplication order, so I don't know where this new error is coming from. Note that v*m is an acceptable expression if one considers that it turns v into a row vector, but then the result of the multiplication is different of course. In 2.49 it was possible to use both expressions m*v and v*m and they were producing different results, except that there were the exact opposite of what you should be by conventional matrix math. Campbell, can you trace back what happened with vector multiplication in Mathutils? /Benoit On Wed, 20 Jul 2011 20:12:50 -0500, Scott Giese scott.gi...@comcast.net wrote: My reasoning for assuming this was a bug: 1. Previously working scripts (2.49) broke. 2. m1 *= m2 is equivalent to m1 = m1 * m2, where m1 represents the Base matrix and m2 represents the Influencing matrix. This is more intuitive to me. There is no equivalent shorthand for m1 = m2 * m1. e.g. Apply a series of transforms to produce a single transformation matrix contextMatrix = mathutils.Matrix() for part in parts: contextMatrix *= data.tran.matrix[part.matrix_index] contextMatrix *= data.tran.matrix[part.parent.matrix_index] ... newObject.matrix_basis = contextMatrix 3. Treating leftMatrix as the Base and rightMatrix as the Influencing facilitates a hypothetical method of varying argument counts. e.g. resultMatrix = Matrix.Combine(baseMatrix, translateMatrix, rotationMatrix, scaleMatrix, ...) The above outlines my thought process. I was not aware that the change was intentional. In light of the ... stop breaking APIs? discussion, we may be better served by leaving it as-is. Scott -Original Message- From: Campbell Barton [mailto:ideasma...@gmail.com] Sent: Wednesday, July 20, 2011 2:16 AM To: bf-blender developers Subject: Re: [Bf-committers] Patches Submitted On Wed, Jul 20, 2011 at 3:37 PM, Scott Giese scott.gi...@comcast.net wrote: Hi Gang, FYI. I submitted 3 patches for your review. ?I'm new to the list and I wanted to give back to the Blender community. 28030 ?SCONS Build: Build Date reflects http://projects.blender.org
Re: [Bf-committers] Patches Submitted
Benoit, should we should apply this logic to quaternions too? (use Quaternion*Vector instead) Couldn't find which order is correct from looking online. On Fri, Jul 22, 2011 at 8:06 PM, Campbell Barton ideasma...@gmail.com wrote: Thank for looking into this Benoit, This is not something I am knowledgeable on with so, taking you're word that vec * matrix is wrong (why didn't anyone notice this???), heres the upgrade path Sergy and I have agreed on that will not break scripts. 1) deprecate vec * matrix immediately. print a warning which includes the python line number, add support for mat * vec. 2) after some weeks/months, drop support for vec * matrix, print an error instead, to ensure scripts are not using it and its developers ignoring the warning. 3) for 2.60 release, add in vec * matrix which works correctly and not like it does currently, leaving enough time that scripts from 2.58 will have time to switch the multiplication order. On Fri, Jul 22, 2011 at 7:09 PM, Benoit Bolsee benoit.bol...@online.be wrote: Hi, I changed the Matrix multiplication order beween 2.49 and 2.5 because it was simply incorrect in 2.49, in the sense that it was not matching the way you write matrix math on paper. In your example, print (m1 * m2) Matrix((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.62, 0.1, -0.05, 1.0)) is actually the correct answer if you remember that the matrix are column major. The order should not be changed again. I see Campbell reverted the patch, so that's ok. @Campbell: the reason why numpy returns a different result than Blender is because numpy matrix are row-major by default. The fact that Blender uses column major matrix may be confusing when the matrix is printed (columns are printed horizontally) but it's very convenient to extract vectors from the matrix (e.g. the position vector). While playing around I found something else that still doesn't work: in the scientific literature, vectors are single column matrix, this means that the only correct way to multiply a vector with a matrix is to put it on the right side of the matrix: v2 = m1 * v1 However, this doesn't work in Blender m Matrix((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (1.0, 0.0, -1.0, 0.0), (0.0, 0.0, 0.0, 1.0)) v Vector((0.5, 0.0, 0.5, 1.0)) m*v Traceback (most recent call last): File blender_console, line 1, in module TypeError: Matrix multiplication: not supported between 'mathutils.Matrix' and 'mathutils.Vector' types But the reverse expression gives the correct result (i.e the result of m * v) v*m Vector((1.0, 0.0, -0.5, 1.0)) which is illogical and should be fixed. Note that this incorrect form has one benefit: it allows the use the shortcut expression v*=m to apply a transformation matrix on a vector. I pretty certain that I set the matrix*vector multiplication order correct at the same time I fixed the matrix*matrix multiplication order, so I don't know where this new error is coming from. Note that v*m is an acceptable expression if one considers that it turns v into a row vector, but then the result of the multiplication is different of course. In 2.49 it was possible to use both expressions m*v and v*m and they were producing different results, except that there were the exact opposite of what you should be by conventional matrix math. Campbell, can you trace back what happened with vector multiplication in Mathutils? /Benoit On Wed, 20 Jul 2011 20:12:50 -0500, Scott Giese scott.gi...@comcast.net wrote: My reasoning for assuming this was a bug: 1. Previously working scripts (2.49) broke. 2. m1 *= m2 is equivalent to m1 = m1 * m2, where m1 represents the Base matrix and m2 represents the Influencing matrix. This is more intuitive to me. There is no equivalent shorthand for m1 = m2 * m1. e.g. Apply a series of transforms to produce a single transformation matrix contextMatrix = mathutils.Matrix() for part in parts: contextMatrix *= data.tran.matrix[part.matrix_index] contextMatrix *= data.tran.matrix[part.parent.matrix_index] ... newObject.matrix_basis = contextMatrix 3. Treating leftMatrix as the Base and rightMatrix as the Influencing facilitates a hypothetical method of varying argument counts. e.g. resultMatrix = Matrix.Combine(baseMatrix, translateMatrix, rotationMatrix, scaleMatrix, ...) The above outlines my thought process. I was not aware that the change was intentional. In light of the ... stop breaking APIs? discussion, we may be better served by leaving it as-is. Scott -Original Message- From: Campbell Barton [mailto:ideasma...@gmail.com] Sent: Wednesday, July 20, 2011 2:16 AM To: bf-blender developers Subject: Re: [Bf-committers] Patches Submitted On Wed, Jul 20, 2011 at 3:37 PM, Scott Giese scott.gi
Re: [Bf-committers] Patches Submitted
it as-is. Scott -Original Message- From: Campbell Barton [mailto:ideasma...@gmail.com] Sent: Wednesday, July 20, 2011 2:16 AM To: bf-blender developers Subject: Re: [Bf-committers] Patches Submitted On Wed, Jul 20, 2011 at 3:37 PM, Scott Giese scott.gi...@comcast.net wrote: Hi Gang, FYI. I submitted 3 patches for your review. ?I'm new to the list and I wanted to give back to the Blender community. 28030 ?SCONS Build: Build Date reflects http://projects.blender.org/tracker/index.php?func=detailaid =28030group_i d=9atid=127 1 instead of actual date of build 28031 ?Minor typo in Blenlib http://projects.blender.org/tracker/index.php?func=detailaid =28031group_i d=9atid=127 28032 ?Python Mathutils: Matrix Multiplication Error http://projects.blender.org/tracker/index.php?func=detailaid =28032group_i d=9atid=127 Great work guys! ?Appreciate the great product. Scott Thanks for the fixes, committed all patches however you're changes to mathutils effectively only change the order of multiplication, http://projects.blender.org/tracker/index.php?func=detailaid= 28032group_id =9atid=127 In you're example print (m1 * m2) Change to... print (m2 * m1) This is a bit confusing because in C we have mul_m4_m4m4(m1, m2); which is the equivalent to m2 * m1 in python. A while back Benoit Bolsee was concerned our matrix multiplication order was wrong so we switched it (between 2.4x and 2.5x) What makes you think the order in blender is wrong? what's you're reference? Just checked and we're currently doing matrix multiplication differently to numpy which doesn't bode well :S - test: # --- snip m1 = ((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.6, 0.0, -0.05, 1.0)) m2 = ((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.02, -0.1, 1.0)) from numpy import matrix n_m1 = matrix(m1) n_m2 = matrix(m2) print(\nnumpy\n%r % (n_m1 * n_m2)) from mathutils import Matrix b_m1 = Matrix(m1) b_m2 = Matrix(m2) print(\nmathutils\n%r % (b_m1 * b_m2)) # --- output numpy matrix([[ 0. , 0. , 1. , 0. ], [-1. , 0. , 0. , 0. ], [ 0. , -1. , 0. , 0. ], [ 0.6 , -0.02, -0.15, 1. ]]) mathutils Matrix((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.62, 0.1, -0.05, 1.0)) # --- switch m1/m2 order for both mathutils and numpy. re-run numpy matrix([[ 0. , 0. , 1. , 0. ], [-1. , 0. , 0. , 0. ], [ 0. , -1. , 0. , 0. ], [ 0.62, 0.1 , -0.05, 1. ]]) mathutils Matrix((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.6, -0.0, -0.15, 1.0)) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Avoid hangovers - stay drunk! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Patches Submitted
On Wed, Jul 20, 2011 at 3:37 PM, Scott Giese scott.gi...@comcast.net wrote: Hi Gang, FYI. I submitted 3 patches for your review. I'm new to the list and I wanted to give back to the Blender community. 28030 SCONS Build: Build Date reflects http://projects.blender.org/tracker/index.php?func=detailaid=28030group_i d=9atid=127 1 instead of actual date of build 28031 Minor typo in Blenlib http://projects.blender.org/tracker/index.php?func=detailaid=28031group_i d=9atid=127 28032 Python Mathutils: Matrix Multiplication Error http://projects.blender.org/tracker/index.php?func=detailaid=28032group_i d=9atid=127 Great work guys! Appreciate the great product. Scott Thanks for the fixes, committed all patches however you're changes to mathutils effectively only change the order of multiplication, http://projects.blender.org/tracker/index.php?func=detailaid=28032group_id=9atid=127 In you're example print (m1 * m2) Change to... print (m2 * m1) This is a bit confusing because in C we have mul_m4_m4m4(m1, m2); which is the equivalent to m2 * m1 in python. A while back Benoit Bolsee was concerned our matrix multiplication order was wrong so we switched it (between 2.4x and 2.5x) What makes you think the order in blender is wrong? what's you're reference? Just checked and we're currently doing matrix multiplication differently to numpy which doesn't bode well :S - test: # --- snip m1 = ((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.6, 0.0, -0.05, 1.0)) m2 = ((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.02, -0.1, 1.0)) from numpy import matrix n_m1 = matrix(m1) n_m2 = matrix(m2) print(\nnumpy\n%r % (n_m1 * n_m2)) from mathutils import Matrix b_m1 = Matrix(m1) b_m2 = Matrix(m2) print(\nmathutils\n%r % (b_m1 * b_m2)) # --- output numpy matrix([[ 0. , 0. , 1. , 0. ], [-1. , 0. , 0. , 0. ], [ 0. , -1. , 0. , 0. ], [ 0.6 , -0.02, -0.15, 1. ]]) mathutils Matrix((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.62, 0.1, -0.05, 1.0)) # --- switch m1/m2 order for both mathutils and numpy. re-run numpy matrix([[ 0. , 0. , 1. , 0. ], [-1. , 0. , 0. , 0. ], [ 0. , -1. , 0. , 0. ], [ 0.62, 0.1 , -0.05, 1. ]]) mathutils Matrix((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.6, -0.0, -0.15, 1.0)) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Patches Submitted
I've needed to try and figure this one out too so here's my two cents and some random matrices. Since Blender uses column major order matrices these printouts are actually visually transposed to normal math, actual matrix columns are shown horizontally in the inner brackets and rows are vertical. So the 2.5 in a*b ((a*b)[2][0] - column 2, row 0) is a result of dot produt (a row 0, b column 2) as it should be - dot( (1.0, 0.0, 1.0, 0.0), (0.5, 1.0, 2.0, 0.0) ). a Matrix((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (1.0, 0.0, -1.0, 0.0), (0.0, 0.0, 0.0, 1.0)) b Matrix((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (0.5, 1.0, 2.0, 0.0), (0.0, 0.0, 0.0, 1.0)) a*b Matrix((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (2.5, 1.0, -2.0, 0.0), (0.0, 0.0, 0.0, 1.0)) b*a Matrix((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (0.5, -1.0, -2.0, 0.0), (0.0, 0.0, 0.0, 1.0)) One nice thing about this is that the columns are the axises (0,1,2) and translation (3) of a matrix, so a camera direction for example would be -a[2][0:3]. 2011/7/20 Campbell Barton ideasma...@gmail.com On Wed, Jul 20, 2011 at 3:37 PM, Scott Giese scott.gi...@comcast.net wrote: Hi Gang, FYI. I submitted 3 patches for your review. I'm new to the list and I wanted to give back to the Blender community. 28030 SCONS Build: Build Date reflects http://projects.blender.org/tracker/index.php?func=detailaid=28030group_i d=9atid=127 1 instead of actual date of build 28031 Minor typo in Blenlib http://projects.blender.org/tracker/index.php?func=detailaid=28031group_i d=9atid=127 28032 Python Mathutils: Matrix Multiplication Error http://projects.blender.org/tracker/index.php?func=detailaid=28032group_i d=9atid=127 Great work guys! Appreciate the great product. Scott Thanks for the fixes, committed all patches however you're changes to mathutils effectively only change the order of multiplication, http://projects.blender.org/tracker/index.php?func=detailaid=28032group_id=9atid=127 In you're example print (m1 * m2) Change to... print (m2 * m1) This is a bit confusing because in C we have mul_m4_m4m4(m1, m2); which is the equivalent to m2 * m1 in python. A while back Benoit Bolsee was concerned our matrix multiplication order was wrong so we switched it (between 2.4x and 2.5x) What makes you think the order in blender is wrong? what's you're reference? Just checked and we're currently doing matrix multiplication differently to numpy which doesn't bode well :S - test: # --- snip m1 = ((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.6, 0.0, -0.05, 1.0)) m2 = ((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.02, -0.1, 1.0)) from numpy import matrix n_m1 = matrix(m1) n_m2 = matrix(m2) print(\nnumpy\n%r % (n_m1 * n_m2)) from mathutils import Matrix b_m1 = Matrix(m1) b_m2 = Matrix(m2) print(\nmathutils\n%r % (b_m1 * b_m2)) # --- output numpy matrix([[ 0. , 0. , 1. , 0. ], [-1. , 0. , 0. , 0. ], [ 0. , -1. , 0. , 0. ], [ 0.6 , -0.02, -0.15, 1. ]]) mathutils Matrix((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.62, 0.1, -0.05, 1.0)) # --- switch m1/m2 order for both mathutils and numpy. re-run numpy matrix([[ 0. , 0. , 1. , 0. ], [-1. , 0. , 0. , 0. ], [ 0. , -1. , 0. , 0. ], [ 0.62, 0.1 , -0.05, 1. ]]) mathutils Matrix((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.6, -0.0, -0.15, 1.0)) ___ 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] Patches Submitted
My reasoning for assuming this was a bug: 1. Previously working scripts (2.49) broke. 2. m1 *= m2 is equivalent to m1 = m1 * m2, where m1 represents the Base matrix and m2 represents the Influencing matrix. This is more intuitive to me. There is no equivalent shorthand for m1 = m2 * m1. e.g. Apply a series of transforms to produce a single transformation matrix contextMatrix = mathutils.Matrix() for part in parts: contextMatrix *= data.tran.matrix[part.matrix_index] contextMatrix *= data.tran.matrix[part.parent.matrix_index] ... newObject.matrix_basis = contextMatrix 3. Treating leftMatrix as the Base and rightMatrix as the Influencing facilitates a hypothetical method of varying argument counts. e.g. resultMatrix = Matrix.Combine(baseMatrix, translateMatrix, rotationMatrix, scaleMatrix, ...) The above outlines my thought process. I was not aware that the change was intentional. In light of the ... stop breaking APIs? discussion, we may be better served by leaving it as-is. Scott -Original Message- From: Campbell Barton [mailto:ideasma...@gmail.com] Sent: Wednesday, July 20, 2011 2:16 AM To: bf-blender developers Subject: Re: [Bf-committers] Patches Submitted On Wed, Jul 20, 2011 at 3:37 PM, Scott Giese scott.gi...@comcast.net wrote: Hi Gang, FYI. I submitted 3 patches for your review. I'm new to the list and I wanted to give back to the Blender community. 28030 SCONS Build: Build Date reflects http://projects.blender.org/tracker/index.php?func=detailaid=28030group_i d=9atid=127 1 instead of actual date of build 28031 Minor typo in Blenlib http://projects.blender.org/tracker/index.php?func=detailaid=28031group_i d=9atid=127 28032 Python Mathutils: Matrix Multiplication Error http://projects.blender.org/tracker/index.php?func=detailaid=28032group_i d=9atid=127 Great work guys! Appreciate the great product. Scott Thanks for the fixes, committed all patches however you're changes to mathutils effectively only change the order of multiplication, http://projects.blender.org/tracker/index.php?func=detailaid=28032group_id =9atid=127 In you're example print (m1 * m2) Change to... print (m2 * m1) This is a bit confusing because in C we have mul_m4_m4m4(m1, m2); which is the equivalent to m2 * m1 in python. A while back Benoit Bolsee was concerned our matrix multiplication order was wrong so we switched it (between 2.4x and 2.5x) What makes you think the order in blender is wrong? what's you're reference? Just checked and we're currently doing matrix multiplication differently to numpy which doesn't bode well :S - test: # --- snip m1 = ((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.6, 0.0, -0.05, 1.0)) m2 = ((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.02, -0.1, 1.0)) from numpy import matrix n_m1 = matrix(m1) n_m2 = matrix(m2) print(\nnumpy\n%r % (n_m1 * n_m2)) from mathutils import Matrix b_m1 = Matrix(m1) b_m2 = Matrix(m2) print(\nmathutils\n%r % (b_m1 * b_m2)) # --- output numpy matrix([[ 0. , 0. , 1. , 0. ], [-1. , 0. , 0. , 0. ], [ 0. , -1. , 0. , 0. ], [ 0.6 , -0.02, -0.15, 1. ]]) mathutils Matrix((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.62, 0.1, -0.05, 1.0)) # --- switch m1/m2 order for both mathutils and numpy. re-run numpy matrix([[ 0. , 0. , 1. , 0. ], [-1. , 0. , 0. , 0. ], [ 0. , -1. , 0. , 0. ], [ 0.62, 0.1 , -0.05, 1. ]]) mathutils Matrix((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.6, -0.0, -0.15, 1.0)) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Patches Submitted
Hi Gang, FYI. I submitted 3 patches for your review. I'm new to the list and I wanted to give back to the Blender community. 28030 SCONS Build: Build Date reflects http://projects.blender.org/tracker/index.php?func=detailaid=28030group_i d=9atid=127 1 instead of actual date of build 28031 Minor typo in Blenlib http://projects.blender.org/tracker/index.php?func=detailaid=28031group_i d=9atid=127 28032 Python Mathutils: Matrix Multiplication Error http://projects.blender.org/tracker/index.php?func=detailaid=28032group_i d=9atid=127 Great work guys! Appreciate the great product. Scott ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
