AAA – technique d’anticrénelage analytique

 (blog.frost.kiwi)
1 points par GN⁺ 2024-11-21 | 1 commentaires | Partager sur WhatsApp
  • Les jaggies et le pixel crawling produits par la rastérisation se voient davantage en mouvement que sur une image fixe, et l’article compare plusieurs méthodes d’anticrénelage avec une démo WebGL de cercle
  • SSAA, MSAA et FXAA ont chacun des contraintes différentes : coût du downsampling, dépendance au matériel, ou déformation des formes liée au post-traitement
  • L’Analytical Anti-Aliasing calcule, quand on connaît les frontières mathématiques d’une forme, la distance jusqu’au bord avec un signed distance field, puis applique un fondu alpha sur une largeur de 1 pixel autour du contour
  • En 2D, la taille d’un pixel peut être calculée directement à partir de la taille de l’objet et du rendu ; avec une perspective 3D, des Screen Space derivatives comme dFdx, dFdy et fwidth sont nécessaires
  • La technique est implémentable même en WebGL 1.0/OpenGLES 2.0 sans buffer supplémentaire ni matériel spécifique, mais elle nécessite le SDF de toute la forme et atteint ses limites avec les formes à haute fréquence plus petites qu’un pixel

L’anticrénelage vu à travers une démo WebGL de cercle

  • L’objectif de l’article est d’examiner plusieurs techniques d’Anti-Aliasing qui réduisent les jaggies visibles avec la rasterization, puis de présenter à la fin une implémentation d’Analytical Anti-Aliasing
  • La comparaison couvre successivement SSAA, MSAA, FXAA, les familles MLAA/SMAA, puis AAA
  • La démo dessine un cercle en mouvement dans un canvas WebGL, avec le postulat que l’anticrénelage doit être compris en mouvement plutôt que sur une image fixe
  • Le canvas d’exemple rend à la résolution native de l’appareil, et le cadre rouge fournit une vue agrandie 4×
  • Pour les écrans haute résolution où l’aliasing est peu visible, la démo propose de basculer entre des résolutions de rendu Native, 1/2, 1/4 et 1/8, avec de l’integer scaling

Les problèmes créés par le rendu de cercle de base

  • Le rendu de cercle le plus simple consiste, dans le fragment shader, à sortir une couleur si length(uv) < 1.0, sinon à faire discard
  • Le cercle ne dépend pas de la résolution réelle de la geometry : il est dessiné sur un quad composé de 4 vertex, le shader déterminant ce qui est à l’intérieur ou à l’extérieur du cercle
  • varying vec2 uv est interpolé pour chaque fragment et fournit des coordonnées centrées en 0, allant de -1 à +1
  • Cette méthode relève de l’Alpha testing, et la valeur length(uv) est liée au signed distance field utilisé ensuite pour l’AAA
  • À basse résolution, le cercle paraît blocky et, lorsqu’il bouge, le pixel crawling — des rangées de pixels qui apparaissent et disparaissent — ainsi que le wobble deviennent très visibles
  • Les résolutions 1/4 et 1/8 servent aussi à représenter des cas d’éléments petits ou éloignés en 3D, et pas seulement un simple agrandissement

SSAA : un downsampling simple, mais coûteux

  • SSAA signifie Super Sampling Anti-Aliasing : on rend à une résolution plus élevée, puis on downsample vers une taille plus petite
  • L’implémentation d’exemple dessine le cercle dans une texture de taille (canvas.width / resDiv) * 2, (canvas.height / resDiv) * 2, la downsample vers un framebuffer à résolution standard, puis la blit à l’écran
  • Un rendu en résolution 2× utilise 4 pixels d’entrée pour 1 pixel de sortie, ce qui multiplie par 4 la mémoire et la quantité de calcul
  • Dans l’exemple réel, l’anticrénelage fonctionne, mais semble plus faible qu’attendu
    • Il devrait y avoir 4 niveaux de transparence, mais certaines zones observées n’en montrent que 2
    • À basse résolution, les 4 niveaux de transparence apparaissent surtout près des diagonales à 45 degrés
    • Sur la partie inférieure alignée sur les axes, on ne voit que l’opacité complète et la transparence à 50 %, les niveaux 25 % et 75 % manquant
  • La cause est que la forme du cercle elle-même n’est pas échantillonnée en résolution 2× : on rééchantillonne plutôt un résultat de cercle déjà quantized
  • Comme l’implémentation d’exemple utilise une texture en résolution 2x et de la linear interpolation, elle consomme en pratique 5 fois plus de VRAM
  • Un SSAA correct échantillonne la scène plusieurs fois sans buffer intermédiaire et combine les résultats, ce qui nécessite une intégration profonde avec la pipeline de rendu

