- RenderFormer ist eine Neural-Rendering-Pipeline, die in szenen auf Basis von Dreiecksmeshes direkt sogar globale Illumination umsetzt
- Es ist kein separates Training oder Fine-Tuning pro Szene erforderlich
- Rendering wird als Sequence-to-Sequence-Transformation definiert, die Dreieckstokens direkt in Pixel-Patch-Tokens umwandelt
- Die gesamte Pipeline ist transformerbasiert aufgebaut und verwendet nur minimale a-priori-Annahmen
- Bilder werden ohne Rasterisierung oder Raytracing erzeugt
Einführung
- RenderFormer ist eine neuronale Pipeline, die Bilder direkt aus einer dreiecksbasierten Szenenrepräsentation rendert
- Sie erzeugt Bilder, auf die globale Illuminationseffekte vollständig angewendet wurden
- Die Architektur funktioniert ohne separates Training oder Fine-Tuning für jede einzelne Szene
Ansatz
- Im Unterschied zu bestehenden Verfahren des physically based rendering wird Rendering als Sequence-to-Sequence-Transformationsproblem neu definiert
- Eine Tokensequenz mit Dreiecken und Reflexionseigenschaften wird in eine Ausgabetokensequenz umgewandelt, bei der jedes Token einem kleinen Pixel-Patch entspricht
Aufbau der Pipeline
- RenderFormer besteht aus einer zweistufigen Struktur
- View-unabhängige Stufe: modelliert den Beleuchtungstransport zwischen Dreiecken
- View-abhängige Stufe: wandelt Tokens, die Bündel von Lichtstrahlen darstellen, in Pixelwerte um. Dabei dient die Dreieckssequenz aus der vorherigen Stufe als Leitfaden
- Beide Stufen basieren auf einer Transformer-Architektur
- Das Training erfolgt mit nur minimalen a-priori-Annahmen
Technische Merkmale
- Beim Rendering werden traditionelle Verfahren wie Rasterisierung und Raytracing überhaupt nicht verwendet
- Die Fähigkeit von Transformern zur Sequenztransformation wird konsequent genutzt
Fazit
- Im Vergleich zu bestehenden Neural-Rendering-Techniken ist dies ein Ansatz, der flexibel und in hoher Qualität Bilder erzeugt, ohne zusätzliche Vorbereitung oder szenenspezifische Anpassungen zu benötigen
1 Kommentare
Hacker-News-Kommentare
Am beeindruckendsten ist der Geschwindigkeitsaspekt. In derselben Szene ist RenderFormer in 0,076 Sekunden fertig, während Blender Cycles 3,97 Sekunden benötigt (oder 12,05 Sekunden bei höheren Einstellungen). Dabei liegt der Structural Similarity Index (SSIM) mit 0,9526 auf einem Niveau, bei dem es fast keinen Unterschied gibt. Es lohnt sich, in der Arbeit Tabelle 2 und 1 anzusehen. Praktisch bedeutet das, dass 3D-Designer in Web- oder nativen Apps mit einem On-Device-Transformer-Modell sofortige Render-Previews in deutlich höherer Qualität sehen könnten. Allerdings wurden diese Ergebnisse auf einer A100-GPU und ohne PyTorch-Optimierung gemessen, und normale Nutzer-GPUs werden nicht so schnell sein, aber dennoch ist wohl ein erheblicher Geschwindigkeitsgewinn gegenüber herkömmlichem Rendering möglich. Bei einem webbasierten System wäre auch denkbar, im Backend eine A100 anzubinden und die Ergebnisbilder in den Browser zu streamen. Die Grenzen sind allerdings ebenfalls klar. Je komplexer die Szene wird, desto stärker sinkt die Genauigkeit, und besonders bei komplexen Schatten (einschließlich Partikeln oder Haaren) treten wahrscheinlich Fehler auf. Deshalb müsste das finale Rendering weiterhin mit traditionellen Methoden erfolgen, um die bei KI-basierten Bildern/Videos oft sichtbaren Artefakte zu vermeiden. Wenn der Geschwindigkeitsgewinn aber groß genug ist, könnte es sich dennoch für große Animationsstudios eignen, die Vorschau-Renderings in Filmlänge für Musik- oder Story-Reviews benötigen
Ich glaube nicht, dass die Forschenden absichtlich Tatsachen verdreht haben, aber mit einer GPU dieser Leistung könnte Blender Cycles alle Szenen aus der Arbeit wohl in unter 4 Sekunden rendern. Die in der Arbeit verwendeten Szenen sind selbst wenig komplex, und Blender wurde auf 4.000 Samples eingestellt, obwohl in der Praxis schon nach ein paar Hundert nahezu Endqualität erreicht wird und der Rest kaum noch etwas bringt. Dadurch werden GPU-Ressourcen unnötig verbraucht. Außerdem scheint die anfängliche Render-Vorbereitung von Blender in die Renderzeit eingerechnet worden zu sein, während die Initialisierungszeit des Transformers ausgeschlossen wurde. Mich würde auch interessieren, wie lange das Rendern des zweiten Frames in jedem System dauert. Ich vermute, Blender wäre dann viel schneller. Die Resultate der Arbeit sind auf jeden Fall interessant, aber bei den Blender-Einstellungen und beim Timing-Vergleich gibt es gewisse Feinheiten
Gemessen an den gezeigten Szenen sind 76 ms eher langsam. Natürlich wird das künftig wohl noch viel schneller werden, aber es erscheint mir verfrüht, das schon jetzt als besser als traditionelles Rendering zu bewerten
Der Zeitvergleich in der Arbeit ist etwas ungenau. Beim Raytracing sinkt der Fehler mit der Quadratwurzel der Sample-Anzahl. In der Arbeit wurde zur Erzeugung der Referenzbilder eine unrealistisch hohe Sample-Zahl verwendet, während echte Offline-Renderer 10- bis 100-mal weniger sampeln. Solche mit extrem hohen Samples erzeugten Bilder dienen wie in der Arbeit dem Qualitätsvergleich, aber für Zeitvergleiche nutzt man sie üblicherweise nicht. Da das Ergebnis nicht streng vergleichbar ist, wäre ein Vergleich mit anderen Rendering-Algorithmen, die ebenfalls Näherungen liefern, fairer. Heutige Echtzeit-Path-Tracer mit Denoiser können auf Consumer-GPUs auch deutlich komplexere Szenen in unter 16 ms rendern. Insbesondere benötigt ein Transformer-Modell sowohl in Bezug auf die Anzahl der Dreiecke als auch der Pixel quadratische Zeit. Vielleicht gibt es in aktueller ML-Forschung Verbesserungen, aber gegen das Skalierungsverhalten klassischer Path Tracer mit O(log n triangles), O(n pixels) dürfte es schwer werden anzukommen (in der Praxis sogar noch weniger empfindlich gegenüber steigender Pixelzahl, dank Kohärenz zwischen benachbarten Pixeln)
Ich finde es überraschend, dass die Behauptung zur Geschwindigkeit so begeistert aufgenommen wird. Ich habe die Arbeit nur grob überflogen und konnte nicht klar erkennen, ob Blender Cycles auf der A100 die CPU oder CUDA-Kernel genutzt hat. Bei einem einzelnen Frame könnte ein Teil der Renderer-Startzeit enthalten sein. Wenn es sich um ein Sequenz-Rendering handelt, sinkt die Zeit pro Frame deutlich. Und wie andere bereits erwähnt haben, wird auch die Dreieckskomplexität (O(n^2)-Skalierung) definitiv eine Rolle spielen
In der Arbeit heißt es: „Die Laufzeitkomplexität der Attention-Layer wächst quadratisch mit der Anzahl der Tokens, hier also der Dreiecke. Deshalb begrenzen wir die Anzahl der Dreiecke in einer Szene auf maximal 4096.“
Deep Learning wird auch sehr erfolgreich zum Denoising von global-illumination-gerenderten Bildern eingesetzt. Dabei erzeugt man mit traditionellem Raytracing ein grobes Global-Illumination-Bild, und ein neuronales Netz entfernt anschließend das Rauschen aus dem Ausgabebild. Relevanter Link: Open Image Denoise
Ich habe einen Freund, der in der Filmbranche tatsächlich physikbasierte Renderer entwickelt, und ich finde es immer spannend, von den Arbeitsweisen und Geschichten in diesem Bereich zu hören. Ich frage mich, welche Firmen aktuell solche Leute einstellen. Ob wohl auch KI-Unternehmen Rendering-Ingenieure suchen, um Trainingsumgebungen aufzubauen? Falls jemand erfahrene Leute aus Rendering-Forschung oder Industrie sucht: Mein Freund ist nicht in sozialen Netzwerken, ich könnte aber den Kontakt herstellen
Ich finde es auffällig, dass keines der Beispiele Objekte hinter der Kamera zeigt. Ich weiß nicht, ob das eine Einschränkung der Beispielgestaltung oder des Ansatzes selbst ist, aber für Reflexionen und Beleuchtung ist der Bereich hinter der Kamera extrem wichtig
Wieder so ein Moment, in dem „the bitter lesson“ greifbar wird. Jetzt gilt dieser Trend auch im Bereich Grafik-Rendering. NeRF nutzte teilweise raytracing-basierte Priors, Gaussian Splatting teilweise rasterisierungsbasierte Priors, aber dieser Ansatz wirft solche Domain-Priors und spezialisiertes Wissen offenbar über Bord und versucht, alles nur mit Daten und Attention zu lösen. Das fühlt sich letztlich wie die Zukunft an
Beeindruckend ist, dass sich rund um die GPU ein Kreislauf zwischen Rendering und Compute geschlossen hat
Das Ergebnis ist ordentlich, wirkt aber etwas blurry. Ich hätte gern noch mehr Vergleiche der Renderzeiten zwischen neuronalen Netzen und klassischen Renderern gesehen
In den Animationen (insbesondere Animated Crab und Robot Animation) sind typische KI-Art-Artefakte sichtbar: Wenn sich Objekte oder die Kamera bewegen, entsteht rund um das Modell ein unnatürlich wirbelnder Effekt
In der Arbeit gibt es etwas Diskussion zum Zeitvergleich. Verglichen mit Blender Cycles (Path Tracing) ist der neuronale Ansatz zumindest bei Szenen mit höchstens 4K Dreiecken deutlich schneller. Für komplexere Szenen ist er aber möglicherweise ungeeignet, da die Laufzeit der Attention quadratisch mit der Dreiecksanzahl steigt. Link zur Arbeit: RenderFormer Paper PDF. Ich könnte mir vorstellen, den neuronalen Ansatz nur für indirekte Beleuchtung zu verwenden, also mit einem traditionellen Rasterizer das Basisbild zu erzeugen und nur die Global Illumination neuronisch hinzuzufügen
Vielleicht übersehe ich etwas, aber wenn diese Szenen am Ende sowieso auf die erwartete Weise gerendert werden, worin genau liegt dann der Vorteil dieses Ansatzes gegenüber einfacheren, direkteren Methoden? Wenn er nicht einmal schneller ist, warum sollte man ihn dann überhaupt verwenden?
Tatsächlich könnte dieser Ansatz interessantere Effekte ermöglichen, als es auf den ersten Blick scheint. Man könnte zum Beispiel eine Szene als ein einziges Bündel von Input-Weights betrachten und darauf Rauschen hinzufügen oder verschiedene Szenen interpolieren, um unerwartete Ergebnisse zu erhalten
Ich denke letztlich, das ist eher „Cool Research“. Praktisch ist es wenig, weil die Kosten mit steigender Dreiecksanzahl quadratisch wachsen. Deshalb begrenzt die Arbeit die Szenen auch auf 4096 Stück
Wie in einem anderen Kommentar erwähnt wurde, ist der Ansatz tatsächlich schneller. Global Illumination ist mit direkten Methoden wirklich langsam
Es wirkt wie eine originelle Forschungsarbeit. Dass Transformer nicht nur für natürliche Sprache, sondern allgemein für viele kontinuierliche Dateneingaben und Domänen mit Korrelationen zwischen Tokens geeignet sein könnten, macht Hoffnung auf mehr Forschung in nichttextuellen Bereichen. Mich würde interessieren, welche nichttextuellen Domänen Hacker-News-Nutzer noch spannend finden, die gut zu Transformern passen könnten
Ich halte das für eine sehr clevere und interessante Idee. Man trainiert einen Transformer darauf, eine szenenbeschreibende Menge von Dreiecken in ein 2D-Pixel-Array umzuwandeln, und das Ergebnis ist ein Bild, das dem Output eines herkömmlichen Global-Illumination-Renderers fast entspricht und sofort erzeugt wird. Nach den Forschungen der letzten fünf Jahre sollte die Tatsache, dass so etwas möglich ist, eigentlich nicht mehr überraschen, und trotzdem ist es immer noch äußerst beeindruckend. Man merkt, wie vielseitig die Transformer-Architektur wirklich ist. Es ist außerdem extrem schnell, sieht dem Blender-Output sehr ähnlich, das Modell hat etwa 1B Parameter, und ich bin nicht sicher, ob es fp16 oder fp32 ist, aber die Datei ist mit 2 GB ziemlich groß. Ich würde gern auch Demos mit realistischeren Szenen sehen, aber mir gefällt auch, dass ich es direkt auf meinen Mac herunterladen und selbst ausprobieren kann