1 Punkte von GN⁺ 2024-04-03 | 1 Kommentare | Auf WhatsApp teilen
  • CityGaussian (CityGS) ist eine auf der ECCV 2024 vorgestellte Methode, die 3D Gaussian Splatting (3DGS) auf stadtgroße Szenen erweitert und dabei sowohl auf Trainingseffizienz als auch auf Qualität bei der Echtzeitnavigation abzielt
  • Die Schwierigkeit, große Szenen auf einmal zu verarbeiten, wird durch eine Kombination aus Divide-and-Conquer-Training und einer Level-of-Detail-(LoD)-Strategie gelöst
  • Mithilfe globaler Szenenprioren und adaptiver Auswahl von Trainingsdaten werden die blockweisen Trainingsergebnisse effizienter aufeinander abgestimmt und nahtloser zusammengeführt
  • Die zusammengeführten Gaussian-Primitiven werden komprimiert, um mehrere Detailstufen zu erzeugen; beim Rendering werden pro Block geeignete Detailstufen ausgewählt und aggregiert
  • Wird MatrixCity ohne LoD mit 25 Millionen Gaussians dargestellt, erreicht es auf einer A100 nur 18 FPS; CityGS mit LoD erzielt im Durchschnitt 36 FPS und ermöglicht damit Echtzeit-Rendering

Trainings- und Rendering-Architektur für großskaliges 3DGS

  • 3D Gaussian Splatting (3DGS) hat seine Stärken bei der Echtzeit-3D-Rekonstruktion und der Synthese neuer Ansichten gezeigt, doch das Training auf großen Szenen und Echtzeit-Rendering über verschiedene Maßstäbe hinweg bleiben weiterhin aufwendig
  • CityGaussian behandelt dieses Problem in zwei Schritten
    • Divide-and-Conquer-Training: Große Szenen werden blockweise aufgeteilt und effizient trainiert
    • LoD-Strategie: Entsprechend dem Betrachtungsmaßstab werden nur die benötigten Detailstufen verwendet, um die Rendering-Geschwindigkeit zu erhöhen
  • Globale Szenenprioren und adaptive Auswahl von Trainingsdaten steigern die Trainingseffizienz und helfen dabei, getrennte Szenenfragmente natürlicher zusammenzuführen
  • Die zusammengeführten Gaussian-Primitiven werden durch einen Kompressionsprozess in mehrere Detailstufen überführt
  • In der Rendering-Phase ermöglichen Strategien zur Auswahl und Aggregation von Detailstufen pro Block eine schnelle Bildgenerierung auch über mehrere Maßstäbe hinweg

Leistung und veröffentlichte Materialien

  • Ohne LoD wird die MatrixCity-Szene mit 25 Millionen Gaussians dargestellt und auf einer A100 mit 18 FPS gemessen
    • Diese Geschwindigkeit wird als unzureichend für ein flüssiges Roaming-Erlebnis bewertet
  • CityGS mit LoD ermöglicht Echtzeit-Rendering auch bei stark unterschiedlichen Maßstäben und wurde auf einer A100 mit durchschnittlich 36 FPS gemessen
  • In Experimenten mit großen Szenen zeigt CityGS Rendering-Qualität auf dem neuesten Stand und unterstützt konsistentes Echtzeit-Rendering für großskalige Szenen über verschiedene Maßstäbe hinweg
  • Verfügbare Materialien

