Show HN : 3D Gaussian Splatting en temps réel avec WebGL

 (antimatter15.com)
4 points par GN⁺ 2023-09-12 | 1 commentaires | Partager sur WhatsApp
  • Un visualiseur WebGL permettant d’ouvrir et de manipuler directement dans le navigateur des scènes 3D Gaussian Splat, avec le code d’implémentation publié sur GitHub
  • Prise en charge du clavier, de la souris, du trackpad, du tactile et même des manettes, couvrant largement les environnements de saisie desktop et mobile
  • Les contrôles de caméra sont répartis entre déplacement, rotation orbitale, inclinaison et roulis, avec différentes façons d’explorer la même scène selon le périphérique d’entrée
  • Les touches numériques ainsi que -, + et p permettent de passer à des vues caméra préchargées, de parcourir les caméras et de reprendre l’animation par défaut
  • Il est possible de glisser-déposer des fichiers .ply pour les convertir en .splat, et de charger les réglages de caméra via cameras.json

WebGL 3D Gaussian Splat Viewer

  • WebGL 3D Gaussian Splat Viewer est un visualiseur 3D Gaussian Splat créé par Kevin Kwok
  • Le code est publié sur Github

Contrôles par périphérique d’entrée

  • Déplacement au clavier

    • Flèche gauche/droite : déplacement latéral
    • Flèche haut/bas : déplacement avant/arrière
    • Space : saut

  • Angle de caméra

    • a / d : rotation gauche/droite de la caméra
    • w / s : inclinaison haut/bas de la caméra
    • q / e : roulis antihoraire/horaire de la caméra
    • i / k, j / l : rotation orbitale

  • Trackpad

    • Défilement : rotation orbitale haut/bas/gauche/droite
    • Pincement : déplacement avant/arrière
    • Ctrl + défilement : déplacement avant/arrière
    • Shift + défilement : déplacement vertical ou latéral

  • Souris

    • Cliquer puis faire glisser : rotation orbitale
    • Clic droit, ou glissement vers le haut/bas avec la touche Ctrl/Cmd : déplacement

  • Tactile

    • Un doigt : rotation orbitale
    • Pincement à deux doigts : déplacement avant/arrière
    • Rotation à deux doigts : rotation horaire/antihoraire de la caméra
    • Panoramique à deux doigts : déplacement latéral et vertical

  • Manette

    • Fonctionne si une manette de jeu est connectée

Caméra et gestion des fichiers

  • Contrôle des vues caméra

    • 0-9 : passer à l’une des vues caméra préchargées
    • - ou + : parcourir les caméras chargées
    • p : reprendre l’animation par défaut

  • Glisser-déposer

    • Fichier .ply : conversion en .splat
    • cameras.json : chargement des caméras

À lire aussi

