« Gaussian splatting » est vraiment plutôt cool
(aras-p.info)- L’article 3D Gaussian Splatting de SIGGRAPH 2023 propose une approche qui construit des scènes à partir de photos sous forme de millions de Gaussian 3D et les rend en temps réel ; une implémentation expérimentale de visualisation dans Unity a aussi été publiée
- Une scène est représentée non pas par des maillages, des voxels ou des champs de distance, mais par un ensemble de blobs dans l’espace, dotés d’une position, d’une rotation, d’une échelle non uniforme, d’une opacité et de coefficients d’harmoniques sphériques
- Cette méthode n’est pas un NeRF et l’implémentation officielle n’utilise pas non plus un pipeline de rastérisation à fonctions fixes, mais un rendu logiciel tuilé 100 % CUDA
- L’implémentation Unity prend 23,8 ms en 1200x800 sur une NVIDIA RTX 3080 Ti, contre 7,40 ms pour le visualiseur officiel, mais elle est écrite en HLSL standard et fonctionne aussi sur Mac
- La scène bicycle occupe 1,5 Go sur disque, compte environ 6 millions de blobs et environ 250 octets par blob : outre les performances, la taille des données et la mémoire GPU sont donc des axes d’amélioration importants
Article de SIGGRAPH 2023 et expérience Unity
- L’article de SIGGRAPH 2023 3D Gaussian Splatting for Real-Time Radiance Field Rendering est le travail de Kerbl, Kopanas, Leimkühler et Drettakis
- Le site de l’article, le code source et les jeux de données sont publics, ce qui permet d’essayer directement des expériences et des reproductions
- L’expérience Unity se concentre sur la visualisation en temps réel de fichiers de « modèles » Gaussian Splat déjà générés
- L’implémentation est publiée sur aras-p/UnityGaussianSplatting, et d’autres expérimentations devraient suivre
- La possibilité de réduire la taille des données est aussi un sujet d’intérêt, avec la possibilité de réutiliser de précédentes expérimentations de compression de floats
De quoi se compose un Gaussian Splat
- Le Gaussian Splatting représente une scène 3D non pas par des maillages polygonaux, des voxels ou des champs de distance, mais par des millions de particules
- Chaque particule, ou « Gaussian 3D », possède les informations suivantes
- une position dans l’espace 3D
- une rotation
- une échelle 3D non uniforme
- une opacité
- des informations de couleur
- La couleur n’est pas une couleur unique : elle est représentée par des coefficients d’harmoniques sphériques de degré 3, ce qui permet de varier selon la direction du point de vue
- Lors du rendu, les particules ne sont pas dessinées comme des sphères 3D allongées : elles sont « splattées » sous forme de Gaussian 2D dans l’espace écran
- Le cœur de l’approche consiste à créer, à partir de photos, une représentation de scène composée de blobs dotés d’une échelle et d’une couleur, puis à la rendre rapidement
Ni NeRF, ni rastérisation à fonctions fixes
- Le Gaussian Splatting n’est pas un NeRF
- Il est explicitement indiqué qu’il n’y a pas d’élément « Neural »
- Sa rapidité ne vient pas non plus du « recours au matériel de rastérisation GPU »
- L’implémentation officielle n’utilise pas le pipeline de rastérisation
- Elle est implémentée à 100 % en CUDA
- Les performances de l’implémentation officielle ne viennent pas de la rastérisation à fonctions fixes, mais d’un rendu logiciel tuilé qui traite efficacement des millions de particules redimensionnées
- Cela dit, un rasterizer tuilé « logiciel sur GPU » n’est pas en soi un concept entièrement nouveau
Liens avec d’anciens blocs technologiques
- Le Gaussian Splatting lui-même est lié à des travaux comme EWA Splatting, vers 2001-2002
- Le principe consiste à placer dans l’espace des blobs mis à l’échelle et orientés, à calculer leur projection à l’écran, puis à traiter leur forme gaussienne dans l’espace écran
- Le jeu Ecstatica, sorti en 1994, est un exemple original de moteur de rendu fondé sur des ellipsoïdes
- Les harmoniques sphériques sont utilisées en physique depuis plusieurs siècles et se sont largement fait connaître en informatique graphique autour de 2000, grâce aux travaux de Ravi Ramamoorthi et Peter-Pike Sloan
- Ray tracing volume densities, de Kajiya & Von Herzen en 1984, pourrait être l’un des premiers cas d’utilisation en graphisme
- Une synthèse connexe est disponible sur la page de Patapom
- Le Point-Based Rendering est également un domaine ancien
- Les systèmes de particules sont utilisés depuis longtemps en VFX et pour représenter des phénomènes non solides
- The Use of Points as a Display Primitive date de 1985
- Surfels est un article de 2000
- La demoscene et les outils de VFX temps réel utilisent eux aussi depuis longtemps des approches de rendu non traditionnelles
- Agenda Circling Forth, Ceasefire (all falls down..) et Number One / Another One, de Fairlight & CNCD, en sont des exemples
- Notch est un outil de VFX temps réel permettant de créer, simuler et afficher des objets basés sur des points et des blobs
- fogleman/primitive est un exemple d’outil de 2016 qui représente des images sous forme d’un ensemble de formes primitives
- « Dreams » de Media Molecule utilisait un moteur de rendu basé sur les splats, et la version publiée semble combiner plusieurs techniques
- La présentation « Learning from Failure » d’Alex Evans est disponible à SIGGRAPH 2015 et Umbra Ignite 2015
- La rastérisation tuilée pour particules existe au moins depuis Holy smoke! Faster Particle Rendering using Direct Compute, de Gareth Thomas en 2014
- Diviser l’écran en tuiles et travailler à l’intérieur de chaque tuile permet de réduire le trafic mémoire
- Cette approche rejoint aussi le fonctionnement général des GPU mobiles ; les premiers designs PowerVR remontent à 1996, et Pixel Planes 5 à 1989
État actuel de UnityGaussianSplatting
- aras-p/UnityGaussianSplatting est une implémentation de visualiseur pour modèles Gaussian Splat
- Son état actuel se résume plutôt à « ça fonctionne, mais ce n’est pas rapide »
- Sur une NVIDIA RTX 3080 Ti, le rendu de la scène bicycle en 1200x800 montre un écart de performances important
- Visualiseur officiel : 7,40 ms, 135 FPS
- Implémentation Unity : 23,8 ms, 42 FPS
- Environ 4 fois plus lent
- La méthode de tri influe aussi sur l’écart de performances
- L’implémentation Unity utilise un tri bitonique GPU relativement simple
- L’implémentation officielle utilise un radix sort CUDA basé sur l’algorithme OneSweep
- L’approche de rastérisation diffère elle aussi
- L’implémentation officielle utilise une approche tuilée écrite en CUDA
- L’implémentation Unity utilise le pipeline de rastérisation GPU standard pour rendre chaque splat sous forme de quad en espace écran
- L’implémentation Unity présente un avantage en matière de portabilité
- Le code est écrit en HLSL standard dans Unity, et fonctionne donc aussi sur Mac
- Sur Apple M1 Max, la même scène est rendue en 108 ms, soit 9 FPS
- La mémoire GPU semble actuellement plus faible dans l’implémentation Unity
- Visualiseur officiel : 4,8 Go
- Implémentation Unity : 2,2 Go
- Ce chiffre inclut aussi la mémoire utilisée par Unity Editor
Taille des données et consommation mémoire
- Les discussions autour du Gaussian Splatting ont tendance à se concentrer sur la qualité et la vitesse de rendu, mais la taille des données et la consommation mémoire sont aussi de gros problèmes
- La scène bicycle occupe 1,5 Go sur disque
- Cette scène est composée d’environ 6 millions de blobs
- Chaque blob utilise environ 250 octets
- À l’exécution, de la mémoire supplémentaire est nécessaire pour le tri, le rendu tuilé, etc.
- La présentation sur Dreams contient des idées qui pourraient servir de référence pour réduire la taille
1 commentaires
Commentaires sur Hacker News
Dire qu’on évite le terme « neural » tout en utilisant la descente de gradient et le rendu différentiable sonne un peu prétentieux
Conceptuellement, c’est proche de NeRF : on optimise, à partir d’images, une représentation fondée sur les données qui approxime des variables liées à une scène 3D. La différence semble être que NeRF modélise l’ensemble de la fonction de transport de la lumière, c’est-à-dire le champ de radiance, alors qu’ici on ne modélise que les conditions aux limites où la lumière arrive
Comme l’objet est différent, une base de représentation plus simple se justifie, et les résultats semblent bons ; mais présenter le fait d’éviter les réseaux de neurones comme quelque chose de louable en soi est regrettable. Les réseaux de neurones ne sont pas utilisés seulement parce qu’ils sont à la mode : ce sont réellement de puissants approximateurs de fonctions, et l’éventail des structures qu’on appelle « réseaux de neurones » est très large
C’est l’impression que me donne seulement le ton de l’introduction du billet de blog ; l’article scientifique lui-même peut être différent
Elle paraît donc plus facile à comprendre et aussi plus simple à intégrer à d’autres logiciels 3D, comme des éditeurs ou des moteurs de rendu ; l’animation semble également possible. Un approximateur de fonction en boîte noire représentant toute la scène d’un seul coup ne paraît ni extensible ni élégant
Cela dit, avec les réseaux de neurones, même quand le problème est bien modélisé, on ignore souvent comment le modèle entraîné fonctionne réellement ; leurs besoins en données et le réentraînement itératif limitent leur capacité à constituer des solutions de long terme
Ici, j’ai envie de l’interpréter généreusement comme une blague bon enfant des auteurs, plutôt que comme l’alimentation d’une petite guerre culturelle
Chaque pixel rendu est une somme pondérée des contributions de gaussiennes non bornées dépendantes du point de vue ; la distinction selon laquelle NeRF modéliserait un champ de radiance tandis que cette méthode ne modéliserait que des conditions aux limites n’est donc pas correcte
Si l’on tient aussi compte du fait que NeRF a utilisé des représentations en harmoniques sphériques de bas rang pour le domaine directionnel, on est presque sur du 3D+α ; on peut alors se demander pourquoi choisir des réseaux de neurones pour reconstruire une fonction d’aussi faible dimension
À l’inférence, il faut échantillonner à répétition le réseau de neurones le long du rayon de visée pour chaque pixel ; or la représentation compressée des champs lumineux est un problème traité depuis longtemps en infographie, ce qui rend cet aspect assez étrange
Par la suite, Plenoxels a retiré le « Ne » de NeRF et a fortement amélioré les performances d’entraînement et d’inférence, tandis que l’Instant NeRF de Nvidia a en partie rattrapé le coup en interpolant des embeddings d’entrée sophistiqués dans un petit réseau de neurones : https://nvlabs.github.io/instant-ngp/assets/mueller2022insta...
En ingénierie graphique, les réseaux de neurones ont surtout été largement utilisés pour reconstruire des données clairsemées, en particulier pour le débruitage, ce qui est naturel puisqu’il s’agit d’un problème de haute dimension. Même ainsi, il est rare qu’ils écrasent les algorithmes conçus à la main ; en revanche, l’utilisation de petits réseaux de neurones pour la compression semble avoir de l’avenir
L’infographie comporte beaucoup d’approximation de fonctions, donc il y a de la place pour les réseaux de neurones, mais les fonctions manipulées y sont généralement plus compréhensibles et contrôlables, contrairement à des domaines comme la compréhension du langage naturel où il est presque impossible d’utiliser des solutions algorithmiques conçues à la main
Beaucoup de discussions se terminent par IA = mal, CRYPTO = mal ; le problème n’est pas que l’opinion inverse soit forcément fausse, mais que si l’on décide d’abord de la conclusion puis qu’on arrête de réfléchir, on n’a aucun moyen de remarquer que ses propres idées sont peut-être complètement absurdes
C’est vraiment un travail impressionnant
L’article mentionne le rendu à base de points et les systèmes de particules, et dans les jeux récents, on a l’impression d’un glissement subtil vers un nouveau style de particules, plus orienté points que fragments de texture, tout en se comportant comme un système physique
Par exemple Hogwarts : https://www.gamespot.com/a/uploads/original/1816/18167535/40..., Forspoken : https://oyster.ignimgs.com/mediawiki/apis.ign.com/project-at..., Starfield : https://dotesports.com/wp-content/uploads/2023/08/temple-loc..., AC6 et FF16
Le point commun, c’est que cela ressemble à des particules ponctuelles transparentes et colorées dotées d’une physique, et, surtout sur console, on dirait que c’est utilisé pour produire des effets peu coûteux sur GPU sans charger le CPU. Si quelqu’un connaît le développement de jeux, ça m’intéresserait
Sans simulation de fluides, un système de particules à base de points ressemble simplement à un feu d’artifice. L’étape suivante consistait à faire en sorte que chaque particule ait indépendamment une physique comme une quantité de mouvement ou du vent, puis soit rendue sous forme de petit billboard texturé ; cela a servi à représenter des explosions ou de la fumée jusqu’à assez récemment
Désormais, avec l’amélioration des performances des machines et des algorithmes physiques, on peut exécuter en temps réel des simulations de fluides où les particules interagissent entre elles, et les effets que l’on voit aujourd’hui semblent aller dans ce sens
Dans l’univers des jeux 3D, ne manipuler que de vraies primitives 3D présente de nombreux avantages conceptuels et structurels, et les point sprites peuvent être traités presque comme des objets 3D infiniment petits
À l’inverse, quand on place des sprites 2D dans une scène 3D, s’ils ont une transparence partielle, il faut les trier de l’arrière vers l’avant, ils s’accordent mal avec le z-buffer, cela entre en conflit avec l’ordre de regroupement optimisé pour le GPU, ils s’enfoncent dans les surfaces 3D et trahissent facilement leur nature 2D
Pour résoudre ces problèmes, on a accumulé divers compromis : transparence en screen-door, shaders modifiant l’écriture dans le z-buffer, alpha test, alpha-to-coverage, etc.
En VR, le rendu à base d’images 2D au sein d’une scène 3D ressort encore plus mal que sur un écran unique, et le fait qu’il s’agisse de billboards plats devient beaucoup plus visible. En additionnant tout cela, il y a largement de quoi vouloir s’éloigner des effets de sprites texturés 2D dans les scènes 3D
Avec la dynamique autour de l’IA, le fait que les GPU évoluent, avec les RT cores et tensor cores, vers une sorte de « GPU à jeu d’instructions réduit à l’intérieur du GPU » semble aussi avoir un certain rapport
Il y a quelques années, chez NVIDIA, un kernel a été écrit pour porter les kernels SE(3) sur les tensor cores, et il ne serait pas surprenant qu’une partie puisse aussi être transposée, lors de la compression et de l’exécution, à la composante en harmoniques sphériques du Gaussian splatting : https://developer.nvidia.com/blog/accelerating-se3-transform...
Le Gaussian splatting ayant toujours un support dans l’espace 3D, il devrait être assez efficace, et même une transformation approximative et rapide peut donner un résultat final tout à fait correct
Il est aussi relativement facile de créer de beaux tourbillons de points lumineux. Unreal Engine a probablement quelque chose de similaire, mais je n’ai pas beaucoup d’expérience directe avec lui
Je ne pense pas que cela en soit issu, mais le premier jalon que je puisse citer est cette démo
Quand l’article du Siggraph est sorti pour la première fois, j’étais vraiment enthousiaste
Depuis une dizaine d’années, j’ai pris des photos sous des centaines d’angles des chambres où j’ai vécu, dans l’idée de les recréer un jour en 3D, et le Gaussian splatting est la première technique qui me donne l’impression de pouvoir les reproduire de façon presque réelle
J’ai très hâte que les outils mûrissent davantage pour pouvoir revisiter mes anciennes chambres et me laisser gagner par la nostalgie
C’est un domaine que je connais mal, donc ma question est peut-être naïve, mais ces vidéos ont vraiment l’air impressionnantes.
Si je comprends bien, la scène ou le champ de radiance est toujours statique et l’éclairage est baked ; je me demande s’il y a une possibilité d’évolution vers un changement dynamique de l’éclairage, voire la prise en charge du mouvement.
Dans un champ de radiance, il n’y a pas de notions comme l’émission, la réflexion ou l’absorption de la lumière : tout est aplati en une seule valeur de « lumière transmise ». En ce sens, un champ de radiance se rapproche davantage d’une photo 3D.
Pour changer cela, il faudrait estimer la position des sources lumineuses, les surfaces, les matériaux, etc. par rendu inverse ou photogrammétrie, puis revenir à du path tracing traditionnel.
Une autre direction consisterait non pas à faire de l’animation, mais de la vidéo : capturer en continu le champ de radiance au fil du temps et compresser les similarités entre les frames afin d’obtenir une cohérence temporelle.
On peut aussi en chaîner plusieurs pour créer une animation : https://twitter.com/8Infinite8/status/1699460316529090568
Pour le relighting, il existe beaucoup de variantes de NeRF qui le prennent en charge ; optimiser les paramètres de matériau des splats semble donc également possible.
Par exemple, dans une scène d’intérieur, si une table projette une ombre sombre sur le sol, un NeRF ne comprend pas encore les sources lumineuses et les ombres ; il ne peut donc pas savoir si le sol est noir, si c’est un sol blanc masqué par l’ombre de la table, ou si un Stanford bunny bleu se cache dans l’ombre.
Les rigs de scan 3D qui capturent de petits objets comme des visages humains résolvent cela en manipulant l’éclairage et en échantillonnant directement la BRDF. Si l’on ne peut pas manipuler l’éclairage, on peut tenter d’estimer la BRDF, mais avec des limites.
Ajouter ensuite une animation peut être facile, mais capturer l’animation elle-même nécessite soit plusieurs caméras, soit de s’appuyer sur des estimations, comme un réseau de neurones qui imagine et complète l’autre côté parce qu’il s’agit d’un humain.
Intel avait mené il y a quelques années un projet où plusieurs caméras capturaient une scène afin de pouvoir modifier la position de la caméra en post-traitement ; cela semblait viser les retransmissions de football américain, mais je n’ai pas entendu parler d’un lancement réel. Il faut plusieurs caméras, façon Matrix.
Autrement dit, on fait en sorte que les données soient animées selon l’heure de la journée. Les besoins en données peuvent devenir importants, mais avec des méthodes d’interpolation, ce n’est peut-être pas si mauvais.
Si une scène statique fait 2 Go, une approximation grossière selon l’heure de la journée devrait être possible en moins de 16 Go, et rendable sur des GPU modernes. Ensuite, il s’agit d’optimiser pendant quelques années en attendant que des performances de niveau H100 deviennent accessibles au grand public.
C’est toujours amusant quand la science dépasse les attentes de la science-fiction.
Dans ce cas, j’ai immédiatement pensé au concept de Braindance dans Cyberpunk 2077 : la possibilité de se déplacer dans le souvenir visuel de quelqu’un d’autre, dans les limites de ce que cette personne a perçu de la scène.
Si l’on déplace la caméra ailleurs que le point de vue d’origine, la vue s’effondre comme un amas de pixels tridimensionnels ; c’est proche du concept de blob ici, mais étonnamment bien moins abouti que dans cet article.
https://steelseries.com/blog/how-to-braindance-cyberpunk-207...
Le splatting en rendu volumique est une technique assez ancienne. Il y a l’article de juillet 1991 de Westover, Lee Alan, « SPLATTING: A Parallel, Feed-Forward Volume Rendering Algorithm ».
Personne ne semble vouloir cacher le second point, et le premier ne me paraît pas correct.
Je ne sais pas d’où venait cette intuition, mais je vivais près de Boston à l’époque et j’avais de jeunes enfants.
J’attends avec impatience la première implémentation WebGPU native optimisée du rendu 3DGS.
Je me demande aussi comment les données de scène seront compressées et décompressées efficacement.
J’ai laissé quelques notes sur cette question dans un thread Zulip : https://xi.zulipchat.com/#narrow/stream/197075-gpu/topic/Gau...
J’ai récemment vu une vidéo montrant comment utiliser le Gaussian splatting : Getting Started With 3D Gaussian Splats for Windows (Beginner Guide) - https://www.youtube.com/watch?v=UXtuigy_wYc
Je suis curieux de connaître l’état de l’art actuel de la structure from motion
Quand on dispose d’une vidéo d’un espace donné, j’aimerais savoir comment, concrètement, on la transforme aujourd’hui en scène 3D
C’est précisément l’entrée du processus de reconstruction de scène décrit dans cet article
Pour autant que je sache, l’approche de base du SfM n’a pas beaucoup changé depuis une dizaine d’années : elle se résume à l’extraction de caractéristiques d’image comme SIFT, à l’appariement heuristique, au bundle adjustment et à la suppression des valeurs aberrantes
La photogrammétrie classique est la réponse, et l’intérêt comme l’utilité pratique des approches de type NeRF augmentent progressivement
Cela dit, il est étonnant que les relations spatiales supplémentaires que l’on peut déduire du simple fait qu’il s’agisse d’une vidéo ne soient pas davantage mises en avant. On pourrait utiliser, pour l’estimation de la pose de la caméra, la contrainte selon laquelle la caméra ne peut se déplacer que de certaines manières entre les images
Il existe l’idée de faire tourner marching cubes sur les gaussiennes splattées pour en extraire un maillage, mais je ne crois pas avoir encore vu de cas concret
À la fin des années 90, on rendait des isosurfaces de voxels avec des blobs
On parcourait les voxels de surface dans tout le tableau 3D de voxels, puis on calculait les normales à partir du gradient de densité local avant de les quantifier en l’une de 240 valeurs
Ensuite, on utilisait une table de vecteurs de déplacement pour créer des chaînes de voxels de surface, et la plupart des voxels tenaient sur 2 octets : un indice de déplacement depuis le voxel précédent et un indice de vecteur normal
L’éclairage des 240 vecteurs normaux était précalculé et stocké dans une table de correspondance, et le logiciel pouvait remplir très rapidement le z-buffer avec de petits disques colorés
Le gros regret, à l’époque, était de ne pas pouvoir utiliser la perspective. Comme les vecteurs de déplacement étaient transformés en espace écran à chaque image, on peignait un blob, on appliquait un décalage, on consultait la couleur, puis on peignait à nouveau. Une valeur de déplacement servait à marquer la fin de la chaîne et la position absolue suivante à stocker, mais la plupart des voxels occupaient 2 octets