2 points par GN⁺ 2024-02-29 | 1 commentaires | Partager sur WhatsApp
  • Une expérimentation visant à pousser l’Euclidean PGA jusqu’au bout dans un moteur de rendu forward compatible glTF, à la place des matrices 4x4 utilisées presque par inertie en graphisme 3D
  • Les rotations et translations sont représentées par un motor PGA de 8 flottants, et la composition générale de motors se fait en 48 multiplications et 40 additions, contre 64 multiplications et 48 additions pour un produit de matrices 4x4
  • La transformation de points est plus coûteuse qu’avec des matrices en développement direct, mais peut être ramenée à 21 multiplications et 18 additions via un sandwich product exploitant la contrainte de normalisation ; les transformations de directions et de vecteurs de base coûtent encore moins cher
  • En normal mapping en tangent space, les normales et tangentes sont remplacées par un tangentRotor, ce qui réduit les données de sommet de 12 à 9 flottants, tout en maintenant un coût de transformation en world space proche de l’approche matricielle, autour de 47 multiplications et 38 additions
  • Pour fonctionner avec du contenu glTF réel, il faut convertir les matrices en motors au chargement et suivre l’uniform scale dans un flottant séparé ; le non-uniform scale nécessite soit un traitement limité, soit un chemin de repli en matrices 4x4

Un renderer forward sans matrices basé sur PGA

  • Le projet est Look, Ma, No Matrices et vise à implémenter un renderer forward sans matrices
  • Depuis SIGGRAPH 2019, la Geometric Algebra, en particulier l’Euclidean PGA, suscite de l’intérêt dans les communautés du graphisme et du machine learning, mais dans le graphisme 3D traditionnel, on s’est souvent contenté de rebaptiser les dual quaternions en motors PGA
  • Cette implémentation intègre l’algèbre PGA dans un moteur 3D compatible glTF, et ne se limite pas à un simple changement de nom : plusieurs parties du pipeline graphique sont réorganisées selon l’approche PGA
  • L’implémentation de référence est le viewer glTF de Khronos, et l’objectif est moins la performance absolue qu’une expérience de remplacement des matrices sans compromis
    • Au final, une solution hybride sera probablement un meilleur choix

Pourquoi remettre en cause les matrices 4x4

  • Les matrices 4x4 ont longtemps occupé un rôle central dans les API graphiques et les pipelines GPU à fonction fixe, et restent l’outil de base du rendu forward classique
  • Les GPU modernes se rapprochent davantage de processeurs scalaires programmables que d’un pipeline à fonction fixe, si bien qu’une représentation centrée sur les matrices n’est pas forcément indispensable
  • Dans les moteurs 3D réels, beaucoup de matrices ne contiennent que rotation et translation, c’est-à-dire des matrices orthogonales
  • La variété des motors PGA représente l’ensemble des mouvements euclidiens avec un coût mémoire et calcul plus faible, et elle englobe aussi quaternions et dual quaternions sans conversion

Représentation des données PGA et opérations de base

  • L’algèbre PGA est générée à partir de quatre vecteurs de base e0 à e3
    • e1, e2, e3 correspondent respectivement aux plans x=0, y=0, z=0
    • Le vecteur dégénéré spécial e0 représente le plan à l’infini
  • Dans les shaders, l’implémentation utilise les types intégrés de GLSL, sans surcharge d’opérateurs, avec addition, soustraction et multiplication scalaire
    • motor mat2x4
    • line mat2x3
    • point vec3
    • direction vec3
  • La composition générale de motors PGA se fait avec le geometric product
    • Produit de matrices 4x4 : 64 multiplications, 48 additions
    • Composition générale de motors gp_mm : 48 multiplications, 40 additions
  • Des combinaisons particulières de transformations permettent des opérations encore moins coûteuses
    • gp_rr : 16 multiplications, 12 additions
    • gp_tt : 0 multiplication, 3 additions
    • gp_rt / gp_tr : 12 multiplications, 8 additions
    • gp_rm / gp_mr : 32 multiplications, 24 additions
    • gp_tm / gp_mt : 12 multiplications, 12 additions

