1
\$\begingroup\$

This might be a misunderstanding on my part but let me give you my superficial understanding of Model-View-Projection pipeline and different coordinate systems. Then I will ask a question.

As we know, we might have many models in our scene. You might load vertex attributes for each using a model loader etc. When you load the coordinates, these are in object space or model space. So they describe the object wrt a local frame. We use model matrix to transform this to world space shared by all models, a global frame let's say.

After this, we are in a huge world space. We might think this as an endless Euclidean 3D space. Here coordinates may have any value. Somewhere in the world, we have a camera and these objects in the world have different coordinates wrt. camera's frame. This is where view matrix comes into play. After applying this transformation, coordinates are in view space. In the OpenGl world, we think like the camera lies at the origin. We specify a view frustum and we do (actually delay) the clipping etc.

After this we apply projection matrix and transform this viewing pyramid into a cube that spans [-1, 1] in all the axes. This is homogeneous coordinates and we do perspective divide, clipping etc. This is my view of the whole thing, roughly.

The question is, we have routines to generate view and projection transformations given the required parameters. But how about the model matrix? For example, I load a bunny model stored in an OBJ file. It might have a coordinate value like (32.657, -12.545, 8.444). In which space are these coordinates? If it's in the model space, what is the best strategy to develop a model matrix to put this object into world space? Another OBJ model of same bunny might have coordinates all lying in [-1, 1] range for example. Does this mean this object is already transformed with an MVP? Are those model matrices related to only skeletal, hierarchical models?

I think this is a strange question so I don't see this really mentioned anywhere. But this bugs me, leaves me with a superficial understanding of whole matter. I want to truly understand.

\$\endgroup\$

2 Answers 2

1
\$\begingroup\$

Your understanding is correct:

  • The model matrix moves from model space to world space.
  • The view matrix moves from world space to view space.
  • The projection matrix moves from view space to clip space.

In which space are these coordinates?

Coordinates in model files are in model (or "object") space.

If it's in the model space, what is the best strategy to develop a model matrix to put this object into world space?

You do this when you decide you're going to render a particular instance of the model somewhere, oriented and scaled in some way. In the general sense you create a translation matrix based on the X, Y and Z in world space you want the object to appear, a rotation matrix based on how you want to orient the object in the world and a scaling matrix based on how you want to scale the object (if at all) and concatenate all three of these as appropriate via matrix multiplication.

You will generally create one such model matrix per instance you're going to draw in the world (whereas you'd probably create the view and projection matrices only once per frame).

Another OBJ model of same bunny might have coordinates all lying in [-1, 1] range for example. Does this mean this object is already transformed with an MVP?

No. It just means it's smaller (unless of course you choose to assume it's already transformed, which you can do, but that is of limited practical use).

From your commentary:

For example, to develop a translation matrix I need to look at object space coordinates, then I could say, "oh I can trasnlate x-axis by -20, that could put this object here". But this assumes I should be fully aware of the object space coordinates of each model.

No, it doesn't assume that. What is assumed in the transition from object to world space is that the you "place" the origin of the object in model space at the desired point in the world; that the model was authored so that the object-space coordinate (0,0,0) is a reasonable placement point for the object. For a humanoid character, for example, you might expect that (0,0,0) is centered under the model's feet.

The three basic transformation matrices are "about the origin," so (for example) a translation of (X, Y, Z) in a model matrix will put the point at (0,0,0) in object space at (X, Y, Z) in world space.

If this assumption that the model is built around a reasonable (0,0,0) point is not true... if for example somebody created a model of a human character and the feet were at (-43, 200, 2) for some reason.. then yes, you'd need to know this offset from the actual model space origin to the placement point. There is no way to algorithmically determine this offset for arbitrary geometry, so any content pipeline that is building models in this (very strange) fashion will generally either also make sure to export that offset in some form, or possibly only be used in a constrained set of circumstances where additional context allows one to algorithmically determine the offset. This is uncommon, however, and you're more likely to see models built around a reasonable origin for placement.

\$\endgroup\$
4
  • \$\begingroup\$ For example, to develop a translation matrix I need to look at object space coordinates, then I could say, "oh I can trasnlate x-axis by -20, that could put this object here". But this assumes I should be fully aware of the object space coordinates of each model. Isn't there a programmatic way of generating this matrix like we have in perspective and camera? Otherwise, things become more like trial-and-error, at least in my case. \$\endgroup\$
    – meguli
    Commented Dec 19, 2017 at 20:33
  • \$\begingroup\$ No, you don't need to look at the object-space coordinates to develop a translation matrix to place the object in the world. You simply need to decide where you want the object in the world: if you want the object at (20, 15, 5) in the world, you build a translation matrix for that value. That will result in the origin of the object (0,0,0 in model space) being at (20, 15, 5) in the world. \$\endgroup\$
    – user1430
    Commented Dec 19, 2017 at 20:37
  • \$\begingroup\$ For example, It could be great if OBJ loaders gave me range [a, b] for each axis, in object space. Then I could interpolate those to my world space extend. I assume I am the one determining the world space extend. \$\endgroup\$
    – meguli
    Commented Dec 19, 2017 at 20:37
  • \$\begingroup\$ You can certainly calculate the range of object space vertices when you load the model, but you don't need that to decide how to place the object in the world at all. You simply decide where you want it in the world and create an appropriate transformation matrix. \$\endgroup\$
    – user1430
    Commented Dec 19, 2017 at 20:43
0
\$\begingroup\$

When a model was created in 3d space , the vertex position were defined in Local space initially, but most DCC app will associate a transform node to the shape(use to generate the vertex in local space in maya) of the model , user can move the model in world space by it's transform node, the transform node is a 4*4 matrix behind , also called model matrix , the final position of the model in world space is it's local position multiply by model matrix. If you export this transformd model to a new app such like unity ,it was in local space initially (Although it was not in the orgin ), all the vertex are live in the local space, The same as maya or other DCC, unity will assosiate a transform component to the model, transform component represents the model matrix of the model ,the final vertex position in the scene is the local coordinates multiply by the model matrix. When you use load the geometry into shader, it only load the local coordinates of the vertex ,so you should multiply the model matrix(reprent transform component) to the model manually to convert it into unity world space coordinates

\$\endgroup\$

You must log in to answer this question.

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