Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Image reference for the question:

object space vs world space

(image from the CG tutorial)

The D3D9 API got us used to world matrices.

However, if you use world matrices, then you have to do an extra matrix multiply in the shader (which ends up being the same for a whole lot of vertices).

Hence the OpenGL convention of concatenating the modelling and viewing matrices into one matrix (the GL_MODELVIEWMATRIX = View*World).

What's better, and why?

share|improve this question
up vote 7 down vote accepted

No. At no time should you ever have an explicit world matrix in your shader.

A detailed explanation for why can be found here, but the short version is really very simple: you never need it and it can kill your floating-point precision.

If your world space is too big, then a camera that is far from the origin can cause floating point precision problems.

All world space is is nothing more than an intermediary between model space and camera space. It's a place where you can express the camera and all other objects in the same space. But all you use it for is to generate a world-to-camera matrix, which you then apply to all of the model-to-world matrices to create model-to-camera matrices.

You can deal with precision problems in C++ by using doubles instead of floats for matrix computations. You can convert these back to floats before uploading them to the shader.

So why would you ever need an explicit world-space transform in your shader? In your source code, yes. But in your shader? What would you do with it that you can't do with camera space?

Lighting can be done in camera space just as easily as world space; all you have to do is transform your light positions/directions into camera space. After all, camera space has the same scale as world space. You do this transformation once per frame per light; hardly a performance burden even on the CPU.

So there is absolutely no point in ever exposing your shaders to an explicit world space transform. It's just an intermediate step that you fold into your matrices.

share|improve this answer

You wouldn't do the extra matrix multiply in your shader. The trick is that you do your matrix multiplication once-per-frame on the CPU, then upload the final result to your vertex shader. That gives you one position by matrix multiplication per-vertex, irrespective of whether you have world and view separate or concatenated.

share|improve this answer

In many cases, you want to have the world pos in the vertex shader anyway, for other purposes. For example, you need to compute the view vector, to pass down into the pixel shader to evaluate specular.

The local-to-world matrix is also needed to transform tangent vectors and normal vectors[1] into world space for shading, assuming that you do shading in world space (you might do it in tangent space, in which case you'd need a different set of matrices).

So IMO, it makes sense to have two matrices: local-to-world and world-to-clip. The latter is the product of the view matrix and the projection matrix. Pass both to the vertex shader, and do the multiplications like:

posWorld = mul(posLocal, matLocalToWorld)
posClip = mul(posWorld, matWorldToClip)

[1] (So long as you don't have nonuniform scaling. In that case normals must be transformed by the inverse transpose of the local-to-world matrix.)

share|improve this answer
-1: World space is bad. Very bad; you shouldn't use it in shaders – Nicol Bolas Oct 18 '11 at 7:43
@NicolBolas: Good point; there are precision issues with shading in world space. Doesn't mean you have to use camera space. At my job we actually use a "camera-centered world space" - axes aligned with the world, origin at the camera. Having world-aligned axes makes it easier to apply cubemaps that are stored in world space. – Nathan Reed Oct 18 '11 at 15:36

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.