Normal Maps

La tecnología del normalMap se basa en codificar las normales de un objeto en una textura en vez de alimentarse exclusivamente de la información de normales que se encuentran en los polígonos.
Entonces, si tenemos un modelo en alta resolución y una equivalencia en baja resolución, podemos codificar y almacenar la información de las normales de modelo en alta (HP) hacia el modelo en baja (LP) en una textura que se llama normalMap.
Existen tres tipos de normalMaps, pero a la práctica sólo se usa uno.

NormalMap en worldSpace:
Su aspecto es parecido al de un arco iris. Su utilidad es limitada porque la información de las normales está referenciada a las coordenadas globales. Si rotáramos el objeto dejaría de estar alineado con las coordenadas globales y la iluminación sobre éste sería errónea .

NormalMap en objectSpace:

Es muy parecido al anterior en todos los aspectos, con la mejoría de que los objetos que lo usan pueden moverse en el espacio, pero no pueden sufrir deformación por vertex

NormalMap in tangent space:
Este es el formato que se utiliza siempre en aplicaciones en realTime. Su ventaja es que está referenciado polígono a polígono, por lo que soporta cualquier tipo de movimiento o deformación.

En esta imagen se puede entender bien el funcionamiento y las limitaciones del normalMap. El funcionamiento es lo comentado: codificar la información de normales de una a otra malla. En cuanto a las limitaciones... todo se basa en que las normales de un objeto no definen su silueta, y es ahí donde el normalMap no puede ofrecernos nada. En la imagen superior se puede observar perfectamente: la silueta interior de la concavidad del objeto fuente (aquel del cual extraemos las normales) no puede codificarse mediante el normalMap. Por lo que cuan más bajo-relieve sea la información de normales que intentamos codificar, mejor.

Pero como se lee un normalMap en tangentSpace?

Es fácil de entender si lo analizamos canal por canal.

En el canal R se codifica la desviación de la normal respecto a la normal del polígono en el ejeX, siendo el gris (R al 50%) el valor sin desviación respecto a la normal original. Del gris al blanco se inclina en un sentido y hacia el negro en el otro. El canal G funciona exactamente igual que el R con la diferencia que recoge las desviaciones de la normal en el ejeY. El canal B, sin embargo, es un misterio para mi. He leído que es una especie de heightMap que por otro lado, no se parece demasiado a un heightMap real. También podría ser el resultado al normalizar el valor del vector obtenido sin modificar los valores de R y G; p.ej.: R=0.1 y G=0.6 => vectorTangente = (0.1,0.6,B), donde B=valor para obtener un vector normalizado. Se trata sólo de una hipótesis personal y, como habréis notado, mi campo no es el álgebra.  La cuestión es que, sea como sea, B siempre da unos valores muy cercanos al blanco.