MSAA : avantages et inconvénients d’un échantillonnage matériel

  • MSAA est une forme de supersampling, mais il s’applique surtout aux silhouettes de modèles, aux geometry qui se recouvrent et aux bords de textures quand l’Alpha to Coverage est activé
  • Son implémentation dépend du matériel GPU et des fournisseurs graphiques, et le niveau de prise en charge varie selon le matériel et les pilotes
  • WebGL 1 ne prenant pas en charge MSAA, l’exemple utilise un contexte WebGL 2
  • L’interface de l’exemple compare No MSAA, 2x, 4x, 8x, 16x, 32x et 64x avec les résolutions de rendu Native, 1/2, 1/4 et 1/8
  • Le nombre maximal d’échantillons pris en charge est lu via gl.MAX_SAMPLES, et seules les options sélectionnables sont activées
  • Sur les GPU mobiles, un appel à renderbufferStorageMultisample() peut en réalité être forcé en MSAA 4x
    • Sur Android, même si le choix 2x est autorisé, le pilote le force en 4x
    • Sur iPhone et iPad, le choix 2x devient du 4x, et la transparence est arrondie à des valeurs proches de multiples de 50 %, ce qui crée un double bord dans l’exemple
  • MSAA déléguant le travail au matériel, l’appareil de l’utilisateur peut ne pas prendre en charge les fonctionnalités nécessaires
  • Le motif d’échantillonnage peut produire des résultats inattendus, et selon le matériel, les niveaux de transparence sur le bord du cercle peuvent apparaître « dans le mauvais ordre »
  • Il reste très puissant dans certaines conditions
    • forward rendering
    • geometry pas trop dense
    • GPU avec une tile-based rendering architecture
  • Rahul Prasad explique que, sur mobile, MSAA n’est pas aussi coûteux que sur desktop et que, sur certains GPU mobiles, le MSAA 4x peut être gratuit
  • Parmi les ressources complémentaires, l’article mentionne MSAA color resolve deep-dive de KhronosGroup Vulkan-Samples

MLAA, SMAA, FXAA : le courant du post-traitement

  • En 2009, l’article d’Alexander Reshetov a proposé une approche consistant à détecter les bords dans une image avec aliasing blocky, puis à réduire les bords en blocs à l’aide de règles de filtrage selon la forme des pixels
  • Cette approche basée sur la morphologie a mené à MLAA, puis a été améliorée avec SMAA, davantage centré sur la suppression des sub-pixel artifacts
  • Certains utilisateurs trouvaient les familles MLAA/SMAA trop floues, d’où l’expression « vaseline on the screen »
  • L’anticrénelage en post-traitement illustre le passage d’un support matériel incertain vers un AA basé sur shader

FXAA 3.11 : structure et limites d’un AA rapide en post-traitement

  • FXAA est l’algorithme Fast approximate anti-aliasing de Timothy Lottes, une méthode inspirée de MLAA
  • La dernière version publique est FXAA 3.11, et la démo s’appuie sur la version publiée le 12 août 2011
  • La démo compare la scène de cercle aux résolutions Native, 1/2, 1/4 et 1/8
  • Les réglages par défaut utilisent FXAA_PC 1, FXAA_QUALITY_PRESET 12, fxaaQualitySubpix 0.75, fxaaQualityEdgeThreshold 0.166 et fxaaQualityEdgeThresholdMin 0.0833
  • FXAA échantillonne d’abord la luminance du pixel central et de ses voisins haut, bas, gauche et droite ; si le local contrast est inférieur au seuil, il renvoie le pixel d’origine
  • S’il n’y a pas d’early exit, il échantillonne aussi la luminance diagonale, calcule la direction horizontale ou verticale de l’edge, puis cherche dans les deux directions pour trouver les extrémités de l’edge
  • Au final, il décale les coordonnées du pixel pour échantillonner avec texture2D ; d’après le whitepaper officiel, il ne s’agit pas simplement de flouter l’edge
  • Dans la démo de cercle, les bords paraissent lisses à l’arrêt, mais la forme se déforme quand le cercle bouge
    • De petites protubérances apparaissent puis disparaissent sur les parties supérieure et inférieure alignées sur les axes
    • À basse résolution, le cercle perd sa rondeur et tremble comme des graphismes de PlayStation 1
  • Comme il ne considère que le voisinage 3x3 autour de chaque pixel, il ne peut pas savoir que cette zone fait partie d’un grand cercle
  • FXAA a été conçu pour antialiaser des scènes plus complexes et fournit de nombreux réglages et presets
  • La full demo utilisant la scène NeoTokyo° calcule le luminance channel à partir de la sortie aliased, applique FXAA, et permet de manipuler tous les presets et settings

