Couverture - faille dans l'algorithme - comment se débarrasser de son utilisation?

introduction

La plupart des moteurs de rendu de graphiques vectoriels principaux comportent une faille algorithmique. Ils rendent chaque forme séparément et anticrénelent en calculant la couverture en pixels, puis les composent les uns sur les autres. Oui c'est simple mais les bonnes solutions sont encore plus simples.

Cela conduit à un problème de confusion car il confond la couverture par la transparence. Le mélange alpha suit une règle qui ne représente pas la situation avec précision, par exemple prendre un pixel couvert à 50% qui est voisin d'un pixel qui est également couvert à 50% ne se termine pas avec une couverture de 100% il se retrouve avec une couverture de 75% . À quoi cela ressemble dépend de la façon dont l'algorithme est réglé et d'autres détails, mais c'est essentiellement une erreur connue. Quelqu'un a même eu la peine de documenter les différentes erreurs de moteur et d'écrire un document montrant comment cela pourrait être mieux fait.

Image 1 : Échantillon totalement non représentatif, de rendu d'une forme faite de triangles montrant une erreur agrandie sur la ligne supérieure. Source SVG

Le problème a une solution naïve simple * juste un super échantillon sans calcul de couverture et filtrer l'image vers le bas. En prime, vous pouvez utiliser de meilleurs algorithmes de reconstruction d'image que le filtrage de boîtes (lire Un pixel n'est pas un carré ³ ). Il existe même des solutions qui ont une vitesse comparable à celle des solutions actuelles et ces solutions sont beaucoup plus faciles à faire dans les pipelines de rastérisation matérielle (et vous voyez rarement cette erreur sur le GPU car il est conçu pour éviter ce problème).

Ce n'est pas non plus un problème sans coût. De nombreuses personnes travaillant dans la conception graphique passent beaucoup de temps à essayer de contourner ce problème manuellement en s'assurant qu'il y a chevauchement ici et pas de chevauchement pour résoudre le problème que l'ordinateur devrait faire pour eux. Et échouant de façon spectaculaire dans de nombreux cas. Mais leurs clients ne se soucient pas de la raison de l'erreur, ils doivent la corriger.

Question

Comment l'erreur se propage-t-elle? Puisqu'ils font tous la même erreur, on pourrait conclure qu'ils utilisent la même source pour leur algorithme. Qu'est-ce qui aurait pu pousser les concepteurs à choisir cet algorithme? Pourquoi seuls les programmeurs 3D ont-ils reconnu cette erreur et même codifié sa part dans leurs API et leur enseignement alors que les programmeurs 2D ne l'ont pas fait?

Comment s'assurer que cette erreur cesse de se propager davantage?

Addendum (mais je ne pose pas de question à ce sujet)

* Apparemment, mon affirmation selon laquelle le super échantillonnage fonctionne sans défaut est extraordinaire et nécessite une preuve extraordinaire. Ok, donc la clé du fonctionnement du super échantillonnage est que le super échantillonnage ne fait pas de traitement de couverture. Essentiellement, le super échantillonneur traite chaque échantillon comme un échantillon ponctuel. Étant donné que l'échantillon ponctuel ne fait aucune hypothèse sur la zone sous-jacente, il ne provoque pas de comparaison alpha là où cela ne se produit pas.

Pour que cela fonctionne de manière cohérente, comme décrit dans l'une des réponses. Nous devons faire pour traiter les échantillons avec un échantillonnage entier pour la cohérence. Cela nous assure que chaque point une fois transformé en espace d'écran obtient exactement la même solution pour des coordonnées égales et qu'aucun échantillon n'est ombré par une bordure de pixel 2 fois. Pour ce faire, un échantillon peut ne pas déclencher un pixel ot est exactement activé s'il s'agit par exemple de l'échantillon inférieur gauche (nous établissons donc une règle selon laquelle les bords exacts sont traités dans> vs <=). Toutes les cartes graphiques de console sauf une fonctionnent comme ceci. Il garantit qu'aucune donnée supplémentaire ne doit être mise en cache et qu'aucun test supplémentaire à proximité ne doit être effectué. Cette solution est aussi stable, plus générale et cohérente que les solutions basées sur la couverture.

L'algorithme est exactement le même que l'original avec un peu moins de code et un peu plus d'échantillons. Il est donc aussi cohérent sinon plus que l'algorithme basé sur la couverture. Nous le savons parce que nous utilisons ces méthodes depuis des lustres dans presque tous les autres domaines de traitement du signal ainsi que les cartes graphiques.

Cette méthode a-t-elle donc un inconvénient? Eh bien, c'est un peu plus lent si vous faites simplement une supposition naïve. Il a théoriquement un comportement asymptotique plus rapide que le rastériseur de couverture, un peu comme un raytracer, il n'est toujours qu'au pair dans les scènes typiques. Cela pourrait également rendre l'utilisation d'effets basés sur la convolution plus difficile à mettre en œuvre.

Le suréchantillonnage, quand il est fait naïvement, est coûteux en calcul, car si vous utilisez par exemple la moitié de la taille en pixels de votre écran, vous avez besoin de quatre fois la mémoire et la bande passante. Wikipedia le mentionne et nomme également le suréchantillonnage adaptatif comme solution possible. Mais cela commence à rendre l'algorithme beaucoup plus sophistiqué, complexe et plus difficile à mettre en œuvre.

Et je suppose que c'est la raison que vous cherchez: si vous voulez un algorithme qui n'a pas besoin de beaucoup plus de mémoire et de temps d'exécution, les choses deviennent beaucoup plus compliquées que dans l'approche naïve de "transparence".

Le suréchantillonnage ne résoudra pas le problème en général: il le rendra simplement moins visible. Avec des pixels deux fois plus petits, le problème sera moitié moins visible, mais il ne disparaîtra pas.

Le point architectural derrière ces conceptions est que nous voulons que la commande "rendre le triangle ABC" ait une signification définie. Nous ne voulons pas qu'il soit ambigu, sauf lorsqu'il est considéré comme faisant partie d'une collection de commandes de dessin - par exemple, avoir une signification lorsque «rendre le triangle BCD» est également dans la collection (avec la même couleur ou une couleur différente) et une autre signification lorsque ça ne l'est pas.

Considérant, par exemple, un millier de triangles, même trouver tous les triangles qui partagent un côté ou une partie d'un côté avec ABC est un calcul lourd (en se rappelant qu'il doit être refait mille fois). Il existe également de nombreux autres problèmes pratiques: notamment que toutes les demandes de rendu d'origine doivent être conservées, même si elles ont été dessinées il y a longtemps, au cas où elles devraient être réévaluées en raison d'une nouvelle demande supplémentaire.

L'essentiel est qu'une solution parfaitement cohérente n'est pas possible. Reste la question: devons-nous essayer d'améliorer la situation actuelle quand nous le pouvons? En général, la réponse à cette question est non . Une implémentation parfaitement cohérente d'un modèle est toujours meilleure, même si le modèle lui-même présente les limites que vous avez illustrées. L'alternative serait une implémentation qui fait parfois mieux et parfois pas, sans aucun moyen pour le programmeur de savoir lequel de ces deux va tenir dans un cas particulier. De plus, il peut passer de «fait mieux» à «ne fait pas mieux» à la suite de minuscules modifications apportées par le programmeur - ou même à la suite de modifications indépendantes de sa volonté. La prévisibilité, dans un contexte de programmation, est loin,