Show HN: Echtzeit-3D-Gaussian-Splatting in WebGL

 (antimatter15.com)
4 Punkte von GN⁺ 2023-09-12 | 1 Kommentare | Auf WhatsApp teilen
  • Ein WebGL-Viewer, mit dem sich 3D-Gaussian-Splat-Szenen direkt im Browser öffnen, ansehen und steuern lassen; der Implementierungscode ist auf GitHub veröffentlicht
  • Unterstützt Tastatur, Maus, Trackpad, Touch und sogar Gamepads und deckt damit **Desktop- und Mobile-**Eingabeumgebungen breit ab
  • Die Kamerasteuerung ist in Bewegung, Orbit-Drehung, Neigung und Roll unterteilt, sodass dieselbe Szenenerkundung je nach Eingabegerät auf unterschiedliche Weise möglich ist
  • Über die Zifferntasten sowie -, + und p lassen sich vorgeladene Kameraperspektiven umschalten, Kameras durchschalten und die Standardanimation fortsetzen
  • .ply-Dateien können per Drag-and-Drop in .splat umgewandelt werden, und mit cameras.json lassen sich Kameraeinstellungen laden

WebGL 3D Gaussian Splat Viewer

  • Der WebGL 3D Gaussian Splat Viewer ist ein 3D-Gaussian-Splat-Viewer von Kevin Kwok
  • Der Code ist auf Github veröffentlicht

Steuerung nach Eingabegerät

  • Tastaturbewegung

    • Linke/rechte Pfeiltaste: nach links/rechts bewegen
    • Pfeil nach oben/unten: vorwärts/rückwärts bewegen
    • Space: springen

  • Kamerawinkel

    • a / d: Kamera nach links/rechts drehen
    • w / s: Kamera nach oben/unten neigen
    • q / e: Kamera gegen den/im Uhrzeigersinn rollen
    • i / k, j / l: Orbit-Drehung

  • Trackpad

    • Scrollen: Orbit-Drehung nach oben/unten/links/rechts
    • Pinch: vorwärts/rückwärts bewegen
    • Ctrl + Scrollen: vorwärts/rückwärts bewegen
    • Shift + Scrollen: nach oben/unten oder links/rechts bewegen

  • Maus

    • Klicken und ziehen: Orbit-Drehung
    • Rechtsklick oder vertikales Ziehen zusammen mit der Ctrl-/Cmd-Taste: Bewegung

  • Touch

    • Ein Finger: Orbit-Drehung
    • Zwei-Finger-Pinch: vorwärts/rückwärts bewegen
    • Zwei-Finger-Drehung: Kamera im oder gegen den Uhrzeigersinn drehen
    • Zwei-Finger-Pan: nach links/rechts und oben/unten bewegen

  • Gamepad

    • Funktioniert, wenn ein verbundener Gamecontroller vorhanden ist

Kamera und Dateiverarbeitung

  • Kameraperspektiven steuern

    • 0-9: zu einer der vorgeladenen Kameraperspektiven wechseln
    • - oder +: durch geladene Kameras schalten
    • p: Standardanimation fortsetzen

  • Drag-and-Drop

    • .ply-Datei: in .splat umwandeln
    • cameras.json: Kamera laden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-12