Entrées FXAA et conditions des paramètres

  • Définir FXAA_GREEN_AS_LUMA à 1 utilise le canal vert au lieu de la luma ; dans ce cas, l’entrée RGB doit être dans un espace colorimétrique non linéaire
  • L’entrée RGB de FXAA doit être en LDR ; concrètement, il faut appliquer FXAA après le tonemapping
  • Si FXAA_GREEN_AS_LUMA n’est pas utilisé, il faut stocker la luma en espace perceptuel dans le canal alpha avant d’exécuter FXAA
  • La luma doit être calculée correctement pour que FXAA fonctionne comme prévu
  • FXAA_QUALITY_PRESET est un réglage qui arbitre entre performances et qualité
    • 12 est la valeur par défaut
    • 15 et 29 correspondent à la meilleure qualité
    • 39 correspond à EXTREME QUALITY
  • fxaaQualitySubpix règle la quantité de suppression de l’aliasing sous-pixel
    • La valeur par défaut est 0.75
    • 1.00 est plus doux, tandis que 0.50 est plus net mais supprime moins l’aliasing sous-pixel
    • 0.00 correspond à l’état désactivé
  • fxaaQualityEdgeThreshold définit le contraste local minimal nécessaire pour appliquer l’algorithme
  • fxaaQualityEdgeThresholdMin exclut les zones sombres du traitement
  • FXAA peut avoir un faible coût en performances si vous disposez déjà d’un pipeline de post-traitement ou utilisez le deferred shading
  • Sur les GPU mobiles, les accès mémoire sont coûteux ; si une nouvelle configuration render-to-texture doit être créée pour FXAA, l’avantage en coût diminue

L’essentiel de l’Analytical Anti-Aliasing

  • L’Analytical Anti-Aliasing consiste à dessiner les pixels déjà sous une forme anticrénelée, en connaissant à l’avance les formes nécessaires
  • Lors du rendu de formes 2D ou 3D, il applique un fondu sur exactement 1 pixel au bord de la forme
  • L’exemple compare un cercle aux résolutions native, 1/2, 1/4 et 1/8, et montre le lissage des bords ainsi que la préservation de la forme même à basse résolution
  • circle-analytical.fs calcule le signed distance field du cercle avec dist = length(uv)
  • Pour faire fondre les pixels proches du bord du cercle sur une largeur de 1 pixel, il utilise alpha = (1.0 - dist) / pixelSizeAdjusted
  • Cette méthode est fluide, sans artefacts, permet de régler la quantité de filtrage et ne nécessite ni buffer supplémentaire ni exigence matérielle additionnelle
  • Elle fonctionne aussi en WebGL 1.0 ou OpenGLES 2.0 de base, sans extension
  • Un lissage de 1 pixel reste net, mais selon la combinaison entre résolution d’écran, taille et position du cercle, les côtés alignés sur les axes à 90° peuvent encore être perçus comme plats
  • Filtrer sur la base de la taille diagonale d’un pixel, √2 px = 1.4142..., peut réduire cette impression de platitude, mais rend la forme très légèrement plus floue

