<p>Yes, you do need to transform the fetch direction into the space of the cubemap. If you could somehow figure out the fetch direction in the vertex shader, then you could do the transformation there instead, but that would produce worse lighting.</p>

<p>It also may be worth optimizing for a smaller number of interpolants between the vertex and pixel shaders (rather than a smaller number of matrix-vector multiplications in the pixel shader). As soon as you have one transformed view vector and two transformed light vectors that must be interpolated (which would otherwise be constant), you've matched the size of the tangent/bitangent/normal matrix that you would otherwise be interpolating. That has the potential to have more performance impact than doing extra matrix multiplications in the shader.</p>

CC BY-SA 3.0
2016-04-19T14:32:18.870Z
2016-04-19T14:32:18.870Z
John Calsbeek
<p>When I saw an implementation of normal mapping that computed the <em>TBN matrix</em> in the vertex shader and converted everything (in particular the view vector and light vector) to tangent space at that stage, it seemed like the proper way to do. This way there is no matrix-vector multiplication left to do in the fragment shader.</p>

<p>Enters image based lighting: for each fragment we want to fetch from an image, typically one or more cube map textures, the light intensity coming from certain directions. I assume this data is in world space.</p>

<p>My question is: is it possible to use IBL while retaining the vertex shader transform optimization mentioned above?</p>

<ul>
<li>It seems to me we still need to transform our fetch direction from tangent space to world space (or whichever space the cube map is in).</li>
<li>Conversely, if we want to work in world space, like with deferred shading, we need to transform the normal for each fragment.</li>
</ul>

<p>Does IBL necessarily imply at least one matrix vector multiplication per fragment and the optimization I mentioned is an uncommon case, or am I missing something?</p>

<optimisation><matrix><ibl><normal-mapping>
Image based lighting, tangent space coordinates, and optimization
Julien Guertault
# Image based lighting, tangent space coordinates, and optimization

(Asked by: username_0 on 2016-04-19)

When I saw an implementation of normal mapping that computed the *TBN matrix* in the vertex shader and converted everything (in particular the view vector and light vector) to tangent space at that stage, it seemed like the proper way to do. This way there is no matrix-vector multiplication left to do in the fragment shader.

Enters image based lighting: for each fragment we want to fetch from an image, typically one or more cube map textures, the light intensity coming from certain directions. I assume this data is in world space.

My question is: is it possible to use IBL while retaining the vertex shader transform optimization mentioned above?

* It seems to me we still need to transform our fetch direction from tangent space to world space (or whichever space the cube map is in).
* Conversely, if we want to work in world space, like with deferred shading, we need to transform the normal for each fragment.

Does IBL necessarily imply at least one matrix vector multiplication per fragment and the optimization I mentioned is an uncommon case, or am I missing something?

**Tags:** optimisation, matrix, ibl, normal-mapping


---

## 1 answers

### Answer by username_1 on 2016-04-19. Score: 4 | Accepted answer

Yes, you do need to transform the fetch direction into the space of the cubemap. If you could somehow figure out the fetch direction in the vertex shader, then you could do the transformation there instead, but that would produce worse lighting.

It also may be worth optimizing for a smaller number of interpolants between the vertex and pixel shaders (rather than a smaller number of matrix-vector multiplications in the pixel shader). As soon as you have one transformed view vector and two transformed light vectors that must be interpolated (which would otherwise be constant), you've matched the size of the tangent/bitangent/normal matrix that you would otherwise be interpolating. That has the potential to have more performance impact than doing extra matrix multiplications in the shader.


---

