Choosing the Space to compute Lighting

• For more information about precision, check Graphics and Shaders#Precision .

View Space

• Advantages :

  • Since view space places the camera at the origin, numbers tend to stay small and preserve precision. This is an important consideration when rendering large worlds. When coordinates become large (e.g. 1000km, they cannot represent small differences; details smaller than ~6 cm are lost.

  • View-space normals allow efficient compression: since the camera always looks down the −Z axis, we only need to store x and y components and reconstruct z, saving G-buffer bandwidth. This is a reason why several engines prefer view-space normals for deferred shading. With smaller positions, depth reconstruction is also more stable. This compression does not work for world-space normals, where all directions are equally likely.

  • The view vector in specular/PBR models is simply the negative fragment position in view space. The camera position is (0,0,0), so no extra subtraction is needed. LearnOpenGL notes that this makes the specular term easy to compute and is why many tutorials prefer view-space lighting.

    • LearnOpenGL:

      • We chose to do the lighting calculations in world space, but most people tend to prefer doing lighting in view space.

      • An advantage of view space is that the viewer's position is always at (0,0,0)  so you already got the position of the viewer for free.

      • However, I find calculating lighting in world space more intuitive for learning purposes.

  • Since the fragment’s z value directly represents the distance from the camera, effects like fog, attenuation and cluster slicing in clustered shading become easier to implement.

• Disadvantages :

  • Environment maps and image-based lighting (IBL) are usually defined in world space. To sample them, view-space normals must be converted to world space; repeated conversions can add instructions and risk precision loss. Some encoding techniques only support world-space normals.

  • Because view-space normals rotate with the camera, specular highlights and reflections may appear to wobble, especially when using normal maps.

  • Light positions and directions stored in world space must be transformed into view space each frame. For many lights, this transformation may be non-negligible (though compute shaders can handle it efficiently).

World Space

• Advantages :

  • World-space normals do not change when the camera moves, so specular highlights from normal maps remain stable. This is useful for physically based rendering (PBR) with image-based lighting, where a consistent normal is needed to look up from environment maps.

  • Krzysztof Narkowicz (UE5) notes that world-space normals have beneficial properties: they do not depend on the camera, so specular highlights and reflections on static objects will not wobble when the camera moves. Because their precision does not depend on the camera direction, they remain accurate even for surfaces pointing away from the viewer. In contrast, view-space normals change orientation when the camera rotates, which can make environment map lookups or specular highlights less stable.

  • Since most lights and environment maps are defined in world space, you avoid per-fragment transformations. In forward renderers this can simplify the shader because light direction can be computed once in world space and reused.

  • Some post-processing effects (SSAO, screen-space reflections) and global illumination techniques operate in world space and expect world-space positions and normals. Having them already in world space can avoid conversions.

• Disadvantages :

  • Using world-space positions directly means adding large translations (e.g., the camera is at 1 km while shading a small object). The article “The Perils of World Space” explains that 32-bit floats only have high resolution near the origin; far from the origin, sub-centimetre differences cannot be represented. Thus shading calculations (e.g., diffuse or specular dot products) may wobble due to imprecision. This can manifest as flickering when the camera moves.

  • World-space normals require all three components to be stored, and world-space positions might need 3×32-bit floats. This increases memory bandwidth in deferred renderers compared with view-space normals, which can be compressed.

  • For specular reflections relative to the camera, you must compute the view vector by subtracting the camera position from the fragment position, adding per-fragment cost.

• Trick to improve precision: Fixing the camera and moving the world :

  • Instead of letting the camera roam far from the origin, move the world in the opposite direction so that the camera stays near the origin. Pharr describes decomposing the view matrix into rotation and translation, then moving the translation into the model matrices while keeping the camera at the origin; worldPos – cameraPos  is computed in double-precision on the CPU and passed to the GPU as a small value. Many engines (e.g., Cryengine) perform lighting in world space but shift the origin per frame; this provides the stability of view-space lighting while retaining the advantages of world-space normals

  • Matt Phaar's explanation of the trick .