Sens de « Analytical » et implémentation basée sur les SDF

  • En programmation graphique, « Analytical » désigne un effet calculé à partir de la définition mathématique d’une forme dont on connaît à l’avance la construction voulue
  • Le terme est utilisé de manière souple en computer graphics et peut prendre plusieurs sens selon le contexte
  • L’implémentation repose sur un signed distance field et suppose que l’on connaît, pour chaque point échantillonné, la distance à la forme désirée
  • Cette information peut être bake dans une texture, comme pour le rendu de texte par SDF, ou être dérivée pixel par pixel par une formule mathématique pour les formes simples
  • En faisant disparaître progressivement la bordure de la forme selon la distance signée, et en fixant la distance de fondu à la taille de 1 pixel, on obtient un bord lisse
  • La question clé de l’implémentation est de savoir comment le shader connaît la taille d’un pixel et comment il effectue le blend à partir de la distance
  • Cette approche offre une pixel-perfection stable en mouvement, mais ne correspond pas à la rastérisation traditionnelle et nécessite un signed distance field pour l’ensemble de la forme

Calcul de la taille de pixel : pré-calcul, dFdx/dFdy, fwidth

  • Si la largeur du fondu au bord est fixée à une valeur constante comme 95 % du rayon du cercle, le résultat peut être bon pour une taille et une résolution données, mais devenir excessivement doux ou produire de l’aliasing lorsque la taille change
  • La taille de pixel fait partie des problèmes résolus par les Screen Space derivatives
  • dFdx, dFdy et fwidth permettent de déterminer à quel point une valeur varie à l’échelle des pixels de l’écran
  • Dans l’exemple, la variation de distance est obtenue avec pixelSize = fwidth(dist) ou pixelSize = length(vec2(dFdx(dist), dFdy(dist)))
  • Les Screen Space derivatives reflètent correctement les transformations, y compris la perspective 3D, mais ne font pas partie du standard WebGL 1 ; elles nécessitent donc l’extension GL_OES_standard_derivatives ou WebGL 2
  • La méthode length() calcule la longueur du vecteur formé par dFdx et dFdy, tandis que fwidth() utilise l’approximation abs(dFdx()) + abs(dFdy())
  • L’approximation fwidth() peut être trop fortement mise à l’échelle dans les directions diagonales, ce qui peut appliquer davantage de fondu sur les diagonales
  • L’extension Unity Shapes appelle l’AAA basé sur fwidth() « Fast Local Anti-Aliasing », et la méthode basée sur length() « Corrected Local Anti-Aliasing »
  • En 2D, comme on connaît la taille de rendu du contexte et la taille du quad, la taille de pixel peut être calculée directement pour chaque objet
  • L’exemple transmet une taille de pixel basée sur la hauteur, comme gl.uniform1f(pixelSizeCircle, (2.0 / (canvas.height / resDiv))), et cette méthode fonctionne aussi sur du matériel ancien, sans WebGL 2 ni extension

Alpha blending et choix de la fonction step

  • Une fois la largeur du fondu calculée, il faut ajuster l’opacité
  • En 2D, l’alpha blending est une option simple
  • Une autre option consiste à combiner MSAA et Alpha to Coverage ; elle peut être utilisée dans les scènes 3D lorsqu’une écriture dans le depth-buffer est nécessaire pour obtenir un blending correct
  • L’alpha doit être estompé en fonction de la distance, et l’on utilise généralement une fonction step qui interpole entre un début et une fin
  • Dans les implémentations GLSL d’anticrénelage, smoothstep() est souvent utilisé, mais dans ce contexte, la fonction agit à l’intérieur de 1 à 2 pixels, donc sa courbe est à peine observable
  • En retirant l’interpolation de Hermite de smoothstep(), on obtient linearstep(), une interpolation linéaire clampée
  • Lorsqu’il n’y a qu’une seule forme dans un quad, le clamp peut aussi être retiré
  • L’alpha final peut être calculé par une simple division comme float alpha = (1.0 - dist) / (pixelSize * smoothingAmount);
  • Du point de vue des performances, la partie coûteuse reste la division effectuée pour chaque pixel, tandis que les GPU modernes peuvent optimiser les multiplications et additions de l’interpolation de Hermite via des Fused Multiply-Add

