This post is a follow-​up to my 2006 ShaderX⁵ arti­cle [4] about nor­mal map­ping with­out a pre-​computed tan­gent basis. In the time since then I have refined this tech­nique with lessons learned in real life. For those unfa­mil­iar with the topic, the moti­va­tion was to con­struct the tan­gent frame on the fly in the pixel shader, which iron­i­cally is the exact oppo­site of the moti­va­tion from [2]:

Since it is not 1997 any­more, doing the tan­gent space on-​the-​fly has some poten­tial ben­e­fits, such as reduced com­plex­ity of asset tools, per-​vertex band­width and stor­age, attribute inter­po­la­tors, trans­form work for skinned meshes and last but not least, the pos­si­bil­ity to apply nor­mal maps to any pro­ce­du­rally gen­er­ated tex­ture coor­di­nates or non-​linear deformations.

Inter­mis­sion: Tan­gents vs Cotangents

The way that nor­mal map­ping is tra­di­tion­ally defined is, as I think, flawed, and I would like to point this out with a sim­ple C++ metaphor. Sup­pose we had a class for vec­tors, for exam­ple called Vector3, but we also had a dif­fer­ent class for cov­ec­tors. The lat­ter are vec­tors that are made from the coef­fi­cients of a plane equa­tion, and they trans­form dif­fer­ently than ordi­nary vec­tors. As you may know, nor­mal vec­tors are an exam­ple of cov­ec­tors. Sup­pose the class for cov­ec­tors was called Covector3, hav­ing the same func­tion­al­ity as Vector3, but not com­pat­i­ble for assign­ment. Now imag­ine the fol­low­ing function:

Vector3 tangent;
Vector3 bitangent;
Covector3 normal;
 
Covector3 perturb_normal( float a, float b, float c )
{
    return a * tangent +
           b * bitangent + 
           c * normal; 
           // ^^^^ compile-error: type mismatch for operator +
}

The above func­tion mixes vec­tors and cov­ec­tors in a sin­gle expres­sion, which in this fic­tional exam­ple leads to a type mis­match error. If the normal is of type Covector3, then the tangent and the bitangent should be too, oth­er­wise they can­not form a con­sis­tent frame, can they? In real life shader code of course, every­thing would be defined as float3 and be fine, or rather not.

Math­e­mat­i­cal Com­pile Error

Unfor­tu­nately, the above mis­match is exactly how the ‘tan­gent frame’ for the pur­pose of nor­mal map­ping was intro­duced by the authors of [2]. This type mis­match is invis­i­ble as long as the tan­gent frame is orthog­o­nal. When the exer­cise is how­ever to recon­struct the tan­gent frame in the pixel shader, as this arti­cle is about, then we have to deal with a non-​orthogonal screen pro­jec­tion. This is the rea­son why in the book I had intro­duced both (which should be called co-​tangent) and (now it gets some­what silly, it should be called co-​bi-​tangent) as cov­ec­tors, oth­er­wise the algo­rithm does not work. I have to admit that I could have been more artic­u­late about this detail. This has caused real con­fu­sion, cf from gamedev.net:

The dis­crep­ancy is explained above, as my ‘tan­gent vec­tors’ are really cov­ec­tors. The def­i­n­i­tion on page 132 is con­sis­tent with that of a cov­ec­tor, and so the frame  should be called a cotan­gent frame.

Inter­mis­sion 2: Blinns Per­turbed Nor­mals (His­tory Channel)

In this sec­tion I would like to show how the def­i­n­i­tion of and as cov­ec­tors fol­lows nat­u­rally from Blinns orig­i­nal bump map­ping paper [1]. Blinn con­sid­ers a curved para­met­ric sur­face, for instance, a Bezier-​patch, on which he defines tan­gent vec­tors and as the deriv­a­tives of the posi­tion with respect to and .

In this con­text it is a con­ven­tion to use sub­scripts as a short­hand for par­tial deriv­a­tives, so he is really say­ing , etc. He also intro­duces the sur­face nor­mal and a bump height func­tion , which is used to dis­place the sur­face. In the end, he arrives at a for­mula for a first order approx­i­ma­tion of the per­turbed normal:

I would like to draw your atten­tion towards the terms and . They are the per­pen­dic­u­lars to and in the tan­gent plane, and can be seen as the ‘off­set vec­tors’ that ulti­mately dis­place the nor­mal. They are also cov­ec­tors (why, make the duck test: if it trans­forms like a cov­ec­tor, it is a cov­ec­tor) so adding them to the nor­mal does not raise said type mis­match. Let’s divide this thing one more time by and intro­duce and as follows:

