opengl - ruido - ¿Es el dibujo de adelante hacia atrás necesario para optimizar los renders?
render de alta calidad en vray sketchup (2)
Estás confundiendo algunos conceptos aquí. No es necesario volver a ordenar los vértices (*). Pero debes dibujar objetos que son opacos de adelante hacia atrás. Esto habilita lo que se denomina "rechazo z inicial" en la GPU. Si la GPU sabe que un pixel no va a ser sombreado por la prueba z, no tiene que ejecutar el sombreador, hacer recuperaciones de texturas, etc. Esto se aplica a los objetos en llamadas de dibujar, no a objetos individuales.
Un simple ejemplo: usted tiene un personaje de jugador y un fondo de cielo. Si dibujas primero al jugador, la GPU nunca tendrá que hacer las búsquedas de textura para los píxeles donde está el jugador. Si lo haces al revés, primero dibujas todo el cielo y luego lo ocultas.
La geometría transparente necesita retroceder al principio del curso.
(*) = los vértices se pueden reordenar para un mejor rendimiento. Pero hacer z temprano es mucho más importante y hecho por objeto.
He visto el artículo ocasional que sugiere ordenar los vértices más cercanos a los más alejados de la cámara al enviarlos a OpenGL (para cualquiera de las variantes de OpenGL). La razón sugerida por esto es que OpenGL no procesará / renderizará un vértice completamente si está detrás de otro vértice ya procesado.
Dado que ordenar vértices por profundidad es un componente costoso de cualquier proyecto, como generalmente este orden cambia con frecuencia, ¿qué tan común o necesario es ese diseño?
Previamente había pensado que OpenGL "miraría" a todos los vértices enviados y procesaría su propio buffer de profundidad en ellos, independientemente de su orden, antes de representar todo el lote. Pero si en realidad se renderiza un vértice en la pantalla antes que en otro, entonces puedo ver cómo el orden podría beneficiar el rendimiento.
¿Es el dibujo de adelante hacia atrás necesario para optimizar los renders?
Una vez que una primitiva se rasteriza, su valor z se puede usar para hacer una "z kill temprana", que omite ejecutar el sombreador de fragmentos. Esa es la razón principal para renderizar de adelante hacia atrás. Sugerencia: cuando tiene polígonos transparentes (con textura alfa), debe renderizar de atrás hacia adelante.
La especificación de OpenGL define una máquina de estado y no especifica en qué orden realmente ocurre la representación, solo que los resultados deben ser correctos (dentro de ciertas tolerancias).
Edite para mayor claridad: lo que trato de decir más arriba es que el hardware puede hacer lo que quiera, siempre que las primitivas parezcan procesadas en orden
Sin embargo, la mayoría de las GPU son procesadores de transmisión y sus controladores OpenGL no "completan" la geometría, excepto tal vez por razones de rendimiento (tamaño mínimo de DMA, etc.). Si introduce en el polígono A seguido del polígono B, se alimentan a la tubería uno después del otro y se procesan de forma independiente (en su mayor parte) el uno del otro. Si hay un número suficiente de polys entre A y B, entonces hay una buena probabilidad de que A complete antes de B, y si B estaba detrás de A, sus fragmentos se descartarán mediante "early z kill".
Edite para mayor claridad: lo que trato de decir más arriba es que, dado que hw no "combina" la geometría, no puede hacer el orden de adelante hacia atrás automáticamente.