Optimisation des transformations de points et de directions

  • En PGA, pour transformer un point p par un motor M, on utilise le sandwich product M p M̃
  • Développé naïvement, cela coûte 33 multiplications et 29 additions, soit plus qu’un produit matrice-vecteur à 16 multiplications et 12 additions
  • En exploitant le fait qu’un motor normalisé vérifie M M̃ = 1, on peut réécrire l’expression et ramener la transformation d’un point à 21 multiplications et 18 additions
  • Une direction, c’est-à-dire un point à l’infini, est encore moins coûteuse car le coefficient implicite e123 vaut 0
    • Transformation de direction générale : 18 multiplications, 12 additions
    • Transformation d’une basis direction, par exemple l’axe x, jusqu’à 6 multiplications et 4 additions
  • Cette optimisation des basis directions sert ensuite d’argument contre l’idée reçue selon laquelle les matrices sont toujours les plus rapides pour traiter les tangent frames

Normalisation, racine carrée, maps exponentielle et logarithmique

  • Le squared pseudonorm d’un motor PGA prend la forme d’un Study Number : M M̃ = a + b e0123
  • La normalisation n’est pas une simple normalisation vectorielle : c’est une procédure qui garantit que le motor résultant représente une transformation orthonormale
    • Coût d’une implémentation générale de normalisation de motor : 21 multiplications, 5 additions
    • Des versions plus efficaces existent pour une translation pure ou une rotation pure
  • La transformation rigide entre deux points, deux lignes ou deux plans a et b s’écrit M = sqrt(b / a)
    • Le geometric product ba entre deux éléments du même type produit un motor correspondant au double de la transformation de a vers b
    • On peut calculer cela sous la forme sqrt M = normalize(1 + M)
  • Le logarithme d’un motor PGA est une scaled line, et une scaled line peut produire un motor de rotation par exponentiation
  • Alors que l’exponential map d’une matrice 4x4 générale est numériquement coûteuse, la variété des motors PGA permet une forme fermée efficace

Inverse et factorisation des motors

  • La Geometric Algebra permet de calculer efficacement l’inverse d’objets normalisés
    • inverse d’un plan : lui-même
    • inverse d’une ligne : inversion de signe
    • inverse d’un point : inversion de signe
    • inverse d’un motor : reversion
  • Lorsqu’un bivecteur général ne satisfait pas la condition de Plücker et ne représente donc pas une ligne unique, on calcule son inverse via l’inverse du Study Number
  • Deux factorisations sont utilisées dans l’implémentation du rendu
    • Factorisation euclidienne : décomposition du motor en une rotation autour de l’origine suivie d’une translation
    • Factorisation invariante : décomposition du motor en une translation et une rotation commutatives, connue en 3D sous le nom de théorème de Mozzi-Chasles
  • Lors de la composition du tangent frame avec le motor object-to-world, la factorisation euclidienne est utile car le frame est invariant par translation

Matrices glTF et gestion du scale

  • Pour rester interopérable avec le contenu glTF existant, il faut convertir les matrices en motors PGA au moment du chargement
  • Une matrice orthogonale 4x4 est convertie en motor en exploitant son isomorphisme avec les quaternions
    • Toutes les matrices et transformations importées sont converties au load time
  • Les motors PGA modélisent des transformations rigides et n’incluent donc pas le scaling
  • Le uniform scaling est invariant par rotation et translation, et peut donc être suivi avec un flottant par nœud
    • Le scale total d’un élément est calculé comme le produit de son scale propre et de celui de son parent
    • Il est appliqué aux sommets au load time ou au tout début du vertex shader
    • Pour les translations, le scale du parent est appliqué au load time et lors de la mise à jour d’animation
  • Sur un échantillon d’environ 400 fichiers glTF aléatoires, moins de 0,5 % comportaient une animation de scale, alors que le uniform scale fixe était assez fréquent
  • Le non-uniform scaling est plus délicat, car il n’est pas invariant par rotation
    • Pour le traiter de manière générale, un chemin de repli en matrice 4x4 est inévitable
    • Dans les échantillons glTF, les cas observés appliquaient le non-uniform scale uniquement à des leaf nodes ; dans ce cas, le scale est appliqué séparément avant les autres transformations, sans impact sur les clés d’animation

