Cobertura - falla en el algoritmo - ¿cómo deshacerse de su uso?

Introducción

Muchos de los motores de representación de gráficos vectoriales principales tienen un defecto algorítmico. Representan cada forma por separado y antialias calculando la cobertura de píxeles y luego las componen una encima de la otra. Sí, es simple, pero las soluciones correctas son aún más simples.

Esto lleva a un problema de fusión, ya que combina la cobertura por transparencia. La combinación alfa sigue una regla que no representa la situación con precisión, por ejemplo, toma un píxel que está cubierto al 50% que está cerca de un píxel que también está cubierto al 50% de forma complementaria no termina con una cobertura del 100%, termina con una cobertura del 75% . La apariencia de esto depende de cómo se ajuste el algoritmo y otros detalles, pero en esencia se trata de un error conocido. Alguien incluso pasó por la molestia de documentar los diferentes errores del motor junto con la redacción de un documento que muestra cómo podría hacerse mejor.

Imagen 1 : Muestra totalmente no representativa, de renderizar una forma hecha de triángulos que muestra un error ampliado en la fila superior. Fuente SVG

El problema tiene una solución ingenua simple * solo una súper muestra sin cálculo de cobertura y filtra la imagen hacia abajo. Como beneficio adicional, puede utilizar mejores algoritmos de reconstrucción de imágenes que el filtrado de cuadros (lea Un píxel no es un cuadrado ³ ). Incluso hay soluciones que tienen una velocidad comparable a las soluciones actuales y estas soluciones son mucho más fáciles de hacer en las tuberías de rasterización de hardware (y rara vez ve este error en la GPU porque se creó para evitar solo este problema).

Esto tampoco es un problema sin un costo. Hay muchas personas que trabajan en diseño gráfico que pasan una cantidad de tiempo no trivial tratando de sortear este problema manualmente asegurándose de que haya superposición aquí y no superposición allí para solucionar el problema que la computadora debería hacer por ellos. Y fallando espectacularmente en muchos casos. Pero a sus clientes no les importa por qué está el error, deben solucionarlo.

Pregunta

¿Cómo se propaga el error? Como todos están cometiendo el mismo error, se podría concluir que usan la misma fuente para su algoritmo. ¿Qué pudo haber causado que los diseñadores eligieran este algoritmo? ¿Por qué solo los programadores 3D reconocieron este error e incluso codificaron su parte en sus API y enseñanza mientras que los programadores 2D no?

¿Cómo asegurar que este error deje de propagarse más?

Anexo (pero no estoy preguntando sobre esto)

* Aparentemente, mi afirmación de que el súper muestreo funciona sin fallas es extraordinaria y requiere pruebas extraordinarias. Ok, entonces la clave para que funcione el supermuestreo es que el supermuestreo no procesa la cobertura. En esencia, la súper muestra trata cada muestra como una muestra puntual. Dado que la muestra puntual no asume el área subyacente, no está causando una comparación alfa donde no ocurre.

Para que funcione de manera consistente, como se describe en una de las respuestas. Necesitamos hacer que el procesamiento de las muestras con muestreo entero sea coherente. Esto nos asegura que cada punto una vez transformado en espacio de pantalla obtiene exactamente la misma solución para coordenadas iguales y que ninguna muestra está sombreada por un borde de píxel 2 veces. Para hacer esto, es posible que una muestra no active un píxel si está exactamente encendida, por ejemplo, en la parte inferior del lado izquierdo (por lo tanto, establecemos una regla de que los bordes exactos se procesan en> vs <=). Todas las tarjetas gráficas de consola menos una funcionan así. Asegura que no se necesiten datos adicionales en caché y que no se deban realizar pruebas cercanas adicionales. Esta solución es tan estable, más general y consistente que las soluciones basadas en cobertura.

El algoritmo es exactamente el mismo que el original con un poco menos de código y un poco más de muestras. Por lo tanto, es tan consistente, si no más, que el algoritmo basado en la cobertura. Sabemos esto porque hemos estado utilizando estos métodos durante siglos en casi cualquier otro campo de procesamiento de señales, así como en tarjetas gráficas.

Entonces, ¿este método tiene un inconveniente? Bueno, es un poco más lento si solo hicieras una suposición ingenua. Teóricamente tiene un comportamiento asintótico más rápido que el rasterizador de cobertura, aunque es similar a un trazador de rayos, todavía está a la par en escenas típicas. También podría hacer que el uso de efectos basados ​​en convolución sea más doloroso de implementar.

El supermuestreo, cuando se hace ingenuamente, es computacionalmente costoso, ya que si usa, por ejemplo, la mitad del tamaño de píxel de su pantalla, necesitará cuatro veces la memoria y el ancho de banda. Wikipedia menciona esto y también menciona el supermuestreo adaptativo como una posible solución. Pero eso comienza a hacer que el algoritmo sea mucho más sofisticado, complejo y difícil de implementar.

Y supongo que esa es la razón por la que está buscando: si desea un algoritmo que no necesite mucha más memoria y tiempo de ejecución, las cosas se vuelven mucho más complicadas que en el ingenuo enfoque de "transparencia".

El supermuestreo no resolverá el problema en general: simplemente lo hará menos notable. Con píxeles de la mitad del tamaño, el problema será la mitad de notable pero no desaparecerá.

El punto arquitectónico detrás de estos diseños es que queremos que el comando "render triangular ABC" tenga un significado definido. No queremos que sea ambiguo excepto cuando se considera como parte de una colección de comandos de dibujo, por ejemplo, tener un significado cuando "render triangular BCD" también está en la colección (con el mismo color o un color diferente) y otro significado cuando no lo es

Considerando, por ejemplo, mil triángulos, incluso encontrar todos los triángulos que comparten un lado o parte de un lado con ABC es computacionalmente pesado (recordando que tiene que volver a hacerse mil veces). También hay muchos otros problemas prácticos: en particular, que todas las solicitudes de representación originales deben mantenerse, incluso si se elaboraron hace mucho tiempo, en caso de que necesiten ser reevaluados debido a una nueva solicitud adicional.

La conclusión es que una solución perfectamente consistente no es practicable. Queda la pregunta: ¿debemos tratar de mejorar la situación actual cuando podamos? En general, la respuesta a esa pregunta es No. Una implementación perfectamente consistente de un modelo siempre es mejor, incluso si el modelo en sí tiene las limitaciones que usted ha ilustrado. La alternativa sería una implementación que a veces funciona mejor y a veces no, sin que el programador sepa cuál de estos dos va a tener en un caso particular. Además, puede pasar de "mejora" a "no mejora" como resultado de pequeños cambios realizados por el programador, o incluso como resultado de cambios fuera del control del programador. La previsibilidad, en un contexto de programación, está lejos,