Tweet
J'ai traduit (avec DeepL bien sûr) ce post de JusteSid qui bosse sur cette partie chez Laminar.
J'ai un peu mieux compris.
Vers le milieu...
J'espère que les images resteront à leur place.
Tout n'est pas parfait !
Je devrais probablement écrire sur l'AA dans un article de blog, mais je pourrais essayer d'éclaircir un peu les choses. Commençons par les bases, qu'est-ce que l'aliasing et pourquoi cela se produit-il ?
Fondamentalement, il s'agit d'un problème d'échantillonnage et de fréquence (c'est le seul paragraphe à caractère scientifique, sautez cette partie et il y aura des images). Toute personne ayant vaguement touché aux fréquences connaît probablement le théorème d'échantillonnage de Nyquist et Shannon, nom donné au fait que deux scientifiques nommés Harry Nyquist et Claude Shannon ont gâché le plaisir de tout le monde. En résumé, si vous voulez échantillonner un signal discret, votre fréquence d'échantillonnage doit être égale à deux fois la fréquence du signal, sinon vous obtiendrez des artefacts de l'aliasing, c'est-à-dire que vous ne serez pas en mesure de représenter le signal avec précision. Ce principe a de nombreuses implications dans de nombreux domaines, mais il concerne également les jeux vidéo. Le tramage d'une image consiste simplement à prendre un signal d'entrée discret et à l'échantillonner à un taux spécifique, c'est-à-dire une fois par pixel. C'est fondamentalement ce qui provoque l'aliasing
Nous pouvons tous comprendre cela intuitivement et puisque vous m'avez suivi, voici une image pour le démontrer :
Voici une grille de pixels zoomée sur laquelle sont tracées 4 lignes. J'ai rempli la grille de pixels avec des carrés rouges et la ligne est en bleu au-dessus. La ligne horizontale est parfaite parce qu'elle s'aligne bien sur la grille, mais les lignes inclinées sont une toute autre histoire. Il s'agit de l'aliasing et, bien sûr, pour le tramage des lignes, il y a plusieurs façons d'atténuer ce phénomène et différents compromis que vous pouvez faire pour que les lignes soient tramées d'une manière qui leur donne une bonne apparence.
Mais que vous placiez une ligne ou un triangle sur la grille de pixels, il y a de fortes chances que la grille et ce que vous essayez d'y projeter ne s'alignent pas correctement. Voici une vue très agrandie du cockpit du MD-80 :
Et voici la vue filaire de la même zone :
Les bords des vertex ne s'alignent pas du tout sur la grille de pixels, ce qui donne lieu à des artefacts de marches d'escalier (aliasing).
D'accord, nous avons abordé les causes de l'aliasing. Qu'est-ce qui est si difficile à résoudre ? Les questions fondamentales de physique qui sont en jeu ici. Ce n'est pas parce qu'on a l'impression que les jeux vidéo n'ont rien à voir avec le traitement du signal qu'en réalité ils ont tout à voir avec lui. Mais attendez, dites-vous, les jeux ont clairement un anti-crénelage et cela fonctionne. De même, X-Plane a un anti-crénelage qui peut fonctionner ou non, selon la personne à qui vous posez la question (mais je crois que nous sommes tous d'accord pour dire qu'il fait quelque chose).
Il existe plusieurs astuces pour lutter contre l'aliasing. La plus simple est le SSAA (Super Sampling Anti Aliasing). Vous vous souvenez que le problème fondamental est que la fréquence d'échantillonnage est tout simplement trop basse ? Le SSAA augmente simplement la taille de l'image rendue, augmentant ainsi la fréquence d'échantillonnage, car vous avez maintenant plus de pixels pour la même zone cible, c'est-à-dire votre écran. Le problème du SSAA est l'extensibilité : alors que la fréquence d'échantillonnage augmente linéairement, la mémoire et le coût de traitement augmentent au carré. Supposons que vous souhaitiez obtenir une image 1080p, la résolution est de 1920x1080, soit 2 073 600 pixels au total. À raison de 4 octets par pixel (un octet par canal de couleur plus un octet supplémentaire pour le canal alpha, la plupart des GPU ne prenant pas en charge les formats de couleur RVB pour des raisons d'alignement), l'image pèse 7,9 Mo.
Supposons maintenant que nous voulions avoir 2x SSAA ou deux fois la fréquence d'échantillonnage, nous devons maintenant ombrer 3840x2160 = 8 294 400 pixels au total pour un coût de 31,6 mégaoctets. Vous obtenez une fréquence d'échantillonnage 2x pour 4x la quantité de pixels et 4x la quantité de mémoire. Et c'est à 1080 ! Je sais que le SSAA de la v11 manque aux gens, mais jouez avec ces chiffres et gardez à l'esprit que les gens ont tendance à avoir des moniteurs beaucoup plus grands. Le SSAA est incroyablement cher pour ce qu'il est et il n'est tout simplement pas extensible. C'est la raison pour laquelle on a l'impression que les jeux étaient beaucoup plus performants avec de meilleurs graphismes, beaucoup de techniques s'adaptent assez bien avec de petits nombres, mais une fois que vous atteignez les tailles d'écran modernes et les objectifs de taux d'images, les choses tombent à l'eau. C'est la physique de l'économie, stupide
Restons-en à ce que X-Plane vous offre, FXAA est le prochain sur la liste. FXAA ou (Post) Effects Anti Aliasing n'est pas vraiment une technique qui tente d'empêcher l'aliasing. Il s'agit plutôt d'une technique qui s'exécute au-dessus d'une image aliasée et qui lisse les bords tranchants. Il s'agit essentiellement d'une détection des bords et d'une moyenne des valeurs des pixels où des discontinuités (c'est-à-dire des bords) sont détectées. Cette opération est incroyablement peu coûteuse et ne nécessite pas de mémoire puisqu'elle s'exécute sur place. Mais il n'a aucune connaissance de la scène, ce qui peut entraîner des problèmes en cours de route. Les instruments flous sont probablement le cas le plus connu pour X-Plane et sont causés, une fois de plus, par Shannon et Nyquist : les instruments existent dans leur propre texture qui est ensuite projetée dans la scène 3D, généralement sous différents angles, mais la plupart du temps, elle finit par être projetée beaucoup plus petite qu'elle ne l'était à l'origine. Prenez un G1000 par exemple, je crois qu'il tourne à 1024x768, mais est-ce que vous lui donnez autant d'espace à l'écran ? Si vous travaillez en 1080p, ce n'est certainement pas le cas, à moins que vous n'ayez que le G1000 en vue. Le mappage de cet instrument à l'écran fait perdre des informations qui étaient présentes auparavant mais qui ne peuvent pas être entièrement représentées à l'écran, puis FXAA examine les morceaux, détecte les bords et les lisse. FXAA ne peut pas rattraper les informations perdues auparavant et le mappage des triangles à l'écran est un processus avec perte, vous ne récupérez pas ces informations et vous êtes triste parce que vos instruments sont flous. Cependant, si vous avez un écran 4k, il y a de fortes chances que l'information soit très claire. Cependant, si vous avez un écran 4k, il y a de fortes chances que l'information soit très proche d'être mappée 1:1. FXAA est donc une excellente option car il peut lisser les bords irréguliers qui sont présents et même si ce processus perd également de l'information, vous ne commencez pas avec un chapeau pratique ayant déjà perdu un tas d'informations avant cela.
Et maintenant, celui que les gens détestent le plus : MSAA. Multi Sample Anti Aliasing. Nous revenons à de vraies techniques anti-crénelage (réelles dans ce cas, cela signifie qu'elles essaient de ne pas perdre d'informations plutôt que d'essayer de faire disparaître les informations perdues). Permettez-moi de commencer en disant ceci : Le MSAA est implémenté dans le matériel, il ne peut pas être implémenté dans le logiciel. Le MSAA dans X-Plane n'est pas "mauvais" parce que les idiots de LR ne savent pas comment nuancer les shaders. Il est intégré dans le matériel de votre GPU et tous les jeux ont la même implémentation du MSAA. Le MSAA tente de rectifier le problème de traitement du SSAA. Vous vous souvenez que le problème était que nous produisions plus de pixels au total ? Eh bien, la production des pixels est la partie la plus coûteuse en termes de calcul, alors que se passerait-il si nous n'en produisions pas ? Le MSAA utilise un masque de couverture pour chaque pixel, divise chaque pixel en plusieurs échantillons, puis détermine lequel de ces échantillons est couvert par un triangle. Cela fait un certain temps, alors voici une image pour que tout le monde soit encore d'accord avec moi :
(L'org est malheureusement en train de manger la qualité de celle-ci)
Il s'agit d'une grille hypothétique de 3x3 pixels, les signes + noirs au milieu sont le centre du pixel, la ligne jaune est le bord d'un triangle qui traverse la grille et j'implique que le triangle couvre la moitié inférieure droite de la grille. Le rouge et le vert + au milieu de la grille sont les échantillons pour ce pixel (mais ils ont été créés pour la démonstration, les masques de couverture ont tendance à avoir des formes différentes pour ne pas être biaisés dans une direction particulière). L'idée est simple, dans ce cas le rasterizer du GPU sait que pour le pixel du milieu, le triangle couvre l'échantillon vert et ne couvre pas du tout l'échantillon rouge. Les pixels du milieu inférieur, de droite et du milieu droit sont entièrement dans le triangle avec les deux échantillons (non dessinés) et leurs homologues de l'autre côté sont entièrement à l'extérieur. Le GPU stocke toutes ces informations, ce qui signifie que le coût de la mémoire augmente toujours par le carré, car au lieu d'un pixel, vous avez maintenant N échantillons. Mais ce n'est pas le cas du traitement, car le GPU n'a pas besoin de calculer un pixel plus d'une fois, mais seulement de mettre à jour les échantillons sous-pixels pendant le rendu.
La dernière étape du MSAA consiste à le résoudre, c'est-à-dire à faire la moyenne des échantillons et à l'utiliser comme couleur finale du pixel. En termes de traitement, c'est essentiellement gratuit, vous n'avez pas à envoyer un milliard d'invocations de shaders supplémentaires juste pour ombrer des pixels avec des valeurs qui n'ont pas d'importance. Sauf que...
Le MSAA fonctionne fondamentalement parce que le matériel sait où se trouvent les bords du triangle. Mais il commence à tomber à plat avec la géométrie transparente, parce que soudainement le truc de couverture cool ne fonctionne plus parce que la transparence est à l'intérieur de la géométrie. Si vous vous souvenez de l'époque antérieure à la version 12.1, les clôtures en mailles et les feuilles d'arbres avaient un très mauvais aspect avec le MSAA, simplement parce que le MSAA fonctionne sur la géométrie et que les feuilles/clôtures en mailles sont des géométries plates avec des trous percés via le canal alpha. La version 12.1 a amélioré le MSAA car elle utilise les techniques alpha-to-coverage et alpha-to-one, deux techniques qui atténuent ce problème. La technique alpha-to-coverage utilise essentiellement la valeur alpha renvoyée pour déterminer le nombre d'échantillons couverts et la technique alpha-to-one remet la valeur alpha à 1 après la distribution des échantillons afin d'éviter les artefacts de mélange. Telles sont les améliorations apportées par la version 12.1.
Mais bien sûr, activer le MSAA n'est pas gratuit en termes de traitement, malgré tous mes efforts pour prétendre le contraire il y a 5 secondes. L'écriture des valeurs MSAA est essentiellement gratuite, mais les jeux ne se contentent pas d'écrire les valeurs finales des pixels sur l'écran et de s'arrêter là. X-Plane et la plupart des jeux modernes utilisent le rendu différé, où l'image est composée avec quelques étapes supplémentaires. L'une des choses les plus coûteuses que vous puissiez faire est le calcul de la lumière. Ainsi, au lieu d'ombrer complètement chaque pixel, X-Plane stockera les métadonnées de chaque pixel, à savoir la couleur de l'albédo, les normales de la surface, les valeurs émissives et les valeurs du matériau. Cela signifie que toutes ces valeurs doivent être stockées quelque part pendant que la scène est composée, mais cela résout le problème du surdessin. Imaginez que vous dessiniez d'abord la piste d'atterrissage, puis l'avion, ce serait un gaspillage d'ombrer complètement chaque pixel de la piste d'atterrissage pour ensuite le remplacer par des pixels d'avion entièrement ombrés quelques étapes plus tard. Au lieu de cela, les informations de la scène sont extraites dans ce que l'on appelle le tampon g. Une fois que la scène est entièrement composée, on passe en revue chaque pixel et on convertit ces métadonnées en pixel entièrement ombré.Et c'est là que les choses se compliquent. Parce que pour ombrer précisément chaque pixel, le shader d'éclairage doit consommer la surface MSAA et s'exécuter par échantillon. Il ne connaît pas les données de couverture de la surface pour savoir quels échantillons proviennent tous du même triangle et n'ont donc pas besoin d'être ombrés par échantillon, ce qui fait que le coût de traitement augmente encore par carré. Pire encore, ce que j'ai écrit ci-dessus est une vaste simplification de la façon dont X-Plane affiche une image à l'écran. Il y a beaucoup de cibles de rendu intermédiaires et bien que tout ne doive pas être traité par échantillon, c'est le cas de la plupart des choses. Voici le graphique de la façon dont X-Plane affiche une image à l'écran :
Nous appelons cela affectueusement le dag. J'appelle cela "compression h#### de l'org".
Edit : Btw, c'est la raison pour laquelle le MSAA forcé par le pilote est plus rapide. Puisque le MSAA est implémenté dans le matériel, le pilote peut simplement l'activer pour une cible de rendu qu'il sélectionne (très probablement la mauvaise, btw) et ensuite le résoudre à sa propre discrétion. Mais X-Plane n'est pas dans la boucle ici, donc il n'exécutera pas de traitement par échantillon, mais seulement par échantillon. Le résultat final est un ombrage incorrect mais des performances plus rapides. C'est à vous de décider si c'est acceptable ou non.
Mais pourquoi le MSAA ne résout-il pas tous les jaggies ? Pourquoi le sol semble-t-il parfois très irrégulier lorsqu'il est mouillé, pourquoi les reflets sont-ils parfois très mauvais et pourquoi les bords de mes ailes semblent-ils parfois irréguliers ? Le MSAA est sûrement capable de résoudre ces problèmes ?
Voici un exemple, regardez les bords déchiquetés avec le contour bleu ! Il s'agit sûrement d'arêtes de vertex et elles devraient donc bénéficier de MSAA, n'est-ce pas ? La réponse est oui, et en fait, voici le secret : cette barre est anti aliasée. Je peux le prouver aussi, voici à quoi elle ressemble dans le tampon g (et donc non ombrée) :I Promis, le MSAA fait parfaitement son travail ici, pas de bord déchiqueté malgré un angle assez faible.
Le problème est que... Vous ne regardez pas un défaut du MSAA, vous regardez XPD-15050. Le problème est que le post-traitement qui éclaire la scène récupère des reflets du ciel pour cet objet, juste parce que la barre est inclinée vers le haut et pointe vaguement dans cette direction. Et certains des pixels présents mangent des reflets du ciel. C'est pourquoi l'image non éclairée semble nette. Il s'agit d'un défaut de plusieurs choses, principalement de l'implémentation actuelle du SSR. Une fois de plus, Shannon et Nyquist sont à blâmer.Ainsi, lorsque vous dites que "LR ne sait pas comment mettre en œuvre l'anti-crénelage correctement",
je grimace un peu parce que tous les bords irréguliers n'ont pas qu'une seule cause. Le MSAA fonctionne parfaitement et fait bien son travail, mais il ne peut rien faire contre les artefacts de crénelage introduits plus tard dans le pipeline de rendu. FXAA peut en fait faire un peu de travail ici parce qu'il fonctionne dans une étape de post-traitement sur l'image finale, mais il ne supprimera pas l'information qui ne devrait pas être là en premier lieu, il se contentera de la lisser un peu. Mais ce problème est résolu par l'implémentation d'un SSR plus intelligent, ce qui semble plus facile qu'il ne l'est pour la même raison que toutes les autres techniques d'AA semblent toujours plus faciles qu'elles ne le sont.
Il y a d'autres choses que je pourrais aborder ici, comme le TAA et d'autres techniques anti-crénelage. Mais cela devient déjà un peu long pour ce que je pensais être un simple commentaire de 5 minutes sur les raisons pour lesquelles l'anti-crénelage est plus difficile que ce que tout le monde veut bien croire. Fondamentalement, la limite est physique. Et je n'excuse rien ici, les artefacts sont ennuyeux et devraient être corrigés. Mais je dirai ceci : avant d'être embauché chez LR il y a 8 ans, je suis arrivé en pensant que tout le monde était stupide et que je pouvais résoudre tous les problèmes de X-Plane facilement (pour ma défense, j'avais 8 ans de moins et 8 ans d'abrutissement). Il s'avère qu'une fois sur le terrain, les choses ne sont pas aussi faciles qu'elles le paraissent et la plupart des gens chez LR sont en fait très intelligents. Ils sont également très passionnés et conscients de toutes les lacunes. Nous voulons que X-Plane soit meilleur et j'espère que nous le démontrons à chaque nouvelle version. En attendant, ne retenez pas votre souffle sur des corrections d'AA pour la 12.2, mais soyez assurés que nous sommes 1) conscients du besoin d'un meilleur AA et 2) que ce n'est pas aussi facile que d'appuyer sur un interrupteur.
J'ai un peu mieux compris.
Vers le milieu...
J'espère que les images resteront à leur place.
Tout n'est pas parfait !
Je devrais probablement écrire sur l'AA dans un article de blog, mais je pourrais essayer d'éclaircir un peu les choses. Commençons par les bases, qu'est-ce que l'aliasing et pourquoi cela se produit-il ?
Fondamentalement, il s'agit d'un problème d'échantillonnage et de fréquence (c'est le seul paragraphe à caractère scientifique, sautez cette partie et il y aura des images). Toute personne ayant vaguement touché aux fréquences connaît probablement le théorème d'échantillonnage de Nyquist et Shannon, nom donné au fait que deux scientifiques nommés Harry Nyquist et Claude Shannon ont gâché le plaisir de tout le monde. En résumé, si vous voulez échantillonner un signal discret, votre fréquence d'échantillonnage doit être égale à deux fois la fréquence du signal, sinon vous obtiendrez des artefacts de l'aliasing, c'est-à-dire que vous ne serez pas en mesure de représenter le signal avec précision. Ce principe a de nombreuses implications dans de nombreux domaines, mais il concerne également les jeux vidéo. Le tramage d'une image consiste simplement à prendre un signal d'entrée discret et à l'échantillonner à un taux spécifique, c'est-à-dire une fois par pixel. C'est fondamentalement ce qui provoque l'aliasing
Nous pouvons tous comprendre cela intuitivement et puisque vous m'avez suivi, voici une image pour le démontrer :
Voici une grille de pixels zoomée sur laquelle sont tracées 4 lignes. J'ai rempli la grille de pixels avec des carrés rouges et la ligne est en bleu au-dessus. La ligne horizontale est parfaite parce qu'elle s'aligne bien sur la grille, mais les lignes inclinées sont une toute autre histoire. Il s'agit de l'aliasing et, bien sûr, pour le tramage des lignes, il y a plusieurs façons d'atténuer ce phénomène et différents compromis que vous pouvez faire pour que les lignes soient tramées d'une manière qui leur donne une bonne apparence.
Mais que vous placiez une ligne ou un triangle sur la grille de pixels, il y a de fortes chances que la grille et ce que vous essayez d'y projeter ne s'alignent pas correctement. Voici une vue très agrandie du cockpit du MD-80 :
Et voici la vue filaire de la même zone :
Les bords des vertex ne s'alignent pas du tout sur la grille de pixels, ce qui donne lieu à des artefacts de marches d'escalier (aliasing).
D'accord, nous avons abordé les causes de l'aliasing. Qu'est-ce qui est si difficile à résoudre ? Les questions fondamentales de physique qui sont en jeu ici. Ce n'est pas parce qu'on a l'impression que les jeux vidéo n'ont rien à voir avec le traitement du signal qu'en réalité ils ont tout à voir avec lui. Mais attendez, dites-vous, les jeux ont clairement un anti-crénelage et cela fonctionne. De même, X-Plane a un anti-crénelage qui peut fonctionner ou non, selon la personne à qui vous posez la question (mais je crois que nous sommes tous d'accord pour dire qu'il fait quelque chose).
Il existe plusieurs astuces pour lutter contre l'aliasing. La plus simple est le SSAA (Super Sampling Anti Aliasing). Vous vous souvenez que le problème fondamental est que la fréquence d'échantillonnage est tout simplement trop basse ? Le SSAA augmente simplement la taille de l'image rendue, augmentant ainsi la fréquence d'échantillonnage, car vous avez maintenant plus de pixels pour la même zone cible, c'est-à-dire votre écran. Le problème du SSAA est l'extensibilité : alors que la fréquence d'échantillonnage augmente linéairement, la mémoire et le coût de traitement augmentent au carré. Supposons que vous souhaitiez obtenir une image 1080p, la résolution est de 1920x1080, soit 2 073 600 pixels au total. À raison de 4 octets par pixel (un octet par canal de couleur plus un octet supplémentaire pour le canal alpha, la plupart des GPU ne prenant pas en charge les formats de couleur RVB pour des raisons d'alignement), l'image pèse 7,9 Mo.
Supposons maintenant que nous voulions avoir 2x SSAA ou deux fois la fréquence d'échantillonnage, nous devons maintenant ombrer 3840x2160 = 8 294 400 pixels au total pour un coût de 31,6 mégaoctets. Vous obtenez une fréquence d'échantillonnage 2x pour 4x la quantité de pixels et 4x la quantité de mémoire. Et c'est à 1080 ! Je sais que le SSAA de la v11 manque aux gens, mais jouez avec ces chiffres et gardez à l'esprit que les gens ont tendance à avoir des moniteurs beaucoup plus grands. Le SSAA est incroyablement cher pour ce qu'il est et il n'est tout simplement pas extensible. C'est la raison pour laquelle on a l'impression que les jeux étaient beaucoup plus performants avec de meilleurs graphismes, beaucoup de techniques s'adaptent assez bien avec de petits nombres, mais une fois que vous atteignez les tailles d'écran modernes et les objectifs de taux d'images, les choses tombent à l'eau. C'est la physique de l'économie, stupide
Restons-en à ce que X-Plane vous offre, FXAA est le prochain sur la liste. FXAA ou (Post) Effects Anti Aliasing n'est pas vraiment une technique qui tente d'empêcher l'aliasing. Il s'agit plutôt d'une technique qui s'exécute au-dessus d'une image aliasée et qui lisse les bords tranchants. Il s'agit essentiellement d'une détection des bords et d'une moyenne des valeurs des pixels où des discontinuités (c'est-à-dire des bords) sont détectées. Cette opération est incroyablement peu coûteuse et ne nécessite pas de mémoire puisqu'elle s'exécute sur place. Mais il n'a aucune connaissance de la scène, ce qui peut entraîner des problèmes en cours de route. Les instruments flous sont probablement le cas le plus connu pour X-Plane et sont causés, une fois de plus, par Shannon et Nyquist : les instruments existent dans leur propre texture qui est ensuite projetée dans la scène 3D, généralement sous différents angles, mais la plupart du temps, elle finit par être projetée beaucoup plus petite qu'elle ne l'était à l'origine. Prenez un G1000 par exemple, je crois qu'il tourne à 1024x768, mais est-ce que vous lui donnez autant d'espace à l'écran ? Si vous travaillez en 1080p, ce n'est certainement pas le cas, à moins que vous n'ayez que le G1000 en vue. Le mappage de cet instrument à l'écran fait perdre des informations qui étaient présentes auparavant mais qui ne peuvent pas être entièrement représentées à l'écran, puis FXAA examine les morceaux, détecte les bords et les lisse. FXAA ne peut pas rattraper les informations perdues auparavant et le mappage des triangles à l'écran est un processus avec perte, vous ne récupérez pas ces informations et vous êtes triste parce que vos instruments sont flous. Cependant, si vous avez un écran 4k, il y a de fortes chances que l'information soit très claire. Cependant, si vous avez un écran 4k, il y a de fortes chances que l'information soit très proche d'être mappée 1:1. FXAA est donc une excellente option car il peut lisser les bords irréguliers qui sont présents et même si ce processus perd également de l'information, vous ne commencez pas avec un chapeau pratique ayant déjà perdu un tas d'informations avant cela.
Et maintenant, celui que les gens détestent le plus : MSAA. Multi Sample Anti Aliasing. Nous revenons à de vraies techniques anti-crénelage (réelles dans ce cas, cela signifie qu'elles essaient de ne pas perdre d'informations plutôt que d'essayer de faire disparaître les informations perdues). Permettez-moi de commencer en disant ceci : Le MSAA est implémenté dans le matériel, il ne peut pas être implémenté dans le logiciel. Le MSAA dans X-Plane n'est pas "mauvais" parce que les idiots de LR ne savent pas comment nuancer les shaders. Il est intégré dans le matériel de votre GPU et tous les jeux ont la même implémentation du MSAA. Le MSAA tente de rectifier le problème de traitement du SSAA. Vous vous souvenez que le problème était que nous produisions plus de pixels au total ? Eh bien, la production des pixels est la partie la plus coûteuse en termes de calcul, alors que se passerait-il si nous n'en produisions pas ? Le MSAA utilise un masque de couverture pour chaque pixel, divise chaque pixel en plusieurs échantillons, puis détermine lequel de ces échantillons est couvert par un triangle. Cela fait un certain temps, alors voici une image pour que tout le monde soit encore d'accord avec moi :
(L'org est malheureusement en train de manger la qualité de celle-ci)
Il s'agit d'une grille hypothétique de 3x3 pixels, les signes + noirs au milieu sont le centre du pixel, la ligne jaune est le bord d'un triangle qui traverse la grille et j'implique que le triangle couvre la moitié inférieure droite de la grille. Le rouge et le vert + au milieu de la grille sont les échantillons pour ce pixel (mais ils ont été créés pour la démonstration, les masques de couverture ont tendance à avoir des formes différentes pour ne pas être biaisés dans une direction particulière). L'idée est simple, dans ce cas le rasterizer du GPU sait que pour le pixel du milieu, le triangle couvre l'échantillon vert et ne couvre pas du tout l'échantillon rouge. Les pixels du milieu inférieur, de droite et du milieu droit sont entièrement dans le triangle avec les deux échantillons (non dessinés) et leurs homologues de l'autre côté sont entièrement à l'extérieur. Le GPU stocke toutes ces informations, ce qui signifie que le coût de la mémoire augmente toujours par le carré, car au lieu d'un pixel, vous avez maintenant N échantillons. Mais ce n'est pas le cas du traitement, car le GPU n'a pas besoin de calculer un pixel plus d'une fois, mais seulement de mettre à jour les échantillons sous-pixels pendant le rendu.
La dernière étape du MSAA consiste à le résoudre, c'est-à-dire à faire la moyenne des échantillons et à l'utiliser comme couleur finale du pixel. En termes de traitement, c'est essentiellement gratuit, vous n'avez pas à envoyer un milliard d'invocations de shaders supplémentaires juste pour ombrer des pixels avec des valeurs qui n'ont pas d'importance. Sauf que...
Le MSAA fonctionne fondamentalement parce que le matériel sait où se trouvent les bords du triangle. Mais il commence à tomber à plat avec la géométrie transparente, parce que soudainement le truc de couverture cool ne fonctionne plus parce que la transparence est à l'intérieur de la géométrie. Si vous vous souvenez de l'époque antérieure à la version 12.1, les clôtures en mailles et les feuilles d'arbres avaient un très mauvais aspect avec le MSAA, simplement parce que le MSAA fonctionne sur la géométrie et que les feuilles/clôtures en mailles sont des géométries plates avec des trous percés via le canal alpha. La version 12.1 a amélioré le MSAA car elle utilise les techniques alpha-to-coverage et alpha-to-one, deux techniques qui atténuent ce problème. La technique alpha-to-coverage utilise essentiellement la valeur alpha renvoyée pour déterminer le nombre d'échantillons couverts et la technique alpha-to-one remet la valeur alpha à 1 après la distribution des échantillons afin d'éviter les artefacts de mélange. Telles sont les améliorations apportées par la version 12.1.
Mais bien sûr, activer le MSAA n'est pas gratuit en termes de traitement, malgré tous mes efforts pour prétendre le contraire il y a 5 secondes. L'écriture des valeurs MSAA est essentiellement gratuite, mais les jeux ne se contentent pas d'écrire les valeurs finales des pixels sur l'écran et de s'arrêter là. X-Plane et la plupart des jeux modernes utilisent le rendu différé, où l'image est composée avec quelques étapes supplémentaires. L'une des choses les plus coûteuses que vous puissiez faire est le calcul de la lumière. Ainsi, au lieu d'ombrer complètement chaque pixel, X-Plane stockera les métadonnées de chaque pixel, à savoir la couleur de l'albédo, les normales de la surface, les valeurs émissives et les valeurs du matériau. Cela signifie que toutes ces valeurs doivent être stockées quelque part pendant que la scène est composée, mais cela résout le problème du surdessin. Imaginez que vous dessiniez d'abord la piste d'atterrissage, puis l'avion, ce serait un gaspillage d'ombrer complètement chaque pixel de la piste d'atterrissage pour ensuite le remplacer par des pixels d'avion entièrement ombrés quelques étapes plus tard. Au lieu de cela, les informations de la scène sont extraites dans ce que l'on appelle le tampon g. Une fois que la scène est entièrement composée, on passe en revue chaque pixel et on convertit ces métadonnées en pixel entièrement ombré.Et c'est là que les choses se compliquent. Parce que pour ombrer précisément chaque pixel, le shader d'éclairage doit consommer la surface MSAA et s'exécuter par échantillon. Il ne connaît pas les données de couverture de la surface pour savoir quels échantillons proviennent tous du même triangle et n'ont donc pas besoin d'être ombrés par échantillon, ce qui fait que le coût de traitement augmente encore par carré. Pire encore, ce que j'ai écrit ci-dessus est une vaste simplification de la façon dont X-Plane affiche une image à l'écran. Il y a beaucoup de cibles de rendu intermédiaires et bien que tout ne doive pas être traité par échantillon, c'est le cas de la plupart des choses. Voici le graphique de la façon dont X-Plane affiche une image à l'écran :
Nous appelons cela affectueusement le dag. J'appelle cela "compression h#### de l'org".
Edit : Btw, c'est la raison pour laquelle le MSAA forcé par le pilote est plus rapide. Puisque le MSAA est implémenté dans le matériel, le pilote peut simplement l'activer pour une cible de rendu qu'il sélectionne (très probablement la mauvaise, btw) et ensuite le résoudre à sa propre discrétion. Mais X-Plane n'est pas dans la boucle ici, donc il n'exécutera pas de traitement par échantillon, mais seulement par échantillon. Le résultat final est un ombrage incorrect mais des performances plus rapides. C'est à vous de décider si c'est acceptable ou non.
Mais pourquoi le MSAA ne résout-il pas tous les jaggies ? Pourquoi le sol semble-t-il parfois très irrégulier lorsqu'il est mouillé, pourquoi les reflets sont-ils parfois très mauvais et pourquoi les bords de mes ailes semblent-ils parfois irréguliers ? Le MSAA est sûrement capable de résoudre ces problèmes ?
Voici un exemple, regardez les bords déchiquetés avec le contour bleu ! Il s'agit sûrement d'arêtes de vertex et elles devraient donc bénéficier de MSAA, n'est-ce pas ? La réponse est oui, et en fait, voici le secret : cette barre est anti aliasée. Je peux le prouver aussi, voici à quoi elle ressemble dans le tampon g (et donc non ombrée) :I Promis, le MSAA fait parfaitement son travail ici, pas de bord déchiqueté malgré un angle assez faible.
Le problème est que... Vous ne regardez pas un défaut du MSAA, vous regardez XPD-15050. Le problème est que le post-traitement qui éclaire la scène récupère des reflets du ciel pour cet objet, juste parce que la barre est inclinée vers le haut et pointe vaguement dans cette direction. Et certains des pixels présents mangent des reflets du ciel. C'est pourquoi l'image non éclairée semble nette. Il s'agit d'un défaut de plusieurs choses, principalement de l'implémentation actuelle du SSR. Une fois de plus, Shannon et Nyquist sont à blâmer.Ainsi, lorsque vous dites que "LR ne sait pas comment mettre en œuvre l'anti-crénelage correctement",
je grimace un peu parce que tous les bords irréguliers n'ont pas qu'une seule cause. Le MSAA fonctionne parfaitement et fait bien son travail, mais il ne peut rien faire contre les artefacts de crénelage introduits plus tard dans le pipeline de rendu. FXAA peut en fait faire un peu de travail ici parce qu'il fonctionne dans une étape de post-traitement sur l'image finale, mais il ne supprimera pas l'information qui ne devrait pas être là en premier lieu, il se contentera de la lisser un peu. Mais ce problème est résolu par l'implémentation d'un SSR plus intelligent, ce qui semble plus facile qu'il ne l'est pour la même raison que toutes les autres techniques d'AA semblent toujours plus faciles qu'elles ne le sont.
Il y a d'autres choses que je pourrais aborder ici, comme le TAA et d'autres techniques anti-crénelage. Mais cela devient déjà un peu long pour ce que je pensais être un simple commentaire de 5 minutes sur les raisons pour lesquelles l'anti-crénelage est plus difficile que ce que tout le monde veut bien croire. Fondamentalement, la limite est physique. Et je n'excuse rien ici, les artefacts sont ennuyeux et devraient être corrigés. Mais je dirai ceci : avant d'être embauché chez LR il y a 8 ans, je suis arrivé en pensant que tout le monde était stupide et que je pouvais résoudre tous les problèmes de X-Plane facilement (pour ma défense, j'avais 8 ans de moins et 8 ans d'abrutissement). Il s'avère qu'une fois sur le terrain, les choses ne sont pas aussi faciles qu'elles le paraissent et la plupart des gens chez LR sont en fait très intelligents. Ils sont également très passionnés et conscients de toutes les lacunes. Nous voulons que X-Plane soit meilleur et j'espère que nous le démontrons à chaque nouvelle version. En attendant, ne retenez pas votre souffle sur des corrections d'AA pour la 12.2, mais soyez assurés que nous sommes 1) conscients du besoin d'un meilleur AA et 2) que ce n'est pas aussi facile que d'appuyer sur un interrupteur.
Commentaire