Bords du quad, MSAA et correction de 0,5 pixel

  • Il existe une interaction entre MSAA + Alpha to Coverage et le rasterizer qui n’apparaît que sur certains matériels
  • Lors de l’utilisation de MSAA + Alpha to Coverage, il peut arriver que exactement 0,5 pixel disparaisse sur un côté du quad, indépendamment du nombre d’échantillons
  • Pour y répondre, l’exemple ajoute une marge de 0,5 pixel au SDF sous la forme dist += pixelSizeAdjusted * 0.5
  • En 2D, un traitement similaire à NV_conservative_raster_dilate peut être implémenté directement
    • Agrandir le quad de 0,5 pixel dans le vertex shader
    • Réduire le signed distance field de 0,5 pixel dans le fragment shader
  • Les démos 2D de la page fonctionnent de cette manière, et vertex *= size + pixelSize joue ce rôle
  • Les questions de gamma et de premultiplied alpha sont également importantes pour toutes les formes d’AA, mais elles ne sont pas traitées afin de se concentrer sur l’AAA

Plusieurs formes et extension 3D

  • Il est possible de dessiner plusieurs formes dans un même quad, et d’appliquer l’anticrénelage à chacune
  • Quand il y a plusieurs formes, les deux doivent être évaluées pour chaque pixel, puis les résultats doivent être clampés, pondérés et additionnés afin que l’anticrénelage soit conservé même aux intersections
  • Il est moins coûteux de colorer directement la sortie des formes nécessaires en une seule fois que de dessiner l’overlay de couleur dans une passe séparée
  • L’exemple 3D utilise un carré arrondi 2D placé dans une caméra mobile et une perspective
  • Le fragment shader 3D calcule le SDF de la boîte arrondie avec roundedBoxSDF, puis obtient la taille du pixel avec length(vec2(dFdx(dist), dFdy(dist)))
  • En présence de multiplications par les matrices de caméra et de perspective, il est fiable d’utiliser les dérivées en espace écran pour obtenir la taille du pixel
  • En théorie, on pourrait multiplier les coordonnées de fragment par la matrice de perspective inverse pour chaque pixel sans utiliser les dérivées, mais le coût en performances est élevé
  • Placer le fondu au centre de la frontière peut réduire la déformation des formes à petite taille ou sous forte perspective, mais les bords peuvent sortir du quad et provoquer un bord dur ou du clipping
  • NVIDIA a introduit l’extension NV_conservative_raster_dilate, qui fournit des pixels supplémentaires sur la frontière, mais elle n’est pas disponible dans WebGL et reste limitée au matériel NVIDIA

Cas d’implémentation réels

  • L’extension Unity Shapes de Freya Holmér est considérée comme l’implémentation fonctionnellement la plus complète de cette approche
    • Elle applique l’anticrénelage aux SDF avec MSAA ou les mélange selon l’approche AAA
    • Elle inclut le motion blur, des dégradés de couleur respectant les formes, et un fondu d’opacité pour les lignes de moins de 1 pixel
    • La technique pour les lignes de moins de 1 pixel est appelée Line Thinness Fading
  • Valve Software a largement introduit le rendu par signed distance field dans le Source engine pendant le développement de l’Orange Box
    • Il a notamment été utilisé dans le HUD de Team Fortress 2 pour créer des éléments d’interface doux mais nets
    • Valve a développé un système de shader de line art produisant des silhouettes douces même lorsque des images à résolution fixe sont agrandies à haute résolution
    • Il gère aussi les outlines et les drop-shadows, et peut s’appliquer à des éléments du monde comme des panneaux dans l’espace 3D
  • Valve a publié son implémentation dans un article SIGGRAPH 2007, qui inclut aussi des exemples de mondes de jeu 3D
  • « Shape Decomposition for Multi-channel Distance Fields » de Viktor Chlumský est un exemple d’évolution d’une technique mentionnée en note de bas de page dans l’article de Valve
    • Les travaux associés incluent msdfgen et msdf-atlas-gen
  • L’approche multi-channel distance field utilise RGB et un terme médian pour produire du texte net, et place un SDF classique dans le canal alpha afin de gérer des effets comme le glow et la drop shadow
  • Les caractères CJK nécessitent des textures plus grandes en raison de leurs détails fins, et réduire de grandes textures peut provoquer ses propres artefacts
  • L’utilisateur Hacker News aappleby indique que Google Maps utilise l’AAA basé sur des formes capsule pour les segments de route
    • aappleby dit l’avoir écrit lui-même il y a environ 10 ans
    • Il explique qu’en vérifiant avec le debugger WebGL Spector.js, le code shader du draw call des rues semble montrer un alpha mélangé dépendant des formes