where the hat (as in ) denotes the nor­mal­ized nor­mal. can be inter­preted as the nor­mal to the plane of con­stant , and like­wise as the nor­mal to the plane of con­stant . There­fore we have three nor­mal vec­tors, or cov­ec­tors, , and , and they are the a basis of a cotan­gent frame. Equiv­a­lently, and are the gra­di­ents of and , which is the def­i­n­i­tion I had used in the book. The mag­ni­tude of the gra­di­ent there­fore deter­mines the bump strength, a fact that I will dis­cuss later when it comes to scale invariance.

A Lit­tle Unlearning

The mis­take of many authors is to unwit­tingly take and for and , which only works as long as the vec­tors are orthog­o­nal. Let’s unlearn ‘tan­gent’, relearn ‘cotan­gent’, and repeat the his­tor­i­cal devel­op­ment from this per­spec­tive: Peercy et al. [2] pre­com­putes the val­ues and (the change of bump height per change of tex­ture coor­di­nate) and stores them in a tex­ture. They call it ‘nor­mal map’, but is a really some­thing like a ‘slope map’. (EDIT: Such maps have also become some­what pop­u­lar recently as deriv­a­tive maps, but the gen­eral idea has been there for some time). Such a slope map can­not rep­re­sent hor­i­zon­tal nor­mals, as this would need an infi­nite slope to do so. It also needs some ‘bump scale fac­tor’ stored some­where as meta data. Kil­gard [3] intro­duces the mod­ern con­cept of a nor­mal map as an encoded rota­tion oper­a­tor, which does away with the approx­i­ma­tion alto­gether, and instead gives the per­turbed nor­mal directly as

where the coef­fi­cients , and are read from a tex­ture. Most peo­ple would think that a nor­mal map stores nor­mals, but this is only super­fi­cially true. This idea of Kil­gard was, since the unper­turbed nor­mal has coor­di­nates , it is suf­fi­cient to store the last col­umn of the rota­tion matrix that would rotate the unper­turbed nor­mal to its per­turbed posi­tion. So yes, a nor­mal map stores basis vec­tors that cor­re­spond to per­turbed nor­mals. The dif­fi­culty starts to show up when nor­mal maps are blended, since this is then an inter­po­la­tion of rota­tion oper­a­tors, with all the com­plex­ity that goes with it (for an excel­lent review, see the arti­cle about Reori­ented Nor­mal Map­ping [5] here).

Solu­tion of the Cotan­gent Frame

The prob­lem to be solved for our pur­pose is the oppo­site as that of Blinn, the per­turbed nor­mal is known (from the nor­mal map), but the cotan­gent frame is unknown. I’ll give a short revi­sion of how I orig­i­nally solved it. Define the unknown cotan­gents and as the gra­di­ents of the tex­ture coor­di­nates and as func­tions of posi­tion , such that

where is the dot prod­uct. The gra­di­ents are con­stant over the sur­face of an inter­po­lated tri­an­gle, so intro­duce the edge dif­fer­ences , and . The unknown cotan­gents have to sat­isfy the constraints

where is the cross prod­uct. The first two rows fol­low from the def­i­n­i­tion, and the last row ensures that and have no com­po­nent in the direc­tion of the nor­mal. The last row is needed oth­er­wise the prob­lem is under­de­ter­mined. It is straight­for­ward then to express the solu­tion in matrix form. For ,

and anal­o­gously for with .

Into the Shader Code

The above result looks daunt­ing, as it calls for a matrix inverse in every pixel in order to com­pute the cotan­gent frame! How­ever, many sym­me­tries can be exploited to make that almost dis­ap­pear. Below is an exam­ple of a func­tion writ­ten in GLSL to cal­cu­late the inverse of a 3×3 matrix. A sim­i­lar func­tion writ­ten in HLSL appeared in the book, and then I tried to opti­mize the hell out of it. For­get this approach as we are not going to need it at all. Just observe how the adju­gate and the deter­mi­nant can be made from cross products:

mat3 inverse3x3( mat3 M )
{
    // The original was written in HLSL, but this is GLSL, 
    // therefore
    // - the array index selects columns, so M_t[0] is the 
    //   first row of M, etc.
    // - the mat3 constructor assembles columns, so 
    //   cross( M_t[1], M_t[2] ) becomes the first column
    //   of the adjugate, etc.
    // - for the determinant, it does not matter whether it is
    //   computed with M or with M_t; but using M_t makes it
    //   easier to follow the derivation in the text
    mat3 M_t = transpose( M ); 
    float det = dot( cross( M_t[0], M_t[1] ), M_t[2] );
    mat3 adjugate = mat3( cross( M_t[1], M_t[2] ),
                          cross( M_t[2], M_t[0] ),
                          cross( M_t[0], M_t[1] ) );
    return adjugate / det;
}

