Spark – Un moteur de rendu 3D Gaussian Splatting avancé pour Three.js

 (sparkjs.dev)
3 points par GN⁺ 2025-06-13 | 1 commentaires | Partager sur WhatsApp
  • Spark est un moteur de rendu avancé conçu pour afficher du 3D Gaussian Splatting dans des scènes Three.js
  • Développé par World Labs, il permet de placer des splats aux côtés d’autres meshes dans des scènes existantes
  • Il vise un rendu rapide sur tous les appareils et se concentre sur la gestion de contenus splat dans divers environnements
  • Il prend en charge des effets splat dynamiques programmables, permettant de composer des effets dans la scène au-delà d’un simple affichage statique
  • Il prend en charge plusieurs formats, dont ply, sogs, spz, splat et ksplat, et la documentation officielle permet de démarrer immédiatement

Un moteur de rendu splat intégré aux scènes Three.js

  • Spark est un moteur de rendu 3D Gaussian Splatting pour Three.js
  • Il est développé par World Labs
  • Il s’intègre aux scènes Three.js existantes et peut être utilisé avec d’autres meshes et splats

Fonctionnalités de rendu et formats pris en charge

  • Il est présenté comme offrant un rendu rapide sur tous les appareils
  • Il prend en charge des effets splat dynamiques programmables
  • Les formats pris en charge sont les suivants
    • ply
    • sogs
    • spz
    • splat
    • ksplat
  • La documentation de démarrage est disponible dans Get started

À lire aussi

1 commentaires

 
GN⁺ 2025-06-13
Avis sur Hacker News

  • La démo est vraiment impressionnante et fonctionne bien même sur un vieil iPhone.
    En tant que développeur de jeux amateur sans grandes connaissances en programmation 3D, j’aimerais qu’il y ait quelque part sur GitHub ou sur le site une définition, ne serait-ce qu’en une ligne, de ce qu’est le Gaussian splatting.
    Rien que la définition de Wikipédia, du type « le Gaussian splatting est une technique de rendu volumique qui rend directement les données volumiques sans les convertir en primitives de surface ou de ligne », rendrait le projet et ses usages possibles bien plus prometteurs.
    Si cela permet de créer des nuages, du feu ou de la fumée hautes performances, ce serait vraiment génial.

    • Il faudrait absolument ajouter une FAQ.

  • La démo de scan de nourriture, en particulier la section d’exemples “Interactivity”, est incroyable.
    J’ai particulièrement aimé le passage où l’on regarde à l’intérieur des trous du pain dans le Mel's Steak Sandwich, et les performances sont étonnamment bonnes sur un GPU intégré de portable, vu le niveau de détail affiché.
    Je me demande où cette technique est aujourd’hui le plus couramment utilisée.

    • Il existe une communauté passionnée par le scan de petits objets avec des appareils portables ou des drones.
      Tipatat a fourni pas mal de scans de nourriture pour les démos, et j’aime aussi les scans de fleurs de kotohibi : https://superspl.at/user?id=kotohibi
    • Pour un tel niveau de détail, la taille de transfert n’est pas mauvaise non plus. Seulement environ 80 Mo.
      Ce n’est pas du sarcasme, c’est vraiment propre.

  • C’est aussi très sympa, et BabylonJS prend également assez bien en charge le Gaussian splatting : https://doc.babylonjs.com/features/featuresDeepDive/mesh/gau...

    • BabylonJS et Aframe [1], cité dans l’article d’origine, semblent similaires côté licence, nombre d’étoiles et de forks GitHub, mais Aframe paraît plus récent et davantage orienté jeux/VR.
      Ayant utilisé Babylon, Aframe, Three.js et PlayCanvas [2], je serais curieux de savoir comment ils se comparent.
      D’après ce que j’ai compris, PlayCanvas est le plus mature, le plus riche en fonctionnalités et performant, mais commercial ; Babylon est un moteur 3D riche en fonctionnalités ; et Three.js est assez brut. Il a de bons éléments comme l’animation, les textures, etc., mais on finit par avoir l’impression de construire soi-même sa propre boîte à outils.
      Je serais curieux de savoir si certains ont eu de bonnes ou de mauvaises expériences avec eux.
      La démo est vraiment stable. Je me demande quel est l’attrait principal d’Aframe.
      Je me demande aussi comment l’avenir du Gaussian splatting va se dessiner : s’il aura des usages au-delà de la visualisation ou des « jumeaux numériques » industriels, s’il sera bientôt possible de l’éditer ou de l’animer, et à quel moment il deviendra utile pour la création et les jeux.
      [1] https://github.com/aframevr/aframe
      [2] https://playcanvas.com/

  • Voici le lien du dépôt, un peu plus visible : https://github.com/sparkjsdev/spark

  • Très chouette.
    Je me demande où se situe actuellement le goulot d’étranglement des performances, et en particulier s’il y a des enseignements côté scènes dynamiques.
    L’exemple de simulation de particules saccade, puis s’améliore nettement quand on fait pivoter la caméra ; l’arrière-plan statique semble donc beaucoup plus lourd qu’il n’en a l’air.
    À l’inverse, indépendamment du goulot d’étranglement, la pyramide de Sierpinski générée procéduralement est excellente.

    • Le nombre de splats dans la scène et leur distribution influencent les performances.
      Il est probable que la caméra ait été orientée dans une direction contenant moins de splats.
      Il reste encore beaucoup à faire pour obtenir des performances constantes, et la prochaine étape sera probablement d’examiner un système de LOD.

  • Je reste assez sceptique quant à l’intérêt du Gaussian splatting au-delà des démos.
    Les fichiers sont trop volumineux. Par exemple, un seul sandwich au steak fait 12 Mo.
    Au SIGGRAPH l’an dernier, il y avait une réplique de Matterport basée sur le Gaussian splatting, et il fallait streamer 1,5 Go pour voir un appartement de deux pièces.
    La démo elle-même est sympa.

    • Il faut aussi noter que le sandwich au steak à 12 Mo est parmi les plus gros.
      Les autres font moins de 10 Mo, et plusieurs éléments assez convaincants sont dans la plage de 1 à 3 Mo. Par exemple, l’Iberico Sandwich fait 1 Mo, et Clams and Caviar 1,8 Mo.
      Des méthodes de compression plus avancées arrivent aussi. Par exemple SOGS. Celui-ci fait 30 Mo.
      https://vincentwoo.com/3d/sutro_tower/
    • La compression SOGS fonctionne bien.
      Elle permet de stocker environ un million de gaussiennes avec l’ensemble des coefficients d’harmoniques sphériques dans environ 14 Mo.
      Il y a un bon article sur le blog de PlayCanvas : https://blog.playcanvas.com/playcanvas-adopts-sogs-for-20x-3...
    • La grande taille des fichiers sert surtout à stocker les coefficients d’harmoniques sphériques, et c’est un problème qui peut être résolu.

  • Le travail est impressionnant, mais les performances sont assez mauvaises dans Firefox sur un ordinateur portable équipé d’un GPU Nvidia RTX A3000.
    Il y a ici assez de cœurs de shader pour provoquer une brûlure au premier degré.

    • C’est sur une démo ou un exemple en particulier ?

  • Est-ce qu’on pourrait se promener avec un téléphone et capturer des Gaussian splats d’herbe, de buissons, de terre, etc. ?
    Puis sélectionner un carré de terrain d’un mètre de côté, ou un volume cubique d’un mètre contenant un buisson, et construire un monde « façon Minecraft » en répétant des blocs d’herbe, avec parfois de la terre et des buissons mélangés ?
    Il faudrait sans doute du matériel assez puissant pour rendre des milliers de blocs.

    • On pourrait probablement faire un tel prototype.
      Je pense que ce serait vraiment superbe à voir.

  • Ça a vraiment l’air génial.
    Est-ce que ça fonctionnerait aussi en VR lorsqu’on ouvre la page dans un navigateur web ? Ce serait encore plus impressionnant.

    • Ça fonctionne en VR. Une démo sera publiée bientôt.