1 Kommentare

 
GN⁺ 2024-04-03
Meinungen auf Hacker News
  • Dass der Datensatz im Video Matrix city heißt, spricht stark dafür, dass er aus der vor einigen Jahren veröffentlichten Unreal-Engine-5-Matrix-Demo extrahiert wurde.
    Die Blickwinkel sind sehr ähnlich, daher wirkt es fotorealistisch, scheint aber nicht aus echten Fotos zu stammen.
    Nach etwas zusätzlicher Recherche stimmte das: https://city-super.github.io/matrixcity/

    • Da Epic früher das Photogrammetrie-Unternehmen Quixel übernommen hat, ist es sehr wahrscheinlich, dass beim Erstellen von Matrix city eine Bibliothek mit fotogescannten Assets verwendet wurde.
      Interessanterweise rekonstruiert der ursprüngliche Beitrag damit gewissermaßen erneut etwas, das bereits aus realen Objekten rekonstruiert wurde.
    • Einige Assets der Demo „The Matrix Awakens“ wurden als separate Packs im Unreal Engine Marketplace veröffentlicht: [1] Karte, [2] Gebäude, Menschenmengen und Fahrzeuge.
      Die MatrixCity-Karte ist zwar anders, ähnelt der Karte von Matrix Awakens aber bis zu einem gewissen Grad. Das lässt sich auch in der Designanalyse auf dieser Seite [3] sehen, die vom Tech Lead des Matrix-Awakens-Projekts geschrieben wurde.
      Wenn man weiter hineingeht und sich den MatrixPlugin-Abschnitt der GitHub-Codebasis [4] ansieht, steht dort ausdrücklich, dass das city-sample project verwendet wurde.
      [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
    • Wenn man Game-Engine-Daten verwendet, erhält man die exakte Kamerapose zu jedem Bild.
      Dadurch wird das Training von NeRF oder Gaussian Splatting etwas einfacher, weil es keinen Optimierungsfehler bei der Kamerapose gibt.
      Aus demselben Grund nutzten die frühen NeRF-Paper den berühmten gelben Lego-Bagger, der mit Blender gerendert wurde.
    • Wenn eine vollständig modellierte Unreal-Engine-Szene vorliegt, frage ich mich, ob man die Splats nicht ohne Trainingsphase erzeugen könnte.
      Bei einer Szene wie Matrix city scheint es nicht nötig zu sein, lange zu trainieren, nur um die Daten zu reproduzieren.
    • Nicht alle Videos sind Matrix City; einige zeigen reale Orte.
  • Am Wochenende habe ich Google Maps 3D Tiles Meshes mit Gaussian Splats zusammengebracht. Es ist nicht exakt dasselbe, aber der Effekt war ziemlich ähnlich und nützlich.
    Beispiel 1 mit verlinktem Code: https://twitter.com/kfarr/status/1773934700878561396
    Beispiel 2: https://twitter.com/3dstreetapp/status/1775203540442697782

    • Wirklich großartig; ich frage mich, ob es dazu ein GitHub mit Code gibt.
      Beim ersten Link erscheint in den Developer Tools ein Fehler:
      Uncaught (in promise) Error: Failed to fetch resource [https://tile.googleapis.com/v1/3dti](<https://tile.googleapis.com/v1/3dti>;)...
    • Ich hatte mit Aframe und OSM-Gebäudeumrissen herumexperimentiert, aber dieser Ansatz sieht deutlich besser aus.
      Ich werde mir aframe-loader-3dtiles-component ansehen.
    • Für Leute, die xitter nicht nutzen: Es wäre schön, wenn hier auch ein Link zum Code-Repository gepostet werden könnte.
  • „Die durchschnittliche Geschwindigkeit beträgt 36 FPS (getestet auf einer A100)“ heißt wohl: Echtzeit, wenn man eine 8.000-Dollar-GPU hat.

    • Das ist die alte SIGGRAPH-Definition von Echtzeit.
      Wenn ein Grafik-Paper behauptet, Echtzeitgeschwindigkeit zu erreichen, muss man immer nachprüfen, ob es wirklich Echtzeit ist oder eher „640x480 bei 20 fps auf der teuersten Hardware, die man für Geld kaufen kann“.
      Wenn man die Messlatte niedrig genug legt, kann alles Echtzeit sein.
    • Es scheint das erste 3DGS zu sein, das LOD und Blöcke verwendet, also könnte noch Optimierungsspielraum bestehen.
      Für Anwendungen wie Virtual Production könnte es nützlich werden, aber für Mobile wohl eher nicht.
    • Das erinnert mich daran, dass frühere GPU-Benchmarks bei ihrem ersten Erscheinen auch mit 10 fps liefen und sich das mit der Zeit änderte.
      https://www.techpowerup.com/forums/attachments/all-cards-png...
    • Leider läuft viel 3DGS/NeRF-Forschung genau so ab.
      Wer etwas will, das auch auf einem zehn Jahre alten Laptop läuft, sogar ohne GPU, sollte sich https://github.com/pierotofy/OpenSplat ansehen. Das ist von mir.
    • Ich denke, die nächste Generation von Consumer-GPUs, die 5090, wird doppelt so schnell wie eine A100 sein und trotzdem keine 8.000 Dollar kosten.
      Daher wirkt das nicht wie ein unüberwindbares Problem.
  • Kann mich jemand davon überzeugen, dass 3D Gaussian Splatting keine Sackgasse ist?
    Das Rendering ist um einen einstelligen Faktor zu langsam, und die Daten sind ebenfalls um einen einstelligen Faktor zu groß. Es fühlt sich an, als würde man den Gegensatz zwischen Rasterisierung und Raytracing noch einmal sehen.
    Rasterisierung wird immer schneller sein als Raytracing, und wenn Raytracing 10-mal schneller wird, wird Rasterisierung ebenfalls 10-mal schneller werden.
    Aus Gaussian-Punktwolken traditionelle Geometrie und Materialien zu erzeugen, könnte interessant sein. Aber Photogrammetrie gibt es schon ziemlich lange.
    Riesige Städte in Echtzeit als Splats zu rendern, fühlt sich nicht wie die „richtige Richtung“ an.
    Cool, unterhaltsam und interessant ist es schon, aber ich bin mir nicht sicher, ob es tatsächlich nützlich werden wird. Ich bin kein Experte, daher frage ich ernsthaft.

    • Das Potenzial ist enorm. Es ist ein ähnlicher, aber anderer Ansatz als die patentierten Technologien, die in der Unreal Engine verwendet werden.
      Der Großteil der aktuellen Forschung konzentriert sich nicht auf Performance, und es gibt noch nicht einmal Einigkeit über ein einheitliches Format inklusive Kompression.
      Das Optimierungspotenzial ist sehr offensichtlich, und die Anpassung an verschiedene Geräte ist ebenfalls einfach. Ähnlich wie bei Punktwolken-LOD oder Mesh-Culling.
      Splat-Performance kann für Viewer ein vorübergehender Wettbewerbsvorteil sein, aber wie sich Videodekompression oder andere 3D-Standards als Open Source verbreitet haben, dürfte hochwertiges Splat-Viewing mit hoher Framerate in ein paar Jahren auf den meisten Geräten zur Grundvoraussetzung werden.
      Die nächste Frage ist dann, wofür man das einsetzt.
    • Es ist nicht um einen einstelligen Faktor zu langsam. Schon jetzt bekommt man in Unreal oder Unity problemlos 200–400fps.
      Über 100fps im Browser: https://current-exhibition.com/laboratorio31/
      900fps: https://m-niemeyer.github.io/radsplat/
      In traditionellen Engines stecken 30 Jahre Forschung und Entwicklung, daher wird es dauern, bis Tools und Optimierungen aufholen.
      Wenn man sich aber ansieht, woher die Papers kommen, sind Apple und Meta stark vertreten, und es wirkt wie eine Technologie, die das von beiden Unternehmen vorangetriebene Zeitalter von Metaverse/Spatial Computing antreiben soll.
      Die Fähigkeit, Inhalte mit sehr niedrigen Produktionskosten wie iPhone-Videos in 3D-Umgebungen zu übertragen, wird einen großen Teil der Forschung und Entwicklung traditioneller Ansätze verdrängen.
    • Photogrammetrie hat Schwierigkeiten mit bestimmten Materialien wie reflektierenden Oberflächen.
      Auch feine Details wie dünne Strukturen oder Haare sind sehr schwer zu erfassen. 3DGS ist in solchen Bereichen stark.
      Es läuft auch Forschung dazu, die aktuellen Schwächen zu verbessern, einschließlich Methoden zur Mesh-Extraktion, die in traditionellen Grafik-Pipelines verwendet werden können.
    • In Bezug auf den Realismus bei der realistischen 3D-Rekonstruktion der realen Welt gibt es derzeit kaum etwas Vergleichbares.
      Photogrammetrie funktioniert nur gut, wenn die Oberflächendaten sauber sind, aber Gaussian Splats sind stark bei halbvolumetrischen Daten wie Fell, Vegetation, Partikeln und rauen Oberflächen.
      Sie eignen sich auch gut für glänzende und reflektierende Oberflächen, Volumen mit stark unterteilungsähnlichen Oberflächeneigenschaften und Materialien mit hoher Blickwinkelabhängigkeit.
    • Entscheidend ist, wofür es eine Sackgasse sein soll.
      Für Anwendungsfälle, die vollständigen 3D-Fotos entsprechen, ist es ziemlich cool und ein völlig legitimer Use Case.
      Für 3D-Game-Engines ist es meiner Meinung nach schwierig, die grundlegenden Primitive dynamisch so zu handhaben, wie Game-Engines es benötigen. Es wird weiter Versuche geben, aber aus dieser Perspektive wirken Gaussians eher wie ein finales Renderformat als wie eine nützliche Zwischendarstellung.
      Damit es in Engines praktisch nutzbar wird, müsste noch etwas erfunden werden, das diese Lücke schließt, und es bleiben noch viele Fragen offen.
      Andere Einsatzgebiete kenne ich nicht, aber die Welt besteht nicht nur aus 3D-Spielen und visuellen Effekten.
  • Es ist immer wieder interessant, wie viele Dinge den Namen Gauß tragen, und dass ständig neue hinzukommen, wie Gaussian splatting – daran sieht man, wie viele Bereiche Gauß beeinflusst hat.
    Er hat es zwar nicht direkt erfunden, aber zu der Mathematik dahinter erheblich beigetragen.

  • Ich bin gespannt, unter welcher Lizenz es veröffentlicht wird.
    Ich würde gern ein Open-Source-Spiel sehen, das das nutzt.

    • Unabhängig von der Performance müsste man für den tatsächlichen Einsatz in Spielen zuerst eine verallgemeinerte Methode finden, Szenen dynamisch zu machen.
      Historisch gab es viele Ansätze, die als Alternative zu Dreiecks-Meshes vielversprechend wirkten, dann aber verschwanden, als klar wurde, dass es keine effiziente Möglichkeit gab, sie zu animieren.
    • Das ist im Grunde eine sehr große Punktwolke aus seltsam geformten Punkten, also wirklich schwierig.
      Objekte in der Punktwolke haben keine inhärenten Metadaten wie „Stuhl, Tisch, Mensch“, daher ist jede Interaktion sehr schwierig.
      Unmöglich ist es nicht, aber derzeit ist es nicht praktikabel.
      Außerdem ist es auch nicht besonders für Echtzeit-Rendering optimiert. Selbst wenn viele Punkte aussortiert wurden, ist es viel effizienter, ein Mesh mit niedriger Auflösung zu verwenden.
  • Das sieht nicht viel besser aus als etwas wie Cities: Skylines.
    Es gibt kein Rein- oder Rauszoomen, und es wird immer nur ein sehr begrenzter Frame gezeigt – übersehe ich da etwas?

    • Die anderen Antworten scheinen ohne echtes Nachdenken oder Recherche gegeben worden zu sein.
      Das Paper verweist wiederholt auf MatrixCity, und auch https://city-super.github.io/matrixcity/, das jemand oben gefunden hat, gibt an, dass es sich um vollständig synthetische Daten handelt.
      Soweit ich es verstehe, wurde es aus der Unreal Engine extrahiert.
    • Das ist kein Game-Rendering, sondern 3D-Rekonstruktion.
    • Ich denke, es wurde aus Fotos gerendert.
    • Das ist keine Game-Engine, sondern eine Umwandlung echter Fotos in einen Gaussian-3D-Blickwinkel.
  • Ich lerne gerade mit pygame und frage mich, wie man Motion Blur in ein Spiel einbaut
    Wenn ich zum Beispiel Mario mit pygame baue, möchte ich, dass Mario beim Springen verschwommen aussieht
    Man könnte zwar eine verschwommene Version von Mario erstellen, indem man den Durchschnitt von 9 Pixeln bildet, aber ich weiß nicht, ob andere Spiele das normalerweise auch so machen
    Viele Spiele sind auch ohne Motion Blur sehr scharf, daher frage ich mich, ob es tatsächlich verwendet wird
    In Filmen ist es ein ziemlich wichtiger Faktor, und mir fällt auch ein, dass man mit 25 fps filmen muss, um filmischen Motion Blur zu erhalten

    • Man rendert die Motion Vectors des Objekts in eine andere Render-Textur
      Das heißt, man berechnet die Geschwindigkeit jedes Objekts und rendert sie als Farbe; anschließend nutzt man sie in einem Post-Processing-Schritt, um Stärke und Richtung des Blur-Effekts festzulegen
      Möglicherweise braucht man die Bewegung relativ zur Kamera. Bei Mario vermutlich eher nicht, aber in einem FPS möchte man wohl, dass die Bildschirmränder verschwimmen, wenn sich die Kamera nach vorn bewegt
  • Zugehöriges Material: https://city-super.github.io/octree-gs/

  • Das ist ein ziemlich fortgeschrittener Ansatz, um größere Szenen mit 3D Gaussians zu rendern; sobald der Code erscheint, möchte ich ihn schnell testen