Meinungen auf Hacker News

  • Wirklich beeindruckend, aber die Steuerung ist verwirrend.
    Statt der üblichen WASD-Bewegung und Maussteuerung für die Blickrichtung bewirkt Ziehen mit der Maus Vorwärts-/Rückwärtsbewegung und eine Orbit-Rotation um einen bestimmten Punkt; A/D bewegt nach links/rechts, W/S lässt nach oben/unten schauen.
    Die vollständige Liste der Steuerung steht im README: https://github.com/antimatter15/splat#controls

    • Ich bin der Autor; sorry, dass die Kamerasteuerung unbequem ist. Pull Requests, die sie auf eine sinnvollere Weise ändern, nehme ich gern an.
      Ursprünglich war die Idee, sich nur mit den Pfeiltasten bewegen zu können: sich auf der Stelle drehen und vorwärts/rückwärts gehen.
    • Das ist N64-FPS-Steuerung, etwa ziemlich ähnlich wie bei GoldenEye.
      Mit Pfeiltasten/Joystick macht man die „Hauptbewegung“ aus Vorwärts-/Rückwärtsbewegung und Links-/Rechtsdrehung, mit WASD/C-Buttons die „Nebenbewegung“ aus Seitwärtsbewegung und Blick nach oben/unten.
    • Nur als Hinweis: Die reine Maussteuerung gefiel mir ziemlich gut.
    • Ehrlich gesagt ist die Steuerung so unintuitiv und furchtbar, dass ich hängen blieb, bevor ich die Rendering-Demo überhaupt genießen konnte.

  • Wirklich cool. Ich arbeite ebenfalls daran, gaussian-splatting [0] auf WebGPU zu portieren.
    Wie bei anderen Implementierungen, die ich bisher gesehen habe, scheint auch diese denselben Fehler bei der Projektion von Ellipsoiden in der perspektivischen Projektion zu machen: Zuerst wird die Kovarianz in 3D berechnet und dann nach 2D projiziert[1]. Dieser Ansatz ist nur bei Parallel-/Orthogonalprojektion korrekt; bei perspektivischer Projektion liefert er falsche Ergebnisse.
    Bei perspektivischer Projektion gibt es drei zusätzliche Effekte: Parallaxenverschiebung verändert die Form der projizierten Ellipse; die Rotation des Ellipsoids kann die scheinbare Position verändern und dadurch eine zusätzliche Translation erzeugen; und Kegelschnitte können nicht nur Ellipsen, sondern auch Parabeln oder Hyperbeln sein.
    Der erste Effekt scheint durch diese Matrix[2] manuell korrigiert zu werden, aber die letzten beiden Effekte sind in den Implementierungen, die ich bisher gesehen habe, nicht in die Berechnung eingeflossen. Korrekt wäre, nicht die 3D-Kovarianz zu berechnen, sondern den Tangentialkegel des Ellipsoids mit der Kameraposition als Spitze zu bestimmen und ihn dann mit der Bildebene zu schneiden. Der daraus entstehende Kegelschnitt ist die exakte Kontur des perspektivisch projizierten Ellipsoids.
    [0]: https://github.com/graphdeco-inria/gaussian-splatting
    [1]: https://github.com/antimatter15/splat/blob/3695c57e8828fedc2...
    [2]: https://github.com/antimatter15/splat/blob/3695c57e8828fedc2...

    • Im Allgemeinen ist ein Gauß nach der Kameraprojektion nicht mehr wirklich ein Gauß, weil die Projektionsfunktion einer Lochkamera durch z teilt und daher nichtlinear ist.
      Wenn der Gauß im Vergleich zur Bildgröße klein ist, kann man die Projektionsfunktion aber linearisieren und annähern. Deshalb verwendet das Gaussian-Splatting-Paper in Gleichung 5 die Jacobi-Matrix der Projektionsfunktion[0].
      In der Praxis passt diese Näherung sehr gut. Die Matrix, von der im dritten Link die Rede ist, ist genau diese Jacobi-Matrix; das ist keine manuelle Korrektur, sondern mathematisch fundiert. Zur Herleitung siehe [1].
      [0] https://repo-sam.inria.fr/fungraph/3d-gaussian-splatting/3d_...
      [1] https://math.stackexchange.com/a/4716514/43771
    • Das scheint zu stimmen. Man betrachtet die Projektion in kartesischen Koordinaten gewissermaßen als lineare Transformation und transformiert damit den Gauß.
      Anders gesehen nähert man die Projektion unter der Annahme an, dass der gesamte Gauß auf einer festen Tiefe liegt; wenn er weit genug entfernt ist, dürfte das funktionieren.
      Die projektive Transformation eines Gauß wirkt ziemlich mühsam, aber irgendjemand hat das bestimmt schon gemacht. In projektiven Koordinaten scheint es machbar, aber der letzte Schritt der Projektion in kartesische Koordinaten ist knifflig.
      Nebenbei: Nur die Kontur zu projizieren ist ebenfalls falsch. Die gesamte Dichteverteilung ändert sich, und auch das beeinflusst die Kontur.
    • Ich bin mit der gaussian-splat-Technik nicht vertraut, aber ist das im Kern nicht ein Quad-Mesh mit internen Daten an den Vertices?
      Ich dachte, die Projektion von Quads sei bereits ein gelöstes Problem. Kannst du genauer erklären, wie sich das von einem einfachen Array aus Quads unterscheidet?
    • Wenn man die Idee der Schnittberechnung mit dem Tangentialkegel ohne Einfluss auf die Framerate umsetzen könnte, wäre das in WebGPU vermutlich glatter. Interessant wäre allerdings, den Unterschied im Vergleich zu einer solchen Implementierung unter gleichen Bedingungen zu sehen.

  • Beim Herauszoomen sieht man viele polygonale Kanten, die eigentlich nicht da sein sollten.
    Es wirkt, als wolle man weiche „Klumpen“ zeichnen, aber die Texturkoordinaten seien leicht verschoben. Ich frage mich, ob das ein Bug ist oder ein beabsichtigter Teil der Technik.

    • Das ist beabsichtigt.
      Im Grunde ist es eine semidichte Punktwolke[1], nur dass es statt Punkten Klumpen gibt, deren Farbe, Winkel und Größe so angepasst wurden, dass sie zu den Eingabefotos passen. Deshalb ist sie für eine Betrachtung aus einer bestimmten Entfernung optimiert.
      Man kann es sich wie eine 3D-Vektorzeichnung vorstellen. Wenn man zu stark hineinzoomt oder Teile herauslöst, wirkt das Ganze allmählich etwas seltsam.
      [1]https://www.researchgate.net/publication/326621750/figure/fi...

  • Bisher habe ich Gaussian Splatting nur im Einsatz mit Fotodaten gesehen.
    Kann man es auch für andere Grafikdaten verwenden? Anders gesagt: Hat es Potenzial für Spiele?

    • Kommt darauf an. Ein Ansatz mit Strahlungsfeldern wie Gaussian Splatting ist im Grunde 3D-Fotografie.
      Er enthält nur Farbe in Abhängigkeit von geometrischer Position und Richtung, aber keine allgemeinen Konzepte von Oberflächen, Materialien oder Lichttransport, also Emission, Absorption, Transmission, Reflexion oder Streuung. Anders gesagt: Es sind nur vorberechnete Beleuchtung und statische Szenen möglich, Animation ist schwierig.
      Die Branche scheint eher in Richtung Verfahren zu gehen, die bessere dynamische Beleuchtung ermöglichen, etwa Physically Based Rendering (PBR) sowie Ray/Path Tracing.
      Außerdem ist die Speicherplatzeffizienz derzeit extrem schlecht. Eine Szene, die in einer klassischen Rendering-Engine mit einigen Dutzend GB auskäme, kann in den TB-Bereich gehen. Mit weiterer Optimierung könnte sich das allerdings verbessern.
      Ein Bereich, in dem Gaussian Splatting ausnahmsweise interessant sein könnte, sind prozedurale/generative Inhalte, vielleicht sogar inklusive Animation. Besonders gut passen könnte es für volumetrische Effekte, für die man heute Partikelsysteme nutzt, etwa Rauch, Feuer, Wolken oder fließendes Wasser.
    • Es gibt keinen Grund, warum es nicht möglich sein sollte. Am Ende ist es nur eine schicke Punktwolke.
      Ein Open-World-Spiel im Minecraft-Stil, das statt Voxeln dies als Basis-Engine verwendet, kann man sich leicht vorstellen.

  • Funktioniert diese Technik auch mit Video?
    Wenn man sich das README der INRIA-Arbeit[1] ansieht, wirkt es so, als würde pro statischer Szene ein Modell trainiert. Bedeutet das, dass Video ausgeschlossen ist?
    [1] https://github.com/graphdeco-inria/gaussian-splatting

  • Was sehe ich mir hier gerade an?

    • Gaussian Splatting ist ein schöner Name für eine Punktwolke, bei der statt Punkten farbige Formen verwendet werden.
      Das Verfahren gibt es schon lange, wurde aber nicht oft genutzt, weil man bei einer Punktwolke mit einer Million Punkten diese Million Punkte künstlerisch bearbeiten muss.
      Es ist ähnlich wie bei 3D-Haaren. Das Prinzip ist simpel: Man rendert einfach eine Milliarde Haarsträhnen. Es tatsächlich gut aussehen zu lassen, ist aber schwierig.
      Hier lässt man ein Machine-Learning-Modell die Winkel, Farben, Formen und Größen von einer Million Grundformen, etwa Quadraten, Kreisen oder Dreiecken, so anpassen, dass es wie die von uns bereitgestellten Fotos aussieht.
    • Im Grunde ist es diese Arbeit: https://github.com/graphdeco-inria/gaussian-splatting — ein etwas anderer Ansatz zum Rendern von 3D-Szenen.

  • Verwendet das die Methode, die Kerbl und Kopanas auf der SIGGRAPH 2023 vorgeschlagen haben?
    https://repo-sam.inria.fr/fungraph/3d-gaussian-splatting/

    • Ja. Allerdings implementiert dies nicht den Optimierungsteil, der anfangs die Rekonstruktion erzeugt, sondern nur den Splatting-/Rendering-Teil.

  • Wirklich beeindruckend. Punktwolken sind schon interessant, aber das hier ist noch viel erstaunlicher. Selbst auf dem Lenovo-Laptop bei der Arbeit läuft es mit 60 fps.

    • Auf einem Mittelklasse-Smartphone läuft es sogar mit 36 fps. Das hatte ich nicht erwartet.
      Allerdings sieht man vor allem beim Bewegen der Kamera viele Artefakte.

  • Wenn man das in ThreeJS zum Laufen bringt, könnte man damit Geschichte im Web-3D schreiben.

  • Solche Maussteuerungen in einer 3D-Ansicht hatte ich noch nie erlebt, deshalb war ich eine ganze Weile ziemlich verwirrt.