Transformations and the "World" matrix,
Crossbones+ - Reputation: 6504
Posted 27 January 2011 - 10:08 AM
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.
External Articulation of Concepts Materializes Innate Knowledge of One's Craft and Science
Beginner in Game Development? Read here. And read here.
Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley
If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts
Members - Reputation: 475
Posted 27 January 2011 - 10:40 AM
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.
LinkedIn profile: http://ar.linkedin.com/pub/andres-ricardo-chamarra/2a/28a/272
Members - Reputation: 100
Posted 28 January 2011 - 12:06 AM
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.
Crossbones+ - Reputation: 7078
Posted 28 January 2011 - 04:42 AM
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 ...
Members - Reputation: 122
Posted 01 February 2011 - 04:34 PM
Check out this summary on World-View-Projection. The author gives a great concise explanation.