1 commentaires

 
GN⁺ 2023-09-12
Commentaires sur Hacker News

  • C’est vraiment impressionnant, mais les contrôles prêtent à confusion
    Au lieu du déplacement WASD classique avec rotation de la vue à la souris, le glisser de la souris sert à avancer/reculer et à orbiter autour d’un point donné, A/D déplacent à gauche/droite, et W/S font regarder vers le haut/bas
    La liste complète des contrôles est dans le README : https://github.com/antimatter15/splat#controls

    • Je suis l’auteur, désolé si les contrôles de caméra sont pénibles. J’accepterai volontiers les pull requests qui les rendent plus logiques
      À l’origine, l’idée était de pouvoir se déplacer uniquement avec les flèches, en tournant sur place et en marchant en avant/arrière
    • C’est assez proche des contrôles FPS de la N64, par exemple GoldenEye
      Les flèches/le joystick servent au « déplacement principal » — avancer/reculer et tourner à gauche/droite — tandis que WASD/les boutons C servent au « déplacement secondaire » — translation gauche/droite et vue haut/bas
    • Pour ma part, j’ai plutôt aimé le mode de contrôle uniquement à la souris
    • Franchement, les contrôles sont tellement peu intuitifs et horribles que je suis resté bloqué avant même de pouvoir apprécier la démo de rendu

  • Vraiment impressionnant. Je travaille moi aussi sur un portage de gaussian-splatting [0] vers WebGPU
    Comme d’autres implémentations que j’ai vues jusqu’ici, celle-ci semble faire la même erreur lorsqu’elle projette des ellipsoïdes en projection perspective. Elle calcule d’abord la covariance en 3D puis la projette en 2D [1], mais cette approche n’est correcte qu’en projection parallèle/orthographique ; appliquée à la perspective, elle donne des résultats erronés
    En projection perspective, il y a trois effets supplémentaires. Le déplacement de parallaxe modifie la forme de l’ellipse projetée, la rotation de l’ellipsoïde peut changer sa position apparente en créant une translation supplémentaire, et une conique peut être non seulement une ellipse, mais aussi une parabole ou une hyperbole
    Le premier effet semble être corrigé manuellement avec cette matrice [2], mais les deux autres effets n’étaient pris en compte dans aucune des implémentations que j’ai vues jusqu’ici. Pour faire les choses correctement, il ne faut pas calculer la covariance 3D : il faut déterminer le cône tangent à l’ellipsoïde dont le sommet est la position de la caméra, puis l’intersecter avec le plan de vue. La conique obtenue donne le contour exact de l’ellipsoïde projeté en perspective
    [0] : https://github.com/graphdeco-inria/gaussian-splatting
    [1] : https://github.com/antimatter15/splat/blob/3695c57e8828fedc2...
    [2] : https://github.com/antimatter15/splat/blob/3695c57e8828fedc2...

    • En général, une gaussienne n’est plus vraiment une gaussienne après projection par la caméra, car la fonction de projection d’une caméra sténopé divise par z, ce qui la rend non linéaire
      Mais si la gaussienne est petite par rapport à la taille de l’image, on peut linéariser la fonction de projection pour l’approximer. C’est pourquoi l’article sur le Gaussian Splatting utilise le jacobien de la fonction de projection, comme dans l’équation 5 [0]
      En pratique, cette approximation fonctionne très bien. La matrice mentionnée dans le troisième lien est précisément ce jacobien ; ce n’est pas une correction manuelle, mais quelque chose de mathématiquement valide. Voir [1] pour la dérivation
      [0] https://repo-sam.inria.fr/fungraph/3d-gaussian-splatting/3d_...
      [1] https://math.stackexchange.com/a/4716514/43771
    • Ça me semble juste. En gros, on traite la projection comme une transformation linéaire en coordonnées cartésiennes, puis on transforme la gaussienne avec
      Vu autrement, on approxime la projection en supposant que toute la gaussienne se trouve à une profondeur fixe ; si elle est suffisamment éloignée, ça devrait fonctionner
      La transformation projective d’une gaussienne a l’air assez pénible, mais j’imagine que quelqu’un a déjà dû le faire. En coordonnées projectives, ça paraît possible, mais la dernière étape de projection en coordonnées cartésiennes est délicate
      À noter que projeter seulement le contour est également faux. Toute la distribution de densité change, et cela influence aussi le contour
    • Je ne connais pas bien la technique du gaussian splat, mais au fond, n’est-ce pas essentiellement un maillage de quadrilatères avec des données internes aux sommets ?
      Je pensais que la projection de quadrilatères était déjà un problème résolu ; pourrais-tu expliquer davantage en quoi c’est différent d’un simple tableau de quadrilatères ?
    • Si l’idée d’intersection avec le cône tangent pouvait être implémentée sans affecter le framerate, ce serait probablement plus fluide en WebGPU. Cela dit, ce serait intéressant de voir la différence comparée dans les mêmes conditions qu’une implémentation comme celle-ci

  • Quand on dézoome, on voit beaucoup d’arêtes polygonales qui ne devraient pas vraiment être là
    On dirait qu’on essaie de dessiner des « blobs » lisses, mais avec des coordonnées de texture légèrement décalées ; je me demande si c’est un bug ou un aspect voulu de la technique

    • C’est voulu
      À la base, c’est un nuage de points semi-dense [1], sauf qu’au lieu de points, il y a des blobs dont la couleur, l’angle et la taille sont ajustés pour correspondre aux photos d’entrée. C’est donc optimisé pour être regardé depuis une certaine distance
      On peut voir ça comme du dessin vectoriel 3D. Si l’on zoome trop ou qu’on en isole une partie, l’ensemble commence à paraître un peu étrange
      [1]https://www.researchgate.net/publication/326621750/figure/fi...

  • Jusqu’ici, je n’avais vu le gaussian splatting utilisé que pour des données photo
    Est-ce qu’on pourrait l’utiliser aussi pour d’autres données graphiques ? Autrement dit, y a-t-il un potentiel pour les jeux ?

    • Ça dépend du contexte. Les approches de champ de rayonnement comme le gaussian splatting sont, fondamentalement, de la photo 3D
      Elles ne stockent que la couleur en fonction de la position et de l’orientation géométriques, sans notions de surface, de matériau ni de transport de la lumière au sens général — émission, absorption, transmission, réflexion, diffusion, etc. Autrement dit, elles ne permettent que de l’éclairage précalculé et des scènes statiques, et l’animation est difficile
      Le secteur semble plutôt aller vers des méthodes permettant un meilleur éclairage dynamique, comme le rendu physiquement réaliste (PBR) et le ray/path tracing
      De plus, l’efficacité spatiale est pour l’instant extrêmement faible. Une scène qui prendrait quelques dizaines de Go avec un moteur de rendu traditionnel peut atteindre des téraoctets. Cela dit, cela pourrait s’améliorer avec davantage d’optimisations
      Les cas où le gaussian splatting pourrait être particulièrement intéressant sont les contenus procéduraux/génératifs, éventuellement jusqu’à l’animation. Il pourrait notamment bien convenir aux effets volumétriques qui utilisent aujourd’hui des systèmes de particules, comme la fumée, le feu, les nuages ou l’eau qui s’écoule
    • Il n’y a pas vraiment de raison que ce soit impossible. Au final, ce n’est qu’un joli nuage de points
      On peut facilement imaginer un jeu open world façon Minecraft qui utiliserait ça comme moteur de base à la place des voxels

  • Cette technique fonctionnerait-elle aussi pour la vidéo ?
    À en juger par le README du travail de l’INRIA[1], on dirait qu’un modèle est entraîné pour chaque scène statique ; est-ce que cela exclut donc la vidéo ?
    [1] https://github.com/graphdeco-inria/gaussian-splatting

  • Qu’est-ce que je suis en train de regarder, au juste ?

    • Gaussian splatting est une façon élégante de désigner un nuage de points qui utilise des formes colorées au lieu de points
      La méthode existe depuis longtemps, mais elle n’était pas très utilisée : quand un nuage de points contient un million de points, il faut manipuler artistiquement ce million de points
      C’est un peu comme les cheveux en 3D. Le principe est simple — il suffit de rendre un milliard de mèches — mais obtenir quelque chose de vraiment beau est difficile
      Ici, on demande à un modèle de machine learning d’ajuster l’angle, la couleur, la forme et la taille d’un million de primitives — par exemple des carrés, des cercles, des triangles, etc. — pour qu’elles ressemblent aux photos qu’on lui fournit
    • En gros, c’est ce travail-ci : https://github.com/graphdeco-inria/gaussian-splatting — une approche un peu différente pour rendre des scènes 3D

  • Est-ce que cela utilise la méthode proposée par Kerbl et Kopanas à SIGGRAPH 2023 ?
    https://repo-sam.inria.fr/fungraph/3d-gaussian-splatting/

    • Oui. Mais ici, seule la partie splatting/rendu est implémentée, pas la partie optimisation qui génère la reconstruction initiale

  • C’est vraiment impressionnant. Les nuages de points sont déjà intéressants, mais là c’est encore bien plus bluffant. Ça tourne à 60 fps même sur le portable Lenovo que j’utilise au travail

    • Ça tourne aussi à 36 fps sur un smartphone milieu de gamme. Je ne m’y attendais pas
      Cela dit, on voit beaucoup d’artefacts, surtout quand on déplace la caméra

  • Si quelqu’un arrive à faire fonctionner ça dans ThreeJS, ça pourrait marquer l’histoire de la 3D web

  • Je n’avais jamais rencontré ce genre de contrôle à la souris dans une vue 3D, donc j’ai été très dérouté pendant un moment