Limites de l’approche SDF et discussion sur le TAA

  • Yakov Galka souligne que, comme l’approche SDF échantillonne le SDF en un point donné, des composantes haute fréquence dans le SDF peuvent provoquer de l’aliasing
  • Lorsqu’on rastérise un cercle plus petit que 1 pixel, l’approche de cet article peut ne pas suffire à éliminer complètement l’aliasing
  • Yakov Galka cite Wavelet Rasterization de J. Manson et S. Schaefer comme une véritable méthode analytique pour rastériser avec anticrénelage des formes polygonales et de Bézier
  • Après la publication de l’article, les commentaires ont indiqué que la critique du TAA était forte, et l’auteur a reconnu ne pas avoir suffisamment traité les problèmes que le TAA cherche à résoudre ni ceux qui sont difficiles à résoudre par d’autres techniques
  • Timothy Lottes considère le TAA comme une évolution technique claire, tout en notant qu’il a des limites en matière de clarté du mouvement
  • FXAA 4 était un blender sur 2 frames et diffère fondamentalement de TXAA ; TXAA n’utilise pas MLAA et repose sur MSAA
  • Pour mieux comprendre le TAA, la présentation GDC Temporal Reprojection Anti-Aliasing in INSIDE de Lasse Jon Fuglsang Pedersen, développeur d’Inside, est recommandée
  • L’AAA est considéré comme une technique permettant de dessiner, à la résolution native, des formes de différentes tailles de manière douce, nette et stable en mouvement

À lire aussi

