Inconsistencias del dispositivo/sistema operativo en los resultados de GLSL ES Phong shader

Question

Apple's Best Practices for OpenGL ES no recomiendan la bifurcación en los resultados calculados en un sombreador de fragmentos. Pero Phong shading generalmente implica omitir el término especular cuando la fuente de luz está en el lado "incorrecto" de la superficie, para lo cual el enfoque directo es salpicar la dirección normal de la unidad N y la dirección de la luz L y verificar que el resultado sea positivo.

he tratado de hacer esto sin una sucursal en mi shader: en lugar de utilizar una declaración if, hago todos los cálculos para el término especular y luego darle un coeficiente que es 1.0 si dot(N, L) es mayor que cero y 0.0 lo contrario . (I lograr esto utilizando la función incorporada step(). Combinando max() y sign() produce los mismos resultados, pero se dice que ser un poco más lenta.)

Sin embargo, esto parecía conducir a iOS impar, dispositivo- y/o versión específica , los resultados:

• en mi iPhone 4 con iOS 6.0, la versión con la rama tiene un reflejo especular de ancho (imagen izquierda); sin la rama, veo un resaltado especular estrecho (imagen derecha), a pesar de que el exponente de "brillo" sigue siendo el mismo.
• En el simulador de iOS 6.0, veo la segunda imagen con ambas versiones del sombreador.
• En mi iPad (modelo original de 2010, atascado en iOS 5.1), veo la primera imagen con ambas versiones del sombreador.

Claramente, el problema no es la ramificación o la falta de ella. (La imagen de la derecha es la traducción "correcta", por cierto.)

Aquí es mi fragmento de sombreado:

precision mediump float; 

uniform lowp vec3 ambientLight; 
uniform lowp vec3 light0Color; 
uniform lowp vec3 materialAmbient; 
uniform lowp vec3 materialDiffuse; 
uniform lowp vec3 materialSpecular; 
uniform lowp float materialShininess; 

// input variables from vertex shader (in view coordinates) 
varying vec3 NormDir; 
varying vec3 ViewDir; 
varying vec3 LightDir; 

void main (void) 
{ 
    vec3 L = normalize(LightDir); 
    vec3 N = normalize(NormDir); 
    vec3 E = normalize(ViewDir); 

    lowp vec3 ambient = ambientLight * materialAmbient; 

    float cos_theta = dot(L, N); 

    lowp vec3 diffuse = materialDiffuse * light0Color * max(0.0, cos_theta); 

    lowp vec3 specular = vec3(0.0, 0.0, 0.0); 
// if (cos_theta > 0.0) { 
     lowp vec3 R = reflect(-L, N); 
     lowp vec3 V = normalize(-E); 
     float cos_alpha = dot(R, V); 
     specular = step(0.0, cos_theta) * materialSpecular * light0Color * pow(max(0.0, cos_alpha), materialShininess); 
     //   ~~~~~~~~~~~~~~~~~~~~~~ 
     //   should produce the same results as the commented branch, right? 
// } 
    gl_FragColor = vec4(ambient + diffuse + specular, 1.0); 
} 

me agrado más sugerencias para mejorar el rendimiento de este shader en el hardware de iOS, también!

Answer 1

Como se señala en el comentario de @ BradLarson, el calificador lowp en materialShininess resultó ser el problema; con eso establecido en mediump, se procesa correctamente (imagen de la derecha) en todos los dispositivos y versiones de sistema operativo que tengo a mano, independientemente de si se utiliza la versión de rama o sin ramificación (con step) del sombreador.

(Usando lowp frente mediump para las entradas R y V de la que cos_alpha se calcula no hace ninguna diferencia visible, lo cual tiene sentido:. Esas son vectores normalizados, por lo que sus componentes tienen magnitudes en el intervalo de 0,0 a 1,0 Eso es el mismo rango que los componentes de color, para los cuales lowp parece estar destinado.)