Remplacement du couple Model-View-Projection

  • Un renderer forward transforme la géométrie du mesh de l’object space vers le screen space, puis détermine les pixels couverts par chaque triangle
  • Dans le pipeline classique, les matrices model et view sont remplacées par des motors PGA
    • position de sommet : sw_mp
    • directions des normales et tangentes : sw_md
  • La matrice de projection n’ayant généralement que cinq entrées non nulles, elle n’est pas artificiellement remplacée par PGA : une expression de projection directe est utilisée
  • Côté CPU, la mise à jour hiérarchique du scene graph réduit le coût de calcul en remplaçant la composition de matrices par la composition de motors
  • Côté GPU, une comparaison naïve rend la transformation de sommets défavorable aux motors, mais cela change quand on modifie la représentation du tangent frame

Optimisation du normal mapping en tangent space

  • Dans un mesh classique avec tangent space normal mapping, le vertex shader doit transformer position, normale et tangente
  • Comme normale, tangente et bitangente forment un frame orthonormé, PGA permet de les représenter par un tangentRotor allant du frame de base canonique au tangent frame voulu
  • Cette approche réduit le descripteur de sommet
    • Classique : position 3 + normale 3 + tangente 4 + uv 2 = 12 flottants
    • Approche PGA : position 3 + tangentRotor 4 + uv 2 = 9 flottants
    • Soit une réduction de 25 % du nombre de flottants par sommet
  • Le tangentRotor possède une double couverture, et le signe du coefficient scalaire est aligné avec le handedness flag classique pour distinguer les k-reflections paires et impaires
    • L’implémentation s’appuie sur le signed zero et extrait la handedness dans le vertex shader avec sign(1/tangentRotor.x)
  • Transformer position, normale et tangente avec une matrice 4x4 demande au total 48 multiplications et 36 additions
  • L’approche PGA transforme tout le tangent frame en une seule fois, puis en extrait normale et tangente
    • composition du tangent frame : 16 multiplications, 12 additions
    • extraction normale/tangente : 9 multiplications, 8 additions
    • transformation de position : 21 multiplications, 18 additions
    • 1 multiplication pour extraire la handedness
    • total : 47 multiplications, 38 additions
  • Le coût de transformation des sommets reste donc presque identique à celui de l’approche matricielle, tandis que le stockage des transformations passe de 32 flottants à 8 flottants

Contraintes côté fragment shader et textures baked

  • Pour charger du contenu existant, il faut de nouveau une matrice TBN à l’étape du fragment shader
  • Lors du baking, l’outil projette un mesh très détaillé sur un mesh simplifié, interpole la normale et la tangente des sommets sur la face du triangle, puis construit à chaque fragment une matrice TBN orthogonale pour produire la texture de normales en tangent space
  • L’interpolation des vecteurs de base génère les erreurs typiques de l’approche matricielle, et ces erreurs sont déjà baked dans la texture
  • Cette implémentation extrait donc explicitement les vecteurs normale et tangente à partir du tangentRotor
  • Si l’on contrôle aussi l’outil de baking, on peut transmettre directement le tangentRotor au fragment shader, le normaliser, puis l’utiliser pour transformer la normale échantillonnée
    • plus besoin de construire de matrice TBN
    • l’extraction normale/tangente dans le vertex shader devient inutile
    • un varying parameter peut être supprimé
    • l’orthogonalisation coûteuse dans le fragment shader disparaît également

