RenderFormer: Neuronales Rendering auf Basis von Dreiecks-Meshes und Global Illumination
(microsoft.github.io)- RenderFormer ist eine Neural-Rendering-Pipeline, die Bilder direkt aus Szenen mit Dreiecks-Meshes erzeugt. Der Kernpunkt ist, dass sie ohne szenenspezifisches Training auch Global Illumination abdeckt
- Rendering wird nicht als physikalischer Simulationsprozess definiert, sondern als Sequence-to-Sequence-Transformation, die Dreiecks- und Reflexionseigenschafts-Token in kleine Pixel-Patch-Token umwandelt
- Die Pipeline ist in eine view-unabhängige und eine view-abhängige Stufe unterteilt; beide nutzen eine Transformer-Architektur und werden mit minimalen Vorabannahmen trainiert
- Die view-unabhängige Stufe modelliert die Lichtübertragung zwischen Dreiecken, die view-abhängige Stufe wandelt Bündel von Strahl-Token in Pixelwerte um
- Öffentliche Beispiele umfassen Beleuchtung, Materialien, geometrische Komplexität, Animationen und physikalische Simulationen und rendern ohne Rasterisierung und Ray Tracing
Rendering-Struktur von RenderFormer
- RenderFormer ist eine Neural-Rendering-Pipeline, die Bilder direkt aus einer dreiecksbasierten Szenenrepräsentation rendert
- Sie umfasst vollständige Global-Illumination-Effekte, ohne szenenspezifisches Training oder Fine-Tuning zu erfordern
- Der Rendering-Prozess ist als Sequence-to-Sequence-Transformation aufgebaut
- Die Eingabe ist eine Sequenz von Dreiecks-Token inklusive Reflexionseigenschaften
- Die Ausgabe ist eine Sequenz von Token, die kleine Pixel-Patches repräsentieren
- Eine zweistufige Pipeline trennt die view-unabhängige Berechnung der Lichtübertragung von der eigentlichen Pixelerzeugung
- View-unabhängige Stufe: modelliert die Lichtübertragung zwischen Dreiecken
- View-abhängige Stufe: wandelt Bündel von Strahl-Token in Pixelwerte um; die Dreieckssequenz aus der view-unabhängigen Stufe leitet diesen Prozess
- Beide Stufen basieren auf einer Transformer-Architektur und werden mit minimalen Vorabannahmen trainiert
- Im Rendering-Prozess werden weder Rasterisierung noch Ray Tracing verwendet
Öffentliche Ergebnisse und Referenzmaterial
- Die Rendering-Galerie zeigt verschiedene Beleuchtungsbedingungen, Materialien und geometrische Komplexitäten ohne szenenspezifisches Training oder Fine-Tuning
- Cornell Box, Stanford Bunny in Cornell Box, Lucy Statue, Utah Teapot
- Composed Scene, Constant Width Bodies, Crystals, Fox in the Wild
- Horse and Heart, RenderFormer Logo, Interior Room, Shader Ball, Tree, Veach MIS
- Für detaillierte Vergleiche werden reference images bereitgestellt
- Als weiteres Videomaterial werden uncompressed videos und reference videos bereitgestellt
-
Teaser-Szenen
- Objektrotation, Beleuchtungsänderungen und Materialanpassungen lassen sich nachvollziehen
- Cornell Box Roughness Adjustment
- Bunny Roughness Adjustment
- Tree Light Change
- Tree Object Rotation
- Fancy Scene Rotation
- Composed Scene View Change
-
Animationen und Simulationen
- Beispiele für Animations-Rendering umfassen Cascade Cube Animation, Animated Crab, Gyroscope Motion, Animated Character, Marching Cubes Animation und Robot Animation
- Beispiele für physikbasierte Simulationen umfassen Bowling Ball Physics Simulation, Rotating Box Dynamics und Constant Width Body Simulation
- Das Paper erscheint in den ACM SIGGRAPH 2025 Conference Papers; der Titel des BibTeX-Eintrags lautet „RenderFormer: Transformer-based Neural Rendering of Triangle Meshes with Global Illumination“
1 Kommentare
Hacker-News-Meinungen
Das Coolste daran könnte die Geschwindigkeit sein: In derselben Szene braucht RenderFormer 0,0760 Sekunden, Blender Cycles 3,97 Sekunden (bei höheren Einstellungen 12,05 Sekunden) und hält dabei einen Structural Similarity Index von 0,9526 (0–1, 1 bedeutet identisches Bild). Siehe Tabelle 2 und 1 im Paper.
Damit könnte man 3D-Designern im Web oder in nativen Apps mit einem On-Device-Transformer-Modell sofortige Render-Vorschauen in besserer Qualität anbieten.
Die obige Messung wurde auf einer A100 mit einer nicht optimierten PyTorch-Version des Modells durchgeführt. Die GPUs normaler Nutzer sind deutlich schwächer, aber GPUs für 3D-Designer könnten dennoch ausreichen, um gegenüber traditionellem Rendering einen recht großen Geschwindigkeitsgewinn zu sehen. Bei einem webbasierten System könnte man auch eine A100 im Backend anbinden und die Bilder in den Browser streamen.
Eine Einschränkung ist, dass es bei steigender Szenenkomplexität nicht vollständig exakt ist, etwa bei komplex geformten Schatten (vermutlich auch bei Partikeln oder Haaren). Daher wird das finale Rendering wohl weiterhin mit traditionellen Verfahren erfolgen, um die unschönen visuellen Artefakte zu vermeiden, die man heute in vielen KI-generierten Bildern/Videos sieht. Wenn es aber gut genug ist und der Geschwindigkeitsgewinn groß ausfällt, hätten große Animationsstudios einen Grund, es einzusetzen, etwa um Vorschauen in Spielfilmlänge für Musik-, Story-Reviews usw. zu rendern.
Die Szenen sind sehr schlichte Technik-Demos mit geringer Komplexität, und offenbar wurde Blender auf 4.000 Iterationen pro Pixel eingestellt, was wenig Sinn ergibt. Blender kommt nach ein paar hundert Cycles schon ziemlich nah an das Ergebnis heran; die weiteren 3.800 Cycles verbrennen wahrscheinlich nur GPU-Zyklen ohne nennenswerte Verbesserung.
Es sieht so aus, als hätten sie versehentlich die Initialisierungsphase von Blender in die gesamte Renderzeit eingerechnet, die Transformer-Initialisierung aber nicht. Ich würde gern die Zeit für das Rendern des zweiten Frames in beiden Systemen sehen; meine Vermutung ist, dass Blender dann deutlich besser abschneidet. Die Ergebnisse des Papers selbst sind interessant, aber bei den Blender-Einstellungen und der Messmethode gibt es Nuancen.
Beim Raytracing sinkt der Fehler proportional zur Quadratwurzel der Sample-Anzahl. Für Referenzbilder zum Qualitätsvergleich verwendet man üblicherweise sehr hohe Sample-Zahlen, aber die tatsächlichen Sample-Zahlen von Offline-Renderern liegen ein bis zwei Größenordnungen unter denen in diesem Paper.
In Grafik-Papern ist es üblich, für Qualitätsvergleiche Referenzbilder mit sehr hoher Sample-Zahl zu verwenden; unüblich ist es, auch die Renderzeit mit genau diesem Referenzbild zu vergleichen. Wenn das Ergebnis eine Näherung ist, wäre ein Vergleich mit anderen approximativen Rendering-Algorithmen fair. Moderne Echtzeit-Pathtracer und Denoiser können selbst auf Consumer-GPUs deutlich komplexere Szenen in unter 16 ms rendern.
Der entscheidende Punkt ist „deutlich komplexere Szenen“. Mit einem Transformer skaliert es quadratisch sowohl mit der Zahl der Dreiecke als auch mit der Zahl der Ausgabepixel. Ich verfolge aktuelle Machine-Learning-Forschung nicht genau, vielleicht hat sich das inzwischen verbessert, aber ich glaube nicht, dass es die theoretische Skalierung typischer Pathtracer von O(log n_triangles) und O(n_pixels) schlagen kann. Die tatsächliche Skalierung mit der Pixelzahl ist wegen der hohen Kohärenz benachbarter Pixel eher sublinear.
Ich habe es nur kurz überflogen, aber keine Details dazu gefunden, wie es konfiguriert wurde. Mich würde interessieren, ob Cycles auf der A100 die CPU oder CUDA-Kernels genutzt hat. Außerdem könnte bei einem einzelnen Frame ein nicht vernachlässigbarer Anteil der 3,97 Sekunden auf den Start des Renderers entfallen sein. Beim Rendern einer Sequenz würde die Zeit pro Frame sinken.
Die in einem Geschwisterkommentar erwähnte Komplexitätsskalierung pro Dreieck ist ebenfalls schmerzhaft.
Deep Learning wird auch sehr erfolgreich für das Denoising von Renderbildern mit globaler Beleuchtung eingesetzt [1].
Bei diesem Ansatz berechnet ein traditioneller Raytracing-Algorithmus schnell eine grobe globale Beleuchtung der Szene, und ein neuronales Netz entfernt das Rauschen aus der Ausgabe.
[1] https://www.openimagedenoise.org
Edit: Das Denoising sieht bei 100 % Vergrößerung besser aus als bei 125 % DPI-Skalierung, und der Farn unten ist leichter zu erkennen.
Bei Grafik-Papern muss man immer darüber nachdenken, was nicht zu sehen ist.
Hier gibt es kaum Polygone, eine niedrige Auflösung, keine Texturen, kein Motion Blur, keine Tiefenschärfe, und in der Animation gibt es einige Artefakte.
Es ist interessante Forschung, aber mit etwas Perspektive betrachtet erzeugt man hier mit modernen GPUs Bilder, die aussehen wie etwas, das man vor 30 Jahren mit einem Millionstel der Rechenleistung gemacht hätte.
Ich fand es seltsam, dass keines der Beispiele zeigt, was hinter der Kamera liegt.
Ich weiß nicht, ob das eine Einschränkung des Ansatzes oder ein Versäumnis bei der Erstellung der Beispiele ist, aber wenn man über Reflexionen und Beleuchtung spricht, ist der Bereich hinter der Kamera ziemlich wichtig.
Ich frage aus Unwissen: Werden diese Szenen auf Grundlage dessen gerendert, wie man erwartet, dass die Szene gerendert wird? Falls ja, verstehe ich nicht, warum man das statt einer direkteren Methode verwenden sollte. Es wirkt nicht so, als wäre es schneller als eine direkte Methode.
Wenn zum Beispiel eine Szene ein Block von Eingabegewichten ist: Wie sähe es aus, wenn man Rauschen darauf addiert? Könnte man damit interessante Ausgaben erhalten, die mit üblichen Methoden unmöglich wären?
Wäre es interessant, zwischen zwei unterschiedlichen Szenenrepräsentationen zu interpolieren? Solche Fragen werden möglich.
Wow, damit schließt sich der Kreis bei der GPU: vom Rendering zur Berechnung und wieder zurück zum Rendering.
Sieht okay aus, aber unscharf. Ich hätte gern einen Vergleich der Renderzeiten zwischen dem neuronalen Renderer und einem klassischen Renderer gesehen.
Bei Animationen, insbesondere Animated Crab und Robot Animation, fallen ziemlich deutlich AI-Art-Artefakte auf, die unnatürlich um das Modell herumwirbeln, wenn sich Objekt und Kamera bewegen.
https://renderformer.github.io/pdfs/renderformer-paper.pdf
Ich frage mich, ob es praktisch wäre, den neuronalen Ansatz mit vereinfachter Geometrie nur für indirekte Beleuchtung zu nutzen – also einen normalen Rasterizer zu verwenden und darauf globale Beleuchtung aufzusetzen.
Ich habe einen Freund, der in der Filmbranche mit physikalisch basierten Renderern gearbeitet und dazu auch geforscht hat. Ich höre mir immer gern seine Geschichten und Erklärungen dazu an, wie in dieser Branche gearbeitet wird.
Ich frage mich, welche Firmen heutzutage solche Leute einstellen. Stellen auch AI-Unternehmen Rendering Engineers ein, um Trainingsumgebungen zu bauen?
Falls jemand erfahrene Research-/Industry-Rendering-Engineers sucht, kann ich gern den Kontakt herstellen. Mein Freund ist nicht in sozialen Medien aktiv, schaut sich aber nach Möglichkeiten um.
Sehr schöne Forschung. Ich mag solche Beispiele wirklich, bei denen Transformer auf Bereiche außerhalb von Text angewendet werden.
Wenn die Eingabe sequenziell ist und die Eingabe-Token miteinander in Beziehung stehen, scheint das gut zu funktionieren. Ich freue mich auf mehr Forschung in diesem Bereich.
Welche interessanten Nicht-Text-Bereiche gibt es, für die Transformer besonders gut passen könnten?
Die Idee, einen Transformer zu trainieren, der eine Szenenbeschreibung in Form einer Menge von Dreiecken in ein 2D-Pixelarray umwandelt, sodass das Ergebnis wie die Pixel aussieht, die ein Global-Illumination-Renderer für dieselbe Szene ausgeben würde, ist großartig und spannend.
Angesichts der Forschung der letzten fünf Jahre ist es nicht schockierend, dass das funktioniert, aber es fühlt sich trotzdem nach einem ziemlich tiefgehenden Ergebnis an. Die Transformer-Architektur ist wirklich extrem vielseitig.
Jedenfalls ist es enorm schnell, kommt dem Output von Blender-Renderings nahe und sieht ungefähr nach einem Modell mit 1 Milliarde Parametern aus. Ich weiß nicht, ob es fp16 oder fp32 ist, aber bei einer 2-GB-Datei gibt es daran nicht viel auszusetzen. Ich würde gern auch Demos mit „realistischeren“ Szenen sehen, aber wenn man möchte, kann man es herunterladen und selbst auf dem Mac laufen lassen.