CityGaussian: Echtzeit-Rendering großer Szenen in hoher Qualität mit Gaussians
(dekuliutesla.github.io)- 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
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/
Interessanterweise rekonstruiert der ursprüngliche Beitrag damit gewissermaßen erneut etwas, das bereits aus realen Objekten rekonstruiert wurde.
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
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.
Bei einer Szene wie Matrix city scheint es nicht nötig zu sein, lange zu trainieren, nur um die Daten zu reproduzieren.
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
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 werde mir aframe-loader-3dtiles-component ansehen.
„Die durchschnittliche Geschwindigkeit beträgt 36 FPS (getestet auf einer A100)“ heißt wohl: Echtzeit, wenn man eine 8.000-Dollar-GPU hat.
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.
Für Anwendungen wie Virtual Production könnte es nützlich werden, aber für Mobile wohl eher nicht.
https://www.techpowerup.com/forums/attachments/all-cards-png...
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.
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.
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.
Ü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.
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.
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.
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.
https://en.wikipedia.org/wiki/Monte_Carlo_(disambiguation)
Allein unter „Science and Technology“ gibt es 8 Einträge.
Ich bin gespannt, unter welcher Lizenz es veröffentlicht wird.
Ich würde gern ein Open-Source-Spiel sehen, das das nutzt.
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.
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?
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.
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
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