We can sub­sti­tute the rows of the matrix from above into the code, then expand and sim­plify. This pro­ce­dure results in a new expres­sion for . The deter­mi­nant becomes , and the adju­gate can be writ­ten in terms of two new expres­sions, let’s call them and (with as ‘perp’), which becomes

As you might guessed it, and are the per­pen­dic­u­lars to the tri­an­gle edges in the tri­an­gle plane. Say Hello! They are, again, cov­ec­tors and form a proper basis for cotan­gent space. To sim­plify things fur­ther, observe:

• The last row of the matrix is irrel­e­vant since it is mul­ti­plied with zero.
• The other matrix rows con­tain the per­pen­dic­u­lars ( and ), which after trans­po­si­tion just mul­ti­ply with the tex­ture edge differences.
• The per­pen­dic­u­lars can use the inter­po­lated ver­tex nor­mal instead of the face nor­mal , which is sim­pler and looks even nicer.
• The deter­mi­nant (the expres­sion ) can be han­dled in a spe­cial way, which is explained below in the sec­tion about scale invariance.

Taken together, the opimized code is shown below, which is even sim­pler than the one I had orig­i­nally pub­lished, but still higher quality:

mat3 cotangent_frame( vec3 N, vec3 p, vec2 uv )
{
    // get edge vectors of the pixel triangle
    vec3 dp1 = dFdx( p );
    vec3 dp2 = dFdy( p );
    vec2 duv1 = dFdx( uv );
    vec2 duv2 = dFdy( uv );
 
    // solve the linear system
    vec3 dp2perp = cross( dp2, N );
    vec3 dp1perp = cross( N, dp1 );
    vec3 T = dp2perp * duv1.x + dp1perp * duv2.x;
    vec3 B = dp2perp * duv1.y + dp1perp * duv2.y;
 
    // construct a scale-invariant frame 
    float invmax = inversesqrt( max( dot(T,T), dot(B,B) ) );
    return mat3( T * invmax, B * invmax, N );
}

Scale invari­ance

The deter­mi­nant was left over as a scale fac­tor in the above expres­sion. This has the con­se­quence that the result­ing cotan­gents and are not scale invari­ant, but will vary inversely with the scale of the geom­e­try. It is the nat­ural con­se­quence of them being gra­di­ents. If the scale of the geomtery increases, and every­thing else is left unchanged, then the change of tex­ture coor­di­nate per unit change of posi­tion gets smaller, which reduces and sim­i­larly in rela­tion to . The effect of all this is a dimin­ished per­tu­ba­tion of the nor­mal when the scale of the geom­e­try is increased, as if a height­field was stretched.

Obvi­ously this behav­ior, while totally log­i­cal and cor­rect, would limit the use­ful­ness of nor­mal maps to be applied on dif­fer­ent scale geom­e­try. My solu­tion was and still is to ignore the deter­mi­nant and just nor­mal­ize and to whichever of them is largest, as seen in the code. This solu­tion pre­serves the rel­a­tive lengths of and , so that a skewed or stretched cotan­gent space is sill han­dled cor­rectly, while hav­ing an over­all scale invariance.

Non-​perspective optimization

As the ulti­mate opti­miza­tion, I also con­sid­ered what hap­pens when we can assume and . This means we have a right tri­an­gle and the per­pen­dic­u­lars fall on the tri­an­gle edges. In the pixel shader, this con­di­tion is true when­ever the screen-​projection of the sur­face is with­out per­spec­tive dis­tor­tion. There is a nice fig­ure demon­strat­ing this fact in [4]. This opti­miza­tion saves another two cross prod­ucts, but in my opin­ion, the qual­ity suf­fers heav­ily should there actu­ally be a per­spec­tive distortion.

Putting it together

To make the post com­plete, I’ll show how the cotan­gent frame is actu­ally used to per­turb the inter­po­lated ver­tex nor­mal. The func­tion perturb_normal does just that, using the back­wards view vec­tor for the ver­tex posi­tion (this is ok because only dif­fer­ences mat­ter, and the eye posi­tion goes away in the dif­fer­ence as it is constant).