1 commentaires

 
GN⁺ 2024-11-21
Commentaires sur Hacker News

  • Je suis l’auteur de l’article, donc s’il y a des questions, j’y répondrai.

    • Google Maps utilise de l’AAA en forme de capsule pour tous les tronçons de route. Je l’ai écrit il y a environ 10 ans :D
    • Excellent article. En essayant de comprendre l’antialiasing des polices MSDF, je suis tombé sur plusieurs affirmations
      Selon certaines, l’antialiasing devrait se faire dans l’espace RGB linéaire plutôt que dans l’espace sRGB [1] [2], mais d’autres avancent que, comme on ne l’a pas fait ainsi pendant des décennies, les polices ont été corrigées en conséquence, et que sRGB est parfois meilleur [3] [4]. Je me demande si vous avez des conseils sur l’antialiasing en espace linéaire vs sRGB
      [1] https://www.puredevsoftware.com/blog/2019/01/22/sub-pixel-ga...
      [2] http://hikogui.org/2022/10/24/the-trouble-with-anti-aliasing...
      [3] https://news.ycombinator.com/item?id=12023985
      [4] http://hikogui.org/2022/10/24/the-trouble-with-anti-aliasing...
    • Petite correction : WebGL prend en charge le MSAA depuis WebGL1. Cela dit, dans WebGL1, ce n’est possible que sur le canvas, on ne peut pas contrôler le nombre d’échantillons, seulement activer ou désactiver l’antialiasing
      WebGL2 n’a toujours pas d’objets de texture MSAA et ne prend en charge que les renderbuffers MSAA, donc on ne peut pas lire directement les échantillons individuels depuis un shader. C’est une fonctionnalité utile pour une passe de rendu de résolution (resolve) personnalisée, mais elle n’est possible qu’avec WebGPU
    • Je suis d’accord pour dire que la tendance récente à dépendre des upscalers est allée trop loin, et que beaucoup de jeux AAA produisent un résultat flou et plein d’artefacts. Mais après avoir vu cette analyse approfondie de Digital Foundry [1], l’argument selon lequel seules des technologies comme DLSS peuvent offrir une stabilité en mouvement et une netteté que l’on ne peut pas obtenir autrement, voire faire mieux que le SSAA, m’a paru assez convaincant
      Du coup, je ne pense plus « TAA == flou », mais plutôt « TAA + machine learning bien utilisé = le meilleur antialiasing actuellement possible dans les jeux 3D ». Je serais curieux de savoir ce que vous en pensez
      [1] https://youtu.be/WG8w9Yg5B3g
    • Je me demande combien de temps il a fallu pour écrire cet article
      J’ai moi-même écrit quelques billets de blog basés sur de la visualisation temps réel, et ça m’a pris énormément de temps. Mais j’ai quand même l’impression que c’est la bonne direction. À une époque où le contenu déborde de partout, produire moins de contenu de qualité, même si cela prend plus de temps, me semble bénéfique pour tout le monde

  • Le problème tient moins à l’antialiasing lui-même qu’à tout ce qui l’entoure. Dans les paramètres des jeux, on peut choisir entre plusieurs sigles, mais presque rien n’explique en quoi ils diffèrent, et la moitié me sont totalement inconnus
    Bien sûr, on peut chercher, mais un peu plus d’attention à l’expérience utilisateur serait bienvenue. Cet article me semble utile comme référence pour la suite

    • Les jeux/le graphisme sont clairement un domaine plein de jargon. Si vous ne voulez pas devenir magicien, il suffit de changer les options et de regarder le résultat. J’aime bien l’approche de Dolphin, qui ajoute des infobulles détaillées aux paramètres, mais il restera toujours une part de savoir tacite
      D’un point de vue méta, j’ai l’impression de voir plus souvent ces derniers temps une humeur anti-sigles. Je pense qu’il n’a jamais été aussi facile qu’aujourd’hui de chercher. Il existe certainement des sigles qui freinent l’apprentissage ou jouent une forme de rôle de gardien, mais il faut bien nommer les concepts à un niveau utile pour pouvoir travailler ; du coup, les sigles des paramètres graphiques dans les jeux me semblent plutôt raisonnables

  • La façon d’analyser la programmation graphique avec des exemples WebGL est géniale. C’est de l’hypertexte qui exploite vraiment les forces du médium. Ça me fait penser au genre d’article qu’on pourrait voir sur https://pudding.cool/, mais avec beaucoup plus de profondeur
    J’utilisais depuis un moment MSAAx4 dans un moteur de rendu, et je réfléchissais récemment à passer à une implémentation FXAA/TAA, mais maintenant je ne sais plus très bien si je vais vraiment changer. J’ai beaucoup appris ici, et je pense essayer une approche analytique pour les éléments d’UI. Les articles sur la programmation graphique ne montent pas souvent sur HN ; pour les personnes intéressées, je recommande cette ressource, une collection d’articles d’analyse de frames :
    https://www.adriancourreges.com/blog/

    • Steve Wittens écrit lui aussi beaucoup d’articles de ce genre, avec des illustrations mathématiques mêlées à du WebGL, sur https://acko.net/
      Mon préféré en particulier est https://acko.net/blog/how-to-fold-a-julia-fractal/. Je n’ai jamais vu de ressource qui m’ait autant aidé à comprendre la relation entre les fonctions trigonométriques et les nombres complexes
    • Je déteste vraiment le TAA. Surtout à faible fréquence d’images, le ghosting est beaucoup trop marqué. Il m’arrive souvent de passer volontairement à un algorithme plus lent pour éviter ce ghosting

  • Les frames avec les cercles et les zones agrandies transmettent très bien le message. L’ensemble de l’article se lit très bien

  • Les SDF ou mSDF ne sont pas l’avenir, ce sont déjà des classiques suffisamment bons
    La partie disant qu’« il faut résoudre tous les segments de courbes de Bézier pour chaque pixel, ce qui dégrade fortement les performances » me semble au contraire relever de l’avenir, voire du présent. Slug et DirectWrite sont déjà utilisés avec de bonnes performances
    https://sluglibrary.com/
    https://learn.microsoft.com/en-us/windows/win32/directwrite/...

    • Il ne faut pas non plus oublier le rendu de courbes implicites [0]. Le brevet devrait expirer bientôt [1]
      [0]: https://www.microsoft.com/en-us/research/wp-content/uploads/...
      [1]: https://patents.google.com/patent/US20070097123A1/en
    • Il y a environ 20 ans, j’ai écrit une implémentation de l’article Loop/Blinn pour Microsoft Game Studios, et je me demande si elle est encore utilisée
      Il a vraiment fallu beaucoup de travail pour l’amener à un niveau production. La tessellation basée sur les Voronoï décrite dans l’article se comportait de façon pathologiquement mauvaise sur beaucoup de caractères asiatiques
    • Ma mémoire me trompe peut-être complètement, mais l’algorithme utilisé dans Slug n’est-il pas couvert par un brevet ?

  • En faisant défiler l’article, la capture d’écran de NeoTokyo m’a immédiatement sauté aux yeux. J’ai couru dans ce couloir des milliers de fois. J’ai administré des serveurs de ce mod pendant des années, et j’ai vraiment passé d’excellents moments avec une petite communauté compétente et sympathique

    • Ce qui est encore plus étonnant, c’est qu’on y joue toujours activement. Chaque vendredi soir, un serveur se remplit, et parfois aussi le samedi/dimanche. Il y a un noyau de fans assez dévoués, et je n’ai jamais vu une telle fidélité pour un jeu multijoueur aussi ancien

  • Ayant écrit à la fois des moteurs de rendu 2D et 3D, j’ajouterais une petite nuance : les deux sont vraiment différents. Ce n’est pas juste une dimension de plus, les objectifs, les cas d’usage et les attentes sont complètement différents
    Donc, plutôt que de dire que « tout ce dont il est question ici s’étend aussi à la 3D », je dirais que tout l’article parle surtout de rendu 3D, et non de rendu 2D. Un bon article qui aborde ce sujet du point de vue du rendu 2D est https://ciechanow.ski/alpha-compositing/
    Des critères d’antialiasing dont personne ne se soucie en 3D, mais qui sont très importants en 2D, sont l’exactitude et le biais. Par exemple, l’AAA est très biaisé, donc inexact. Si l’on dessine plusieurs fois la même forme au même endroit, elle devient plus opaque ou plus sombre. Cela n’arrive pas avec le MSAA : l’erreur est bornée et il n’y a pas de biais

    • En réfléchissant à un moteur de rendu vectoriel 3D basé sur WebGPU en JS/TS, j’ai vu hier votre projet [0]
      Le dessin de lignes épaisses est particulièrement intéressant, parce que c’est difficile [1]. J’ai aussi vu récemment ceci [2], et je me suis demandé s’il serait possible de convertir toutes les formes en segments de courbes de Bézier quadratiques pour utiliser cette technique. Je serais curieux de savoir si vous pensez que c’est une piste à suivre
      [0] https://github.com/Lichtso/contrast_renderer
      [1] https://mattdesl.svbtle.com/drawing-lines-is-hard
      [2] https://scribe.rip/@evanwallace/easy-scalable-text-rendering...
    • Il est difficile de considérer que cet article se généralise tel quel à la 3D
      La solution proposée repose sur des champs de distance signés, mais elle survole la partie importante : « distance jusqu’à quoi ? ». En 2D, c’est clair : on mesure la distance jusqu’à la frontière entre l’objet et l’arrière-plan, c’est-à-dire la silhouette
      En 3D, cela se complique, car un objet peut tourner et s’auto-occulter. Par rapport à quoi mesurer le SDF ? La silhouette de la projection 2D d’un objet 3D change en permanence et ne peut pas simplement être précalculée

  • J’ai été content de voir un lien vers Captain Disillusion. Je ne le connaissais pas, mais son travail est impressionnant. Lien direct pour les personnes intéressées par les effets vidéo : https://www.youtube.com/@CaptainDisillusion

  • L’article est bien structuré, mais je pense que la partie qui s’attaque au TAA peut prêter à confusion. L’antialiasing par SDF n’est en aucun cas une alternative au TAA
    Le TAA traite toutes sortes d’aliasing, alors qu’ici il n’est question que de l’aliasing des contours. Beaucoup de jeux modernes utilisent des approches fondées sur Monte-Carlo pour l’éclairage indirect et d’autres effets, ce qui rend en pratique le TAA nécessaire

  • Le passage disant que « les puces mobiles prennent exactement en charge le MSAAx4 et la situation est étrange. Sur Android, on peut choisir 2x, mais le pilote force de toute façon 4x » me laisse un peu perplexe
    Sur mon téléphone Android, je vois clairement la différence entre 2x et 4x, mais cela n’a pas l’air “arrondi” comme du côté de l’iPhone