Two-side Lighting + Shaders

[DraKKaR]

 Buenas, me gustaría iluminar correctamente las dos caras de un triángulo. El problema es que por vértice solo se puede especificar una normal (la de la cara delantera), por lo que cuando se pinta la cara trasera, la normal que recibo en el vertex shader está invertida.

Hablando en OpenGL: en la pipeline fija puedes especificar el atributo two-side-lighting de modo que automáticamente se invierte la normal de las caras traseras. Sin embargo, usando shaders, parece que esto se lo tiene que currar el usuario. Lo que he hecho ahora es meter en un shader una comprobación de que la normal está mirando en sentido inverso, y en ese caso invertirla. Funciona bien pero se le añaden muchas instrucciones al shader, y creo que una cosa así tiene que tener una solución más elegante y menos fuerza bruta.

Lo ideal sería que OpenGL detectara que estás pintando la cara de atrás e invirtiera automáticamente las normales por vértice, aunque parece que no lo haga.

Estoy seguro que no soy el único que se ha topado con este "problema"... ¿alguna idea?

[Pogacha]

 La solucion mas sencilla y mas al modo OpenGL seria dibujar las caras de adelante, cambiar de shader y luego las de atras...

[DraKKaR]

 Ya había pensado esa solución, pero no me sirve, se trata de modelos con bastantes polígonos y no podemos permitirnos doblar el número de vértices a procesar.

[BeRSeRKeR]

 Renderman utiliza la técnica que dices que estás utilizando a través de la función faceForward. Se le pasa el vector normal y el vector "view" y entonces se hace un dot product para saber si la normal está encarando la cámara. Si no la encara, se invierte la normal y listo. Evidentemente Renderman es una especificación para renderers offline, pero no sé hasta que punto puede llegar a ser costoso un producto escalar en un vertex shader.

Luego tienes los documentos que hay en nVidia sobre iluminación "two-sided" que utilizan otra técnica que creo que es la que menciona Pogacha.

Saludos.

[Pogacha]

Ya había pensado esa solución, pero no me sirve, se trata de modelos con bastantes polígonos y no podemos permitirnos doblar el número de vértices a procesar.

Pero a los vertices los procesas una vez tan solo ... con el face culling cuando una cara esta del lado "apagado" no se procesa ... si no confias en esto lo puedes hacerlo mediante software y seria un producto punto mas suma por cara. A no ser que estemos hablando de caras transparentes  O_O  !? No creo ... verdad?
Con el tema de las sombras por stencil existe la extención de stencil de dos lados que permite operaciones distintas para distintos lados de las caras con respecto a la camara y es lo unico que conozco con respecto a este tema ...
Y la opcion que dice BeRSeRKeR tambien es muy valida y muy sencilla tambien:

Código [Seleccionar] Expand

normal*=punto(normal,view);
normal. normalizar();
Que supongo que es lo que hará el opengl con el fixed  pipeline
Saludos.

[DraKKaR]

 Sí, al final eso es lo que he hecho, sólo quería asegurarme de que no habia una forma automática de obtener las normales correctas desde el vertex shader sin tener que engordar el programa.

[Pogacha]

 Eso cual?
Lo de agregar 3 lineas al vertex shader?
o hacer 2 pasadas?

Ahora estoy convencido que lo mejor es lo de agregar 3 lineas al vertex shader!
Saludos.

[DraKKaR]

 Lo del vertex shader. Aunque no han sido solo 3 lineas, sino que he tenido que convertir la normal y el vertice al eye-space. Aunque estoy seguro que puedo reorganizarlo para hacer menos operaciones en el vertex shader.

[BeRSeRKeR]

 Para invertir la normal me imagino que lo más rápido será:

N *= sign(dot(N, V));

Y con respecto a transformar la normal y el vértice a eye space lo tendrías que hacer igualmente aunque no hagas two-sided lighting, si es que estás calculando la iluminación en eye-space, ¿no?.

Saludos.

[DraKKaR]

 Sí lo ideal sería calcular la iluminación por píxel en eye-space, aunque ahora mismo no se hace así. Por eso digo que tengho que cambiar la organización de qué se hace en el vertex sahder y qué se envia al pixel shader.