CityGaussian : rendu de scènes à grande échelle en temps réel et en haute qualité avec des gaussiennes
(dekuliutesla.github.io)- CityGaussian (CityGS) est une méthode présentée à l’ECCV 2024 qui étend le 3D Gaussian Splatting (3DGS) à des scènes à l’échelle d’une ville, avec l’objectif d’améliorer à la fois l’efficacité de l’apprentissage et la qualité de l’exploration en temps réel
- Pour surmonter la difficulté de traiter de grandes scènes en une seule fois, l’approche combine un apprentissage par division pour régner et une stratégie de niveau de détail (LoD)
- En s’appuyant sur des informations globales préalables sur la scène et sur une sélection adaptative des données d’apprentissage, elle aligne plus efficacement les résultats appris bloc par bloc et les fusionne de manière fluide
- Les primitives gaussiennes fusionnées sont compressées pour créer plusieurs niveaux de détail, puis le rendu sélectionne et agrège le niveau approprié pour chaque bloc
- Sans LoD, représenter MatrixCity avec 25 millions de gaussiennes plafonne à 18 FPS sur un A100, tandis que CityGS avec LoD atteint un rendu en temps réel à 36 FPS en moyenne
Structure d’apprentissage et de rendu pour le 3DGS à grande échelle
- Le 3D Gaussian Splatting (3DGS) a démontré ses points forts pour la reconstruction de scènes 3D en temps réel et la synthèse de nouveaux points de vue, mais l’apprentissage sur des scènes de grande taille et le rendu en temps réel à différentes échelles restent coûteux
- CityGaussian aborde ce problème en deux étapes
- Apprentissage par division pour régner : la scène à grande échelle est découpée en blocs pour être apprise plus efficacement
- Stratégie LoD : seul le niveau de détail nécessaire est utilisé selon l’échelle d’observation afin d’accélérer le rendu
- Les informations globales préalables sur la scène et la sélection adaptative des données d’apprentissage améliorent l’efficacité de l’apprentissage et aident à fusionner plus naturellement les fragments de scène séparés
- Les primitives gaussiennes fusionnées passent par un processus de compression pour former plusieurs niveaux de détail
- À l’étape de rendu, une stratégie de sélection et d’agrégation du niveau de détail par bloc permet une génération d’image rapide à plusieurs échelles
Performances et ressources publiques
- Sans application du LoD, la scène MatrixCity est représentée par 25 millions de gaussiennes et mesurée à 18 FPS sur un A100
- Cette vitesse est jugée insuffisante pour offrir une expérience de navigation fluide
- CityGS avec LoD permet un rendu en temps réel même à des échelles très différentes, avec une moyenne de 36 FPS sur A100
- Dans les expériences sur des scènes à grande échelle, CityGS affiche une qualité de rendu de tout premier plan et prend en charge un rendu temps réel cohérent sur de grandes scènes à différentes échelles
- Ressources publiques
1 commentaires
Avis sur Hacker News
Vu que le nom du dataset de la vidéo est Matrix city, il est très probable qu’il ait été extrait de la démo Matrix d’Unreal Engine 5 publiée il y a quelques années
Les points de vue sont très similaires, donc le rendu est photoréaliste, mais il ne semble pas provenir de vraies photos
En cherchant davantage, c’était bien ça : https://city-super.github.io/matrixcity/
Ce qui est amusant, c’est que l’article original reviendrait alors à reconstruire à nouveau des objets réels déjà reconstruits
La carte de MatrixCity est différente, mais elle ressemble dans une certaine mesure à celle de Matrix Awakens. On peut aussi le voir dans l’analyse de conception de [3] cette page écrite par le responsable technique du projet Matrix Awakens
En allant plus loin, la section MatrixPlugin du code source GitHub [4] indique explicitement que le projet city-sample a été utilisé
[1] https://www.unrealengine.com/marketplace/en-US/product/city-...
[2] https://www.unrealengine.com/marketplace/en-US/learn/city-sa...
[3] https://quentinmarmier.artstation.com/projects/xYeKNO
[4] https://github.com/city-super/MatrixCity
Cela facilite donc un peu l’entraînement de NeRF ou du Gaussian Splatting, car il n’y a pas d’erreur d’optimisation sur la pose de la caméra
C’est aussi pour cette raison que les premiers articles sur NeRF utilisaient la célèbre pelleteuse Lego jaune rendue avec Blender
Pour une scène comme Matrix city, il ne semble pas nécessaire de passer beaucoup de temps à entraîner un modèle juste pour reproduire les données
J’ai essayé ce week-end d’assembler le mesh 3D Tiles de Google Maps avec du Gaussian Splatting ; ce n’est pas exactement la même chose, mais l’effet était assez proche et utile
Exemple 1 avec code lié : https://twitter.com/kfarr/status/1773934700878561396
Exemple 2 : https://twitter.com/3dstreetapp/status/1775203540442697782
Une erreur apparaît dans les outils de développement sur le premier lien
Uncaught (in promise) Error: Failed to fetch resource [https://tile.googleapis.com/v1/3dti](<https://tile.googleapis.com/v1/3dti>;)...Je vais regarder aframe-loader-3dtiles-component
« Vitesse moyenne de 36 FPS (testé sur A100) » : on dirait que « temps réel » veut dire qu’il faut un GPU à 8 000 $
Quand un article de graphisme affirme avoir atteint des performances en temps réel, il faut toujours vérifier si c’est vraiment du temps réel, ou bien du genre « 20 fps en 640x480 sur le matériel le plus cher qu’on puisse acheter »
Si on baisse assez le niveau d’exigence, tout peut devenir temps réel
Ça pourrait devenir utile pour des usages comme la production virtuelle, mais sans doute pas pour le mobile
https://www.techpowerup.com/forums/attachments/all-cards-png...
Si vous voulez quelque chose qui tourne sur un ordinateur portable vieux de 10 ans, voire sans GPU, regardez https://github.com/pierotofy/OpenSplat. C’est moi qui l’ai créé
Donc cela ne semble pas être un problème insurmontable
Quelqu’un peut-il me convaincre que le 3D Gaussian splatting n’est pas une impasse ?
Le rendu est bien trop lent, d’un facteur à un chiffre, et les données sont aussi bien trop volumineuses, d’un facteur à un chiffre. Ça donne l’impression de revoir l’opposition entre rastérisation et ray tracing.
La rastérisation sera toujours plus rapide que le ray tracing, et si le ray tracing devient 10 fois plus rapide, la rastérisation le deviendra aussi 10 fois
Générer une géométrie et des matériaux traditionnels à partir d’un nuage de points gaussiens peut être intéressant. Mais la photogrammétrie existe déjà depuis longtemps
Essayer de rendre en temps réel une ville gigantesque avec des splats ne donne pas l’impression d’aller dans la “bonne direction”
C’est cool, amusant et intéressant, mais je ne sais pas si ça deviendra vraiment utile. Je pose sérieusement la question, je ne suis pas expert
La plupart des recherches actuelles ne se concentrent pas sur les performances, et il n’existe même pas encore de consensus sur un format unifié, y compris pour la compression
Le potentiel d’optimisation est très clair, et c’est aussi facile à adapter à différents appareils. Un peu comme les LOD de nuages de points ou le culling de meshes
Les performances des splats peuvent être un avantage compétitif temporaire pour certains viewers, mais comme le décodage vidéo ou d’autres standards 3D se sont diffusés en open source, il est très probable que, dans quelques années, l’affichage de splats de haute qualité à fréquence d’images élevée devienne une exigence de base sur la plupart des appareils
La vraie question ensuite, c’est : à quoi va-t-on s’en servir ?
Plus de 100 fps dans le navigateur : https://current-exhibition.com/laboratorio31/
900 fps : https://m-niemeyer.github.io/radsplat/
Les moteurs traditionnels cumulent 30 ans de R&D, donc il faudra du temps pour que les outils et les optimisations rattrapent leur niveau
Mais quand on regarde d’où sortent les papiers, on voit souvent Apple et Meta, et ça ressemble à la technologie qui fera tourner l’ère du métavers / spatial computing que ces deux entreprises poussent
La capacité à transformer des contenus à très faible coût de production, comme des vidéos d’iPhone, en environnements 3D va balayer une grande partie de la R&D des approches traditionnelles
Elle a aussi beaucoup de mal à capturer les détails fins comme les structures minces ou les cheveux. La 3DGS est bonne sur ce terrain
Des recherches sont en cours pour améliorer ses faiblesses actuelles, y compris des méthodes d’extraction de meshes utilisables dans les pipelines graphiques traditionnels
La photogrammétrie ne fonctionne bien que quand les données de surface sont propres, alors que les Gaussian splats excellent sur des données semi-volumétriques comme la fourrure, la végétation, les particules ou les surfaces rugueuses
Ils conviennent aussi bien aux surfaces brillantes ou réfléchissantes, aux volumes aux propriétés de surface très fragmentées, et aux matériaux fortement dépendants du point de vue
Pour des usages relevant d’une vraie photo 3D complète, c’est plutôt génial et c’est un cas d’usage tout à fait valable
Pour un moteur de jeu 3D, j’ai l’impression qu’il est difficile de manipuler dynamiquement les primitives de base comme le demandent les moteurs de jeu. Il y aura d’autres tentatives, mais sous cet angle les gaussiennes ressemblent davantage à un format de rendu final qu’à une représentation intermédiaire utile
Pour un usage pratique dans un moteur, il faudra inventer autre chose pour combler l’écart, et il reste encore beaucoup de questions ouvertes
Je ne sais pas pour les autres usages, mais le monde ne se résume pas aux jeux 3D et aux effets visuels
Il y a tellement de choses portant le nom de Gauss, et le fait qu’on continue à en créer de nouvelles, comme le Gaussian splatting, rappelle de façon assez amusante à quel point Gauss a influencé de nombreux domaines
Ce n’est pas lui qui l’a inventé directement, mais il a énormément contribué aux mathématiques derrière tout ça
https://en.wikipedia.org/wiki/Monte_Carlo_(disambiguation)
Rien que dans la section “Science and Technology”, il y en a 8
J’ai hâte de voir sous quelle licence ce sera publié
J’aimerais voir un jeu open source qui utilise ça
L’histoire est pleine d’approches qui semblaient prometteuses comme alternative aux meshes triangulaires, avant de disparaître quand on s’est aperçu qu’il n’existait pas de moyen efficace de les animer
Les objets dans le nuage de points n’embarquent pas de métadonnées intrinsèques du type “chaise, table, personne”, donc toute interaction devient très compliquée
Ce n’est pas impossible, mais ce n’est pas pratique aujourd’hui
Et en plus, ce n’est pas particulièrement optimisé pour le rendu temps réel. Même avec beaucoup de points élagués, utiliser un mesh basse résolution est bien plus efficace
Ça n’a pas l’air beaucoup mieux que quelque chose comme Cities: Skylines
Il n’y a ni zoom avant ni zoom arrière, et on voit toujours des frames très limitées, donc est-ce que je rate quelque chose ?
Le papier renvoie à plusieurs reprises à MatrixCity, et https://city-super.github.io/matrixcity/ — trouvé aussi par quelqu’un plus haut — indique clairement qu’il s’agit de données entièrement synthétiques
Si j’ai bien compris, elles sont extraites d’Unreal Engine
J’apprends avec pygame et je me demande comment ajouter du motion blur dans un jeu
Par exemple, si je crée Mario avec pygame, j’aimerais qu’il paraisse flou quand il saute
Je pourrais faire une version floue de Mario en prenant la moyenne de 9 pixels, mais je ne sais pas si c’est aussi comme ça qu’on fait d’habitude dans d’autres jeux
Beaucoup de jeux sont aussi très nets sans motion blur, donc je me demande si c’est réellement utilisé
C’est un élément assez important au cinéma, et ça me fait aussi penser qu’il faut filmer à 25 fps pour obtenir un motion blur cinématographique
Autrement dit, on calcule la vitesse de chaque objet, on la rend sous forme de couleur, puis on l’utilise à l’étape de post-traitement pour déterminer l’intensité et la direction de l’effet de flou
Il peut aussi falloir prendre en compte le mouvement par rapport à la caméra. Pour Mario, probablement pas, mais dans un FPS, on voudra que les bords de l’écran deviennent flous quand la caméra avance
Ressource associée : https://city-super.github.io/octree-gs/
C’est une approche assez avancée pour rendre de plus grandes scènes avec des gaussiennes 3D, donc j’ai hâte de tester le code dès sa publication