vec3 perturb_normal( vec3 N, vec3 V, vec2 texcoord )
{
    // assume N, the interpolated vertex normal and 
    // V, the view vector (vertex to eye)
    vec3 map = texture2D( mapBump, texcoord ).xyz;
#ifdef WITH_NORMALMAP_UNSIGNED
    map = map * 255./127. - 128./127.;
#endif
#ifdef WITH_NORMALMAP_2CHANNEL
    map.z = sqrt( 1. - dot( map.xy, map.xy ) );
#endif
#ifdef WITH_NORMALMAP_GREEN_UP
    map.y = -map.y;
#endif
    mat3 TBN = cotangent_frame( N, -V, texcoord );
    return normalize( TBN * map );
}

varying vec3 g_vertexnormal;
varying	vec3 g_viewvector;  // camera pos - vertex pos
varying vec2 g_texcoord;
 
void main()
{
    vec3 N = normalize( g_vertexnormal );
    vec3 V = normalize( g_viewvector );
 
#ifdef WITH_NORMALMAP
    N = perturb_normal( N, V, g_texcoord );
#endif
 
    // ...
}

The green axis

Both OpenGL and DirectX place the tex­ture coor­di­nate ori­gin at the start of the image pixel data. The tex­ture coor­di­nate (0,0) is in the cor­ner of the pixel where the image data pointer points to. Con­trast this to most 3-​D mod­el­ing pack­ages that place the tex­ture coor­di­nate ori­gin at the lower left cor­ner in the uv-​unwrap view. Unless the image for­mat is bottom-​up, this means the tex­ture coor­di­nate ori­gin is in the cor­ner of the first pixel of the last image row. Quite a dif­fer­ence!
An image search on Google reveals that there is no dom­i­nant con­ven­tion for the green chan­nel in nor­mal maps. Some have green point­ing up and some have green point­ing down. My artists pre­fer green point­ing up for two rea­sons: It’s the for­mat that 3ds Max expects for ren­der­ing, and it sup­pos­edly looks more nat­ural with the ‘green illu­mi­na­tion from above’, so this helps with eye­balling nor­mal maps.

Sign Expan­sion

The sign expan­sion deserves a lit­tle elab­o­ra­tion because I try to use signed tex­ture for­mats when­ever pos­si­ble. With the unsigned for­mat, the value 0.5 can­not be rep­re­sented exactly (it’s between 127 and 128). The signed for­mat does not have this prob­lem, but in exchange, has an ambigu­ous encod­ing for -1 (can be either -127 or -128). If the hard­ware is inca­pable of signed tex­ture for­mats, I want to be able to pass it as an unsigned for­mat and emu­late the exact sign expan­sion in the shader. This is the ori­gin of the seem­ingly odd val­ues in the sign expansion.

In Hind­sight

The orig­i­nal arti­cle in ShaderX⁵ was writ­ten as a proof-​of-​concept. Although the algo­rithm was tested and worked, it was a lit­tle expen­sive for that time. Fast for­ward to today and the pic­ture has changed. I am now employ­ing this algo­rithm in real-​life projects for great ben­e­fit. I no longer bother with tan­gents as ver­tex attrib­utes and all the asso­ci­ated com­plex­ity. For exam­ple, I don’t care whether the COLLADA exporter of Max or Maya (yes I’m rely­ing on COLLADA these days) out­put usable tan­gents for skinned meshes, nor do I bother to import them, because I don’t need them! For the artists, it doesn’t occur to them that an aspect of the asset pipeline is miss­ing, because It’s all nat­ural: There is a geom­e­try, there are tex­ture coor­di­nates and there is a nor­mal map, and just works.

Take Away

There are no ‘tan­gent frames’ when it comes to nor­mal map­ping. A tan­gent frame which includes the nor­mal is log­i­cally ill-​formed. All there is are cotan­gent frames in dis­guise when the frame is orthog­o­nal. When the frame is not orthog­o­nal, then tan­gent frames will stop work­ing. Use cotan­gent frames instead.

[1] James Blinn, “Sim­u­la­tion of wrin­kled sur­faces”, SIGGRAPH 1978
http://research.microsoft.com/pubs/73939/p286-blinn.pdf

[2] Mark Peercy, John Airey, Brian Cabral, “Effi­cient Bump Map­ping Hard­ware”, SIGGRAPH 1997
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.42.4736

[3] Mark J Kil­gard, “A Prac­ti­cal and Robust Bump-​mapping Tech­nique for Today’s GPUs”, GDC 2000
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.537

[4] Chris­t­ian Schüler, “Nor­mal Map­ping with­out Pre­com­puted Tan­gents”, ShaderX 5, Chap­ter 2.6, pp. 131 – 140

[5] Colin Barré-​Brisebois and Stephen Hill, “Blend­ing in Detail”,
http://blog.selfshadow.com/publications/blending-in-detail/