I stumbled on this question because I had the same problem with my camera, and changing the multiplication order worked.

I ran into a similar problem when scaling a model. This code produced the wrong result:

// world is an existing Matrix
var scale = world * Matrix.CreateScale(3.2f);

whereas this worked perfectly (scaled a model to 3.2x it's size):

var scale = Matrix.CreateScale(3.2f) * world;

I don't understand why the order matters though - in "normal" math (that is, 5*3 vs 3*5), swapping the factors yields the same result. I understand differences if there are more than 2 factors (like in this question), but I don't see the issue here?

I don't know much about how Matrices really work and so I don't know if that's an XNA quirk or if it would happen in OpenGL as well?

  • 14
    \$\begingroup\$ This isn't a game dev question, it's a math question. Go teach yourself how to manually multiply matrices, you'll quickly learn why the order matters. \$\endgroup\$
    – House
    Commented Sep 11, 2013 at 5:50
  • 3
    \$\begingroup\$ Matrix multiplication is not commutative, unlike "normal" multiplication. In this sense it's more like "normal" division - would you expect 5 / 3 to be the same as 3 / 5? \$\endgroup\$ Commented Sep 11, 2013 at 7:03
  • \$\begingroup\$ Just by definition \$\endgroup\$
    – acrilige
    Commented Sep 11, 2013 at 9:09
  • 21
    \$\begingroup\$ Walk five steps then rotate 90 degrees. Now, rotate 90 degrees then walk five steps. Are you in the same place? Please, Don't do this test near a cliff. \$\endgroup\$
    – Zhen
    Commented Sep 11, 2013 at 10:53
  • 1
    \$\begingroup\$ @MichaelStum, another way to think about it. You mean scale matrix but in reality [in a more accurate way] this matrix should be called scale using (0,0,0) as center. So if world move the mesh from the (0,0,0), the scale result will be different. \$\endgroup\$
    – Zhen
    Commented Sep 12, 2013 at 7:25

2 Answers 2


The fact that matrix multiplication isn't (usually) commutative is a mathematical fact, and doesn't have anything to do with which API or library (XNA, OpenGL, etc.) you're using.

At the level of arithmetic, the order matters because matrix multiplication involves combining the rows of the first matrix with the columns of the second. If you swap the two matrices, you're swapping which one contributes rows and which one contributes columns to the result.

The deeper reason that order matters is that matrices represent geometric transformations, and the order of transformations matters. For example, since simple scaling is always relative to the origin of coordinates, doing a scale after a translate is different from a translate after a scale, since the translate moves the origin. Similarly, rotations don't commute with translation, and rotations around one axis don't commute with those around another axis.


Man is this kind of hard to figure out a good explanation of why.

Basically the matrices all transform the geometric values. If you shift the object any, you aren't just performing on a mathematical operation on the original object, but you are performing the operation after any other adjustments you have already done.

You can almost think of the object after any matrix operation as a completely new object, because that's what it is in RAM, for the most part. So, if you move the object 4 steps to the left, you end up with (Object on top of an "invisible board" 4 steps to the left). If you rotate the resultant object, you aren't rotating the original object anymore, but the object based on the object that is attached to that "invisible board" 4 steps to the left.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .