- In die THREE.js-Rendering-Pipeline integriert und zeigt splat- und mesh-basierte Objekte gemeinsam an
- Hoch portabel und läuft auf nahezu allen Geräten (mehr als 98 % mit WebGL2-Unterstützung)
- Bietet schnelle Rendering-Leistung auch auf leistungsarmen Mobilgeräten
- Rendert mehrere Splat-Objekte gleichzeitig und verarbeitet dabei auch die Sortierung korrekt
- Unterstützt die meisten wichtigen Splat-Dateiformate wie .PLY (einschließlich Komprimierung), .SPZ, .SPLAT, .KSPLAT
- Unterstützt gleichzeitiges Rendering aus mehreren Perspektiven
- Dynamische Bearbeitung: Jedes Splat-Objekt kann individuell transformiert und animiert werden
- Unterstützt Echtzeit-Farbbearbeitung, Deformation und Skelettanimation
- Mit einem Shader-Graph-System können Splats dynamisch auf der GPU erzeugt und bearbeitet werden
1 Kommentare
Hacker-News-Kommentare
Wirkt wie eine extrem beeindruckende Demo, läuft sogar auf meinem alten iPhone gut.
Als Hobby-Spieleentwickler ohne viel professionelles 3D-Programmierwissen wäre mein Feedback: Es wäre schön, wenn irgendwo auf GitHub oder der Website ein Einzeiler stünde, der erklärt, was „Gaussian Splatting“ eigentlich ist.
Durch die Ein-Satz-Erklärung aus der Wikipedia fand ich es gleich viel interessanter und sah mehr Potenzial.
Gaussian Splatting ist eine Volumen-Rendering-Technik, bei der volumetrische Daten direkt gerendert werden, ohne sie in Oberflächen- oder Linienprimitive umzuwandeln.
Dass man damit performante Wolken, Feuer, Rauch usw. erzeugen kann, ist wirklich cool.
Ich denke, wir sollten auf jeden Fall ein FAQ hinzufügen.
Die Demo mit dem Essensscan (das Beispiel „Interactivity“) ist erstaunlich.
Besonders beeindruckend fand ich es, bei Mel's Steak Sandwich in die Löcher im Brot hineinzuschauen.
Selbst mit nur integrierter Grafik in meinem Laptop ist die Performance gemessen an den sichtbaren Details hervorragend.
Ich frage mich, wofür diese Technik derzeit hauptsächlich eingesetzt wird.
Es gibt eine Community, die kleine Objekte mit Handheld-Geräten oder Drohnen scannt.
Tipatat hat den Essensscan für diese Demo beigesteuert.
Ich mag auch die Blumenscans von kotohibi.
https://superspl.at/user?id=kotohibi
Für dieses Detailniveau ist die übertragene Datenmenge gar nicht so groß.
Ungefähr 80 MB, was ich wirklich erstaunlich finde.
Wirklich cool.
BabylonJS unterstützt Gaussian Splats ebenfalls gut.
https://doc.babylonjs.com/features/featuresDeepDive/mesh/gaussianSplatting
Aframe ist das neuere Projekt und stärker auf Games und VR fokussiert.
Mich würde aus Sicht von jemandem interessieren, der Babylon, Aframe, Three.js und PlayCanvas alle benutzt hat, wie sie sich vergleichen.
PlayCanvas ist kommerziell, aber am reifsten, am funktionsreichsten und bietet die beste Performance.
Babylon ist eher eine funktionsorientierte 3D-Engine, während Three.js nur das Nötigste bereitstellt.
Animation und Texturunterstützung sind gut, aber am Ende muss man sich doch sein eigenes Toolkit bauen.
Mich würden gute und schlechte Erfahrungen mit diesen Engines interessieren.
Die Demo des OP ist wirklich solide.
Ich frage mich, was genau die Stärken und das Versprechen von Aframe sind.
Außerdem würde mich interessieren, wie sich die Zukunft von Gaussian Splatting entwickelt – nicht nur für reine Visualisierung oder die Digital-Twin-Industrie, sondern ob Bearbeitung und Animation bald auch in kreativen Bereichen oder Spielen möglich sein werden.
Aframe GitHub
PlayCanvas
Tolle Arbeit.
Aber auf meinem Laptop mit Nvidia RTX A3000 GPU und Firefox ist die Performance sehr schlecht.
Bei so vielen Shader-Cores kann das Gerät schon fast so heiß werden, dass man sich die Hände verbrennt.
Ich frage mich, ob man mit dem Handy herumrennen und Gaussian Splats von Gras, Büschen, Erde usw. aufnehmen kann.
Also etwa einen 1-Meter-Quadrat-Fleck Boden oder einen 1-Meter-Würfel mit einem Busch auswählen
und dann Grasblöcke wiederholt platzieren, dazwischen Büsche oder Erde mischen und so eine „Minecraft-artige“ Welt bauen.
Für das Rendern von Tausenden solcher Blöcke bräuchte man vermutlich ziemlich leistungsstarke Hardware.
In echt zu sehen wäre das wirklich cool.
Wirklich beeindruckend.
Gibt es vielleicht Einblicke in die aktuellen Performance-Engpässe?
Besonders interessieren mich die Engpässe bei dynamischen Szenen.
Das Partikelsimulations-Beispiel ruckelt, aber wenn ich die Kamera drehe, wird die Performance plötzlich deutlich besser.
Das wirkt so, als wäre der statische Hintergrund schwerer als gedacht; unabhängig davon ist die Sierpinski-Pyramide auf prozedurale Weise wirklich beeindruckend.
Es kann auch sein, dass du die Kamera einfach in eine weniger komplexe Richtung gedreht hast.
Daran, die Performance gleichmäßiger zu machen, gibt es noch Arbeit.
Als Nächstes planen wir ein LOD-System.
Ein etwas auffälligerer Hinweis auf das Repo.
https://github.com/sparkjsdev/spark
Ich bin immer noch skeptisch, ob Gaussian Splatting mehr als nur Demos leisten kann.
Die Dateigrößen sind zu groß.
Zum Beispiel ist das Steak-Sandwich 12 MB groß.
Letztes Jahr auf der SIGGRAPH habe ich einen auf Gaussian Splats basierenden Matterport-Port-Klon gesehen, bei dem man 1,5 GB streamen musste, um sich eine 2-Zimmer-Wohnung anzuschauen.
Coole Demo.
Die SOGS-Kompressionstechnik ist effektiv.
1M Gaussians lassen sich einschließlich voller Spherical Harmonics in etwa 14 MB speichern.
Im PlayCanvas-Blog gibt es einen guten Beitrag dazu.
https://blog.playcanvas.com/playcanvas-adopts-sogs-for-20x-3dgs-compression
Zur Einordnung: Das 12-MB-Steak-Sandwich ist die größte Datei.
Die übrigen liegen unter 10 MB, einige sogar bei sehr überzeugenden 1–3 MB.
(z. B. Iberico Sandwich 1 MB, Clams and Caviar 1.8 MB usw.)
Fortgeschrittene Kompressionsverfahren wie SOGS kommen bald.
Dieses Beispiel hier hat 30 MB.
https://vincentwoo.com/3d/sutro_tower/
Der Hauptgrund für die großen Dateien ist, dass die Spherical-Harmonics-Koeffizienten gespeichert werden müssen.
Das ist ein lösbares Problem.
Ich habe den Eindruck, der Name ist schon ziemlich überstrapaziert.
Es gibt bereits Apache Spark, SPARK (Ada), Sparklines und SPARQL.
https://en.wikipedia.org/wiki/SPARC