I also I have to do some more coding because I didn't catch how Chad was going to move both squares around. It seemed that once he created that second rectangle that was all he could manipulate. Obviously, I need more quality-time with XNA.
Transformations and the "World" matrix
I read that section about the rotation and translation about 3 times before it clicked as to what exactly was going on. The one I was confused about from the reading is the passing of "World" to the DrawRectangle method. Are you changing the "world" or just the "square"?
I also I have to do some more coding because I didn't catch how Chad was going to move both squares around. It seemed that once he created that second rectangle that was all he could manipulate. Obviously, I need more quality-time with XNA.
I also I have to do some more coding because I didn't catch how Chad was going to move both squares around. It seemed that once he created that second rectangle that was all he could manipulate. Obviously, I need more quality-time with XNA.
The world matrix represents the scale, rotation and position of the object in the world, that transformation moves the "Object Space Origin" to the position in the world you want the rectangle to be, that transformation will be applied to each vertex of the rectangle.
By multiplying the position vector of the vertices by the world matrix you move them to the desired position, the vertices are in object space, which means their position is relative to the object's "center", the world matrix moves and rotates that center to any position in the common or "world" space.
By multiplying the position vector of the vertices by the world matrix you move them to the desired position, the vertices are in object space, which means their position is relative to the object's "center", the world matrix moves and rotates that center to any position in the common or "world" space.
Think of spaces as frames of reference. When we move a point from one space to another, we change the origin, and as a result the point "moves". To keep things simple, objects have a "local" or "model" space, where the origin <0,0,0> is usually the center of the model. (It does not have to be, but it is usually nearby) This allows the artist to create individual models around <0,0,0> in their editor.
In the game, we obviously cannot have each model sitting right next to, or on, <0,0,0>; we want them to be spread out in the world. So to do this, we need to apply some Transformations to the model vertices to move them where they need to go. By applying these transformations, we "move" the vertices away from the origin, and now the vertices are in World Space.
Matrices simply provide a nice and easy way to apply these transformations to many points. Remember that if you were to transform a complex model with many many points/vertices, you would need to apply the transformation to each one. If you wanted to Translate (move), Rotate and Scale your model, you would need to do 3 different things to each point. So instead you can combine the different transformations into a single Matrix that will do it all at once. Then the graphics card (or cpu) has a nice "pre-made" matrix that it can multiply by every point to apply all of the transformations.
In the game, we obviously cannot have each model sitting right next to, or on, <0,0,0>; we want them to be spread out in the world. So to do this, we need to apply some Transformations to the model vertices to move them where they need to go. By applying these transformations, we "move" the vertices away from the origin, and now the vertices are in World Space.
Matrices simply provide a nice and easy way to apply these transformations to many points. Remember that if you were to transform a complex model with many many points/vertices, you would need to apply the transformation to each one. If you wanted to Translate (move), Rotate and Scale your model, you would need to do 3 different things to each point. So instead you can combine the different transformations into a single Matrix that will do it all at once. Then the graphics card (or cpu) has a nice "pre-made" matrix that it can multiply by every point to apply all of the transformations.
A rotation as well as a scaling is a multiplicative kind of operation (opposed to the translation, which is additive, although this fact is hidden when using homogeneous co-ordinates). It is known that multiplying anything with 0 (zero) will result in 0. Hence, a rotation of point 0 or a scaling of point 0 will result in 0. That means 0 is invariant against rotations and scaling. For scaling there is no other point in space that is invariant. For rotation, however, there are infinite many points that are invariant. All those point together is usually called the axis of rotation (because 0 is inherently invariant, any axis of rotation passes through 0).
One must see that this happens at the moment the rotation (as an example) is applied, and this doesn't mean a moment in time but a moment w.r.t. when the transformation has an effect on e.g. a vertex. Think of a transformation like
v * R
where R (a rotation) is applied to the v. The co-ordinates of v are given w.r.t. an "origin" at 0. This 0 is usually named the local origin, but for R it is simply the 0 that is part of the rotation axis. Now using a slightly different transformation
v * T * R
0 is still part of the rotation axis. Hence, from the point of view of R, T hasn't shifted the axis away, but it has shifted v away from the fixed axis. Therefore each single transformation happens in its own space, and for a single "model transformation"
S * R * T
there are already 3 spaces involved or perhaps even 5 if R itself is composed as Euler rotation.
The space in which v is given is called the "model" space. Then there are many spaces in which the transformations happen, one space per transformation. At a particular point you don't apply any more transformations to the model itself, and that space is called the "global" space or "world" space. That may be a space that is 0, 5, 1000, or any (positive) number of spaces "away" from the "model" space. So the "world" space is nothing special, besides that you have stopped to apply transformations to a model.
The above counts for the camera, too, because the camera can be handled like any other object. Just because the viewing pipeline requires to transform into the camera's "model" space (a.k.a its "local" space, a.k.a. the view space) what means to apply the inverse of the overall camera transform, it looks like the "world" space is something special. In fact it is just the space which we declare to be the common one at the end of all model transformations including the camera.
Coming to the point "moving the view or moving the world". Concatenating a model's standard transform RM * TM with a view transform V
RM * TM * V
and considering that V is the inverse of the camera transform C
RM * TM * C-1
which itself is usually composed as RC * TC , so that
RM * TM * TC-1 * RC-1
one can see that "in the middle" there is a composition of 2 translations. Considering further that mathematically there is no difference in which order the multiplications are done (caution: this doesn't mean that commutativity is given!)
( RM * TM ) * ( TC-1 * RC-1 ) == ( RM * TM * TC-1 ) * RC-1 == RM * ( TM * TC-1 * RC-1 )
it is obvious that a composed translation
T := TM * TC-1
can either be associated to the "model side" or to the "camera side" without any difference in the effect:
( RM * T ) * RC-1 == RM * ( T * RC-1 )
However, considering that the "model side" and the "camera side" can be computed for each own before being concatenated, it is performance-wise better to do the translation once for the one camera instead of once for each of N>1 models.
EDIT: Ohh, haven't noticed formerly that this thread belongs to a workshop ...
One must see that this happens at the moment the rotation (as an example) is applied, and this doesn't mean a moment in time but a moment w.r.t. when the transformation has an effect on e.g. a vertex. Think of a transformation like
v * R
where R (a rotation) is applied to the v. The co-ordinates of v are given w.r.t. an "origin" at 0. This 0 is usually named the local origin, but for R it is simply the 0 that is part of the rotation axis. Now using a slightly different transformation
v * T * R
0 is still part of the rotation axis. Hence, from the point of view of R, T hasn't shifted the axis away, but it has shifted v away from the fixed axis. Therefore each single transformation happens in its own space, and for a single "model transformation"
S * R * T
there are already 3 spaces involved or perhaps even 5 if R itself is composed as Euler rotation.
The space in which v is given is called the "model" space. Then there are many spaces in which the transformations happen, one space per transformation. At a particular point you don't apply any more transformations to the model itself, and that space is called the "global" space or "world" space. That may be a space that is 0, 5, 1000, or any (positive) number of spaces "away" from the "model" space. So the "world" space is nothing special, besides that you have stopped to apply transformations to a model.
The above counts for the camera, too, because the camera can be handled like any other object. Just because the viewing pipeline requires to transform into the camera's "model" space (a.k.a its "local" space, a.k.a. the view space) what means to apply the inverse of the overall camera transform, it looks like the "world" space is something special. In fact it is just the space which we declare to be the common one at the end of all model transformations including the camera.
Coming to the point "moving the view or moving the world". Concatenating a model's standard transform RM * TM with a view transform V
RM * TM * V
and considering that V is the inverse of the camera transform C
RM * TM * C-1
which itself is usually composed as RC * TC , so that
RM * TM * TC-1 * RC-1
one can see that "in the middle" there is a composition of 2 translations. Considering further that mathematically there is no difference in which order the multiplications are done (caution: this doesn't mean that commutativity is given!)
( RM * TM ) * ( TC-1 * RC-1 ) == ( RM * TM * TC-1 ) * RC-1 == RM * ( TM * TC-1 * RC-1 )
it is obvious that a composed translation
T := TM * TC-1
can either be associated to the "model side" or to the "camera side" without any difference in the effect:
( RM * T ) * RC-1 == RM * ( T * RC-1 )
However, considering that the "model side" and the "camera side" can be computed for each own before being concatenated, it is performance-wise better to do the translation once for the one camera instead of once for each of N>1 models.
EDIT: Ohh, haven't noticed formerly that this thread belongs to a workshop ...
Hi Alpha_ProgDes,
Check out this summary on World-View-Projection. The author gives a great concise explanation.
http://robertokoci.com/world-view-projection-matrix-unveiled/
Jamison
Check out this summary on World-View-Projection. The author gives a great concise explanation.
http://robertokoci.com/world-view-projection-matrix-unveiled/
Jamison
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