Skinning par motor et animation blending

  • Un motor PGA est isomorphe à un dual quaternion, ce qui le rend naturellement adapté au skinning
  • Après conversion de l’inverse bind matrix en motor, les bone motors sont blendés selon le même schéma que pour le dual quaternion skinning
  • Les transformations blendées sont alignées en signe pour suivre le shortest arc, puis la transformation résultante est renormalisée
  • L’animation blending suit la même logique : les motors PGA sont blendés directement côté CPU puis normalisés

Résultat de l’expérience de remplacement des matrices

  • Il est possible de remplacer les matrices uniquement avec PGA dans un renderer forward compatible glTF
  • L’idée selon laquelle le coût des transformations serait forcément plus élevé devient moins évidente quand on applique l’optimisation du sandwich product et une nouvelle représentation du tangent frame
  • Dans le cas courant du tangent space normal mapping, l’approche par motors PGA maintient un coût de vertex shader presque identique à l’approche matricielle tout en réduisant fortement l’empreinte mémoire des sommets
  • Le gain mémoire, permettant de stocker environ 33 % de sommets en plus à capacité égale, est particulièrement notable
  • Cette technique peut être intégrée comme remplacement direct dans un moteur 3D existant, sans presque augmenter le coût du vertex shader ni modifier le reste du pipeline

1 commentaires

 
GN⁺ 2024-02-29
Avis Hacker News
  • L’une de mes créatrices YouTube préférées en maths/graphisme, Freya Holmér, a publié il y a quelque temps une très bonne vidéo d’introduction à l’algèbre géométrique : https://www.youtube.com/watch?v=htYh-Tq7ZBI&ab_channel=Freya...
    Si vous vous intéressez au graphisme 3D, en particulier aux splines/courbes de Bézier, toutes ses vidéos valent le détour
    Personnellement, j’ai toujours trouvé l’algèbre linéaire difficile, mais cette approche par l’algèbre de Clifford me paraît beaucoup plus intuitive

    • C’était une vraiment bonne présentation, et cela m’a fait penser à https://enkimute.github.io/ganja.js/
      Cette bibliothèque a été créée par enkimute, l’auteur de l’article original ; c’est une bibliothèque assez étonnante qui, malgré le fait qu’il s’agisse d’un script en un seul fichier et sans build, fournit une prise en charge de l’algèbre en N dimensions ainsi que du rendu
    • Je pensais que l’article parlerait d’elle. J’ai aussi beaucoup apprécié ses vidéos sur les splines et les courbes de Bézier, et sa présentation va droit au cœur du sujet sans jamais donner l’impression de se précipiter
    • Les commentaires YouTube contiennent aussi, étonnamment, de bonnes explications complémentaires et de bonnes questions
      Par exemple, on y trouve des explications assez utiles sur des points que Freya survole un peu vite ou omet, comme la non-commutativité du produit
  • L’algèbre géométrique est longtemps restée pour moi un mystère complet, jusqu’à ce que je finisse par la comprendre ainsi : ce n’est que de la multiplication de polynômes, sauf qu’il existe des quantités pour lesquelles l’ordre de multiplication compte, et que la table de multiplication est étrange. Par exemple i*i = 1, i*j = -j*i
    La plupart des introductions présentent le produit géométrique de deux vecteurs (x1*i + y1*j) * (x2*i + y2*j) comme quelque chose de profond et mystérieux, mais en réalité c’est la même expansion FOIL que l’on apprend en algèbre de première année :
    (x1*i + y1*i)(x2*i+y2*j) = x1*x2*i*i + x1*y2*i*j + y1*x2*j*i + y1*y2*j*j = (x1*x2 + y1*y2) + (x1*y2 - y2*x1)*i*j
    La valeur dans la première parenthèse est le produit scalaire familier, et la valeur dans la seconde correspond au produit vectoriel familier, mais exprimée avec une base d’une nouvelle dimension, i*j. Et contrairement au produit vectoriel, elle se généralise à un nombre arbitraire de dimensions ; en algèbre géométrique, on l’appelle le produit extérieur
    Une fois qu’on comprend cela, même des choses comme la dérivation des formules de rotation deviennent plus faciles. Les techniques apprises en algèbre peuvent être appliquées telles quelles à la résolution de problèmes de géométrie

    • Dans https://youtu.be/htYh-Tq7ZBI?si=lOmsCL2DoqUCQgh1&t=1540, mentionné dans un autre commentaire, Freya explique très bien comment réduire les axiomes à un seul
      Si l’on définit le produit d’un vecteur par lui-même comme le carré de la longueur de ce vecteur, tout le reste découle d’une simple multiplication de polynômes. C’est assez beau
    • Cette explication offre un contraste intéressant. Il y a quelques jours, quelqu’un demandait pourquoi les cours de maths ne montraient pas la méthode et la raison des opérations, mais se contentaient de donner des formules à calculer ; ici, l’accent est mis sur ce que fait l’opération plutôt que sur la raison pour laquelle elle est valide
      « Comment cela fonctionne-t-il ? » et « Pourquoi cela fonctionne-t-il ? » sont deux questions qu’un professeur de mathématiques doit équilibrer, et il est difficile de répondre toujours correctement aux deux dans un même cours
    • Le second terme n’est pas un produit vectoriel, mais un produit d’algèbre extérieure, ou bivecteur. Le produit vectoriel ne fonctionne qu’en trois dimensions, tandis que le produit d’algèbre extérieure est possible dans n’importe quelle dimension supérieure
      Le produit vectoriel de deux vecteurs en 3D est un autre vecteur perpendiculaire au plan formé par ces deux vecteurs. En revanche, le produit d’algèbre extérieure est un 2-vecteur, c’est-à-dire un bivecteur, qui balaie le parallélogramme entre les deux vecteurs et se trouve dans le plan où ils reposent. En 3D, le vecteur du produit vectoriel est perpendiculaire à ce plan bivectoriel
    • L’une des choses qui prennent le plus de temps à apprendre en mathématiques, c’est que la plupart des objets sont définis de la manière la plus simple possible
      En particulier, définir un produit bilinéaire m:V x V -> V sur un espace vectoriel V revient exactement à définir m uniquement sur les paires de vecteurs de base. Si on appelle cela la « propriété universelle du produit tensoriel », on répondra probablement simplement : « ah, d’accord »
  • Il est intéressant de voir qu’il existe plusieurs approches pour l’interpolation de rotations : algèbre géométrique, quaternions, voire interpolation de matrices complètes : https://www.gamedev.net/tutorials/programming/math-and-physi...
    Mais une fois le code optimisé à la main, le code final finit par être presque identique dans la plupart des approches. La différence réside dans la manière de comprendre les règles et les possibilités
    D’après ce que j’en sais, l’algèbre géométrique semble être l’approche la plus cohérente et la plus puissante. Elle est déroutante et assez difficile à accepter au début, mais ceux qui franchissent cette barrière l’apprécient
    À l’inverse, tout le monde utilise les quaternions tout en se plaignant de ne pas les comprendre, et dit qu’il faut un livre entier pour les visualiser. Un livre comme 『Visualizing Quaternions』 d’Andrew J. Hanson et Steve Cunningham

    • Je ne suis pas mathématicien et je n’utilise pas beaucoup la géométrie dans mon travail, mais j’apprenais l’algèbre géométrique par curiosité, et j’avais aussi essayé d’apprendre les quaternions auparavant
      L’algèbre géométrique est amusante, les quaternions ne le sont pas. J’ai l’impression de comprendre l’algèbre géométrique ; avec les quaternions, même en suivant des cours et des exercices, la seule chose dont j’étais sûr, c’est que je ne les comprenais pas. Maintenant que je connais un peu l’algèbre géométrique, j’ai enfin l’impression de comprendre aussi les quaternions dans une certaine mesure
    • Naive Lie Theory』 est un excellent livre, et il enseigne les quaternions dès le premier chapitre
      https://www.goodreads.com/en/book/show/4419538
  • Si ce sujet vous intéresse, il existe de bonnes diapositives qui parcourent les concepts de Grassmann/Clifford/algèbre géométrique : http://www.terathon.com/gdc12_lengyel.pdf
    Il y a aussi un autre bon site : https://mattferraro.dev/posts/geometric-algebra

  • Il ne faut pas non plus oublier l’excellent « A swift introduction to projective geometric algebra » de Sudgy : https://www.youtube.com/watch?v=0i3ocLhbxJ4
    Et le site de référence principal est https://bivector.net
    On peut aussi rejoindre le Discord bivector, qui compte plus de 1 000 professeurs, chercheurs et passionnés : https://discord.gg/vGY6pPk

    • Eric Lengyel, l’auteur de cette présentation, a aussi écrit Foundations of Game Engine Development, Volume 1: Mathematics, dont le chapitre 4 traite du même sujet
  • Honnêtement, je n’ai jamais trop aimé la façon dont l’algèbre géométrique produit toutes sortes d’éléments mixtes si l’on ne fait pas attention à ce que l’on multiplie par quoi
    Le fait qu’il faille jusqu’à 2^n termes pour ce qui était un espace à n dimensions me semble aussi difficile à manier
    On s’attendrait à ce qu’elle permette de mieux traiter la géométrie, c’est-à-dire le produit scalaire, mais je n’ai jamais vu d’explication convaincante de pourquoi on ne pourrait pas simplement utiliser le produit extérieur et l’opérateur étoile de Hodge, ou un isomorphisme musical
    Le côté un peu « magique » qui transforme un bivecteur u^v en rotation dans ce plan, e^(u^v)t, revient au fond à utiliser un isomorphisme musical pour transformer la 2-forme u^v en endomorphisme linéaire, puis à interpréter e^(u^v)t comme une exponentielle de matrice
    Un autre exemple souvent cité est qu’on peut ramener les équations de Maxwell à une seule équation ; mais avec les formes différentielles, on peut déjà les résumer en deux équations qui valent pour des raisons différentes, donc je ne voyais pas l’intérêt de les fusionner en une seule

    • Le fait qu’« il faille jusqu’à 2^n termes pour ce qui était un espace à n dimensions » est parfois une économie en trompe-l’œil
      Par exemple, les vecteurs normaux se transforment différemment des vecteurs de position. On peut représenter les deux avec la même structure de données, mais il faut alors suivre quel type de vecteur elle contient et ajouter un peu partout dans le code des cas particuliers pour les traiter différemment
      L’algèbre géométrique prend le problème de front : elle utilise la base (i,j,k) pour les vecteurs, et une base séparée (j*k, k*i, i*j) pour un autre type
      C’est un bon exemple où un espace de plus grande dimension est en fait plus économique en stockage qu’un espace de plus faible dimension, au sens où une seule équation vaut mieux que deux ou quatre
      Le champ électrique diffère du champ magnétique d’une manière assez proche de celle dont un vecteur diffère d’un bivecteur. On peut traiter les champs électrique et magnétique comme des cas particuliers dans des équations séparées, ou bien les traiter uniformément avec une seule approche
    • Les éléments mixtes sont justement la partie importante
      Un quaternion avec w=1, x,y,z=0 est l’identité, et un quaternion comme w=0, x=1 ou w=0, x=y=0.7 ne correspond qu’à une rotation de 180 degrés
      Pour obtenir une rotation arbitraire, il faut une combinaison des deux. On mélange « un peu de rotation de 180 degrés autour de cette droite » et « un peu de rotation de 0 degré/identité ». C’est exactement ce que signifie avoir à la fois un scalaire et un bivecteur
      Si l’on essaie d’éviter « prudemment » les mélanges avec le produit extérieur et le produit scalaire, c’est qu’on l’utilise mal. Le produit géométrique est l’acteur principal, et il produit des mélanges remarquables
    • Je suis d’accord pour dire que la confusion existe déjà. L’approche traditionnelle se contente de la balayer sous le tapis
      Par exemple, si l’on manipule des normales, il faut suivre au moins deux espaces à n dimensions qui se transforment de façons assez différentes
      Représenter les points, plans, droites, normales, translations et rotations avec un seul type multivector et des règles cohérentes donne, une fois compris, une impression assez libératrice. Je suis encore moi-même en train d’apprendre
  • L’interpolation d’animation en bas est vraiment superbe, mais j’aimerais que les modèles du reste de la page soient un peu moins agités
    Les maths sont déjà assez difficiles sans petites éléphantes pom-pom girls

    • Au contraire. Sans ces encouragements façon éléphant, je ne serais jamais allé jusqu’au bout de la page
  • Si l’auteur lit ceci, j’aimerais qu’il définisse l’acronyme PGA lors de sa première utilisation

    • Pour ceux que cela intéresse, PGA signifie projective geometric algebra, c’est-à-dire algèbre géométrique projective
      On ajoute un vecteur de base nul aux vecteurs de base de l’espace dans lequel on travaille. Cela permet de représenter algébriquement des objets géométriques qui ne passent pas par l’origine
    • En particulier, le passage où « Fast PGA » est abrégé en FPGA m’a pas mal embrouillé
    • Corrigé. mea maxima culpa
  • Ces algorithmes sont-ils efficaces même en tenant compte du GPU ?
    J’ai l’impression vague que les GPU sont optimisés pour les opérations matricielles, et je me demande si l’on ne perd pas cet avantage en formulant les choses avec l’algèbre géométrique, au point de ne pas vraiment gagner en pratique
    C’est une supposition mal informée, donc corrigez-moi si je me trompe

    • C’est une idée reçue très répandue de croire que, parce que les standards GPU incluent les produits matrice-matrice et matrice-vecteur, les fabricants de GPU les accélèrent forcément
      En réalité, ce n’est pas nécessairement possible, car l’ensemble des cœurs de shader est déjà SIMD. Certains GPU le font, d’autres non
    • Quand on programme, il faut déterminer deux choses : quelle grandeur on veut calculer, et quelle est la façon la plus efficace de la calculer
      La PGA demande un certain effort pour être comprise, mais c’est une très bonne façon de traiter le premier point. De toute façon, il vaut généralement mieux essayer d’abord la méthode la plus simple et la plus facile à implémenter
      L’implémentation obtenue en résolvant le premier point avec la PGA suffit à prototyper le reste du programme et à faire des benchmarks pour trouver le vrai goulot d’étranglement. Heureusement, dans la plupart des cas, c’est soit la méthode de calcul la plus rapide, soit suffisamment rapide pour ne pas être le goulot d’étranglement
      Et même si elle le devient, elle donne une compréhension approfondie du problème à résoudre. Je pense qu’il vaut mieux avoir cette compréhension avant de commencer à rogner des cycles en espérant que ce soit assez rapide
    • Cet article traite précisément de ce sujet. En résumé, on peut généralement arriver à un niveau comparable
  • Cela ressemble à une bataille de micro-différences à la pointe du progrès
    Le fait que l’animation squelettique 3D utilise encore des matrices 4x4 sur GPU signifie que les maths développées pour cet usage sur CPU à l’époque de Half-Life 1 sont toujours à l’avant-garde. De 1998 à 2024, cela fait 26 ans
    Dans 1 000 ans, l’animation 3D sera toujours la même

  • Cet article dépasse mon niveau de compréhension, mais le titre m’a rappelé une expérience où je fabriquais un moteur de rendu 3D simple
    Après avoir échoué plusieurs fois à apprendre l’algèbre linéaire, je me suis dit sous la douche que les rotations 3D n’étaient que trois rotations 2D, et que ça, je savais déjà le faire. Environ une heure plus tard, j’avais un moteur de rendu 3D en fil de fer avec perspective
    Je recommande à tout le monde d’essayer au moins une fois