- RenderFormer es un pipeline de neural rendering que implementa directamente incluso efectos de iluminación global en escenas basadas en mallas triangulares
- No requiere entrenamiento adicional ni ajuste fino por escena
- Define el renderizado como una transformación secuencia a secuencia, convirtiendo directamente tokens de triángulos en tokens de parches de píxeles
- Todo el pipeline está diseñado con base en transformers, aplicando solo restricciones previas mínimas
- Genera imágenes sin usar rasterización ni ray tracing
Introducción
- RenderFormer es un pipeline neuronal que renderiza imágenes directamente a partir de una representación de escena basada en triángulos
- Produce imágenes con los efectos de iluminación global completamente aplicados
- Funciona con una estructura que no requiere entrenamiento ni fine-tuning por escena
Enfoque
- A diferencia de los métodos existentes de renderizado físicamente basado, redefine el renderizado como un problema de transformación secuencia a secuencia
- Convierte una secuencia de tokens que contiene triángulos y propiedades de reflexión en una secuencia de tokens de salida, donde cada uno se transforma en un pequeño parche de píxeles
Estructura del pipeline
- RenderFormer está compuesto por una estructura de 2 etapas
- Etapa independiente de la vista: modela el fenómeno de transferencia de iluminación entre triángulos
- Etapa dependiente de la vista: convierte tokens que representan haces de rayos en valores de píxeles. En este proceso, la secuencia de triángulos de la etapa anterior actúa como guía
- Ambas etapas se basan en una arquitectura transformer
- Se entrena aplicando solo restricciones previas mínimas
Características técnicas
- Durante el renderizado no utiliza en absoluto métodos tradicionales como rasterización o ray tracing
- Aprovecha activamente la capacidad de transformación de secuencias de los transformers
Conclusión
- Frente a las técnicas existentes de neural rendering, es un enfoque que genera imágenes flexibles y de alta calidad sin necesidad de preparación previa adicional ni ajustes por escena
1 comentarios
Opiniones de Hacker News
Lo más impresionante es la velocidad. En la misma escena, RenderFormer termina en 0.076 segundos, mientras que Blender Cycles tarda 3.97 segundos (o 12.05 segundos con configuraciones más altas). Aun así, el índice de similitud estructural (SSIM) es de 0.9526, o sea, casi no hay diferencia. Recomiendo ver las tablas 2 y 1 del paper. Lo que esto significa en la práctica es que los diseñadores 3D podrían ver vistas previas de render instantáneas y de mucha mayor calidad en la web o en apps nativas con modelos transformer on-device. Claro, esos resultados se midieron en una GPU A100 y sin optimización de PyTorch, así que una GPU de usuario común no será tan rápida, pero aun así esperaría una mejora de velocidad suficiente frente al render tradicional. O, si es un sistema web, también se podría conectar al backend con una A100 y hacer streaming de la imagen resultante al navegador. Aun así, las limitaciones son claras. A medida que la escena se vuelve más compleja, baja la precisión, y en especial con sombras complejas (incluyendo partículas o cabello) es muy probable que aparezcan errores, así que el render final todavía tendría que hacerse con métodos tradicionales para evitar los artefactos que se ven seguido en imágenes o video generados por IA. Aun así, si la mejora de velocidad es lo bastante grande, imagino que podría usarse en grandes estudios de animación que necesitan renders preliminares de duración cinematográfica para revisar música o historia, por ejemplo
No creo que los investigadores hayan distorsionado deliberadamente los hechos, pero con una GPU de ese nivel Blender Cycles debería poder renderizar todas las escenas del paper en menos de 4 segundos. Las escenas usadas en el paper ya son de baja complejidad, y además configuraron Blender para hacer 4,000 muestras repetidas, cuando en la práctica con unos pocos cientos ya se llega a una calidad casi final y el resto casi no aporta nada. El resultado es que se consumen recursos de GPU innecesariamente. Además, parece que incluyeron en el tiempo de render la preparación inicial de Blender, mientras que excluyeron el tiempo de inicialización del transformer. También me da curiosidad cuánto tarda el segundo frame en cada sistema. Mi intuición es que Blender sería mucho más rápido. En cualquier caso, los resultados del paper son interesantes, pero hay matices en la comparación de configuración y tiempos con Blender
Para las escenas que muestran, 76 ms más bien se siente lento. Claro, probablemente se volverá mucho más rápido en el futuro, pero me parece prematuro decir que ya es mejor que los renders tradicionales
La comparación de tiempos del paper es algo inexacta. En ray tracing, el error disminuye según la raíz cuadrada del número de muestras. En el paper usaron un número de muestras irrealmente alto para generar la imagen de referencia, mientras que los renderizadores offline reales usan entre 10 y 100 veces menos muestras. Las imágenes hechas con tantos samples como en el paper sirven para comparar calidad, pero no es común usarlas para comparar tiempos. Como el resultado no es estricto, sería más justo compararlo con otros algoritmos de render que produzcan aproximaciones similares. Hoy en día, la combinación de path tracers en tiempo real con denoisers también puede renderizar escenas mucho más complejas en menos de 16 ms con GPUs de consumo. Además, el modelo transformer requiere tiempo proporcional al cuadrado tanto del número de triángulos como del número de píxeles. Puede que investigaciones recientes de machine learning hayan mejorado esto, pero será difícil superar el escalado O(log n triangles), O(n pixels) de un path tracer tradicional (en la práctica incluso es menos sensible al aumento de píxeles gracias a la coherencia entre píxeles vecinos)
Me sorprende que se presente como una mejora tan grande en velocidad. Revisé el paper por encima y no me quedó claro si Blender Cycles usó la CPU de la A100 o si usó kernels de CUDA. Si fue un solo frame, parte del tiempo podría incluir el arranque del renderizador. Si fue un render de secuencia, el tiempo por frame bajaría bastante. Y el punto que mencionó otra persona sobre la complejidad en triángulos (escalado O(n^2)) claramente también influiría
En el paper dicen que "la complejidad temporal de ejecución de las capas de attention crece cuadráticamente con el número de tokens, es decir, en este caso, con el número de triángulos. Por eso limitamos el número de triángulos en la escena a un máximo de 4096"
El deep learning también se está usando con mucho éxito para denoise de imágenes renderizadas con global illumination. La idea es generar una imagen aproximada de global illumination con ray tracing tradicional, y luego una red neuronal elimina el ruido de la imagen de salida. Link relacionado: Open Image Denoise
Tengo un amigo que de verdad desarrolla renderizadores físicamente basados para la industria del cine, y siempre me resulta fascinante escuchar cómo trabaja ese sector y sus historias. Me da curiosidad saber qué empresas están contratando gente así en este momento. También me pregunto si las empresas de IA están contratando ingenieros de rendering para construir entornos de entrenamiento. Si alguien quiere contratar ingenieros con experiencia en investigación o industria de rendering, puedo ponerlos en contacto, porque mi amigo no usa redes sociales
Me parece curioso que ninguno de los ejemplos muestre objetos detrás de la cámara. No sé si es una limitación de cómo armaron los ejemplos o del enfoque en sí, pero al considerar reflejos o iluminación, lo que está detrás de la cámara es un factor muy importante
Otro momento en que se siente muy real "the bitter lesson". Ahora esa tendencia también se está aplicando al campo del rendering gráfico. NeRF usaba parcialmente priors basados en ray tracing, Gaussian splat usaba priors basados en rasterización, pero este enfoque intenta resolverlo dejando de lado ese conocimiento de dominio o especializado y apoyándose solo en los datos y en la attention. Da la impresión de que ese es el futuro al final
Me impresiona que ya se haya completado esta estructura circular donde rendering y cómputo quedan conectados entre sí alrededor de la GPU
El resultado está bien, pero se siente algo borroso. Me gustaría ver más comparaciones de tiempo de render entre redes neuronales y renderizadores clásicos
En las animaciones (especialmente Animated Crab y Robot Animation) se notan artefactos típicos del arte con IA: ese efecto de remolino poco natural alrededor del modelo cuando se mueve el objeto o la cámara
En el paper sí hay algo de discusión sobre la comparación de tiempos. Frente a Blender Cycles (path tracing), el enfoque neuronal es mucho más rápido al menos en escenas de hasta 4K triángulos. Pero puede no encajar bien en escenas más complejas que eso (porque el runtime de attention aumenta con el cuadrado del número de triángulos). Link al paper: PDF del paper de RenderFormer. En mi opinión, una forma realista podría ser usar el enfoque neuronal solo para la iluminación indirecta, generar la imagen base con un rasterizador tradicional y luego superponer la Global Illumination de forma neuronal
Tal vez no entiendo bien, pero si al final estas escenas se renderizan de la manera esperada, me pregunto por qué este enfoque tendría ventajas frente a métodos directos más simples (si ni siquiera es más rápido, da la impresión de que no habría mucha razón para usarlo)
En realidad, este enfoque podría producir efectos más interesantes de lo que parece. Por ejemplo, podrías tratar una escena como un solo bloque de weights de entrada, agregarle ruido, o interpolar (mezclar) distintas escenas para obtener resultados inesperados
Al final creo que esto está más cerca de "Cool Research". Tiene poca utilidad práctica, porque el costo crece cuadráticamente a medida que aumenta el número de triángulos. Por eso en el paper limitan cada escena a 4096
Como ya se mencionó en otro comentario, sí es más rápido. La global illumination es realmente lenta con métodos directos
Me parece una investigación novedosa. Los transformers no solo sirven para lenguaje natural, sino que pueden aplicarse a muchos dominios caracterizados por entradas de datos continuas y correlaciones entre tokens. Me interesa ver más investigación futura sobre aplicaciones en dominios no textuales. Me da curiosidad qué otros dominios no textuales les parecen más interesantes a los usuarios de Hacker News y que podrían encajar bien con transformers
Me parece una idea muy ingeniosa e interesante. Entrenar un transformer que convierta una descripción de escena basada en conjuntos de triángulos en un arreglo de píxeles 2D, y que como resultado genere al instante una imagen casi igual a la salida de un renderizador tradicional de global illumination. Viendo la investigación de los últimos 5 años, el hecho de que esto sea posible ya no debería sorprender, pero aun así sigue siendo muy impresionante. Se siente lo versátil que es la arquitectura transformer. La velocidad también es increíblemente alta, la salida es casi igual a la de Blender, el modelo tiene alrededor de 1B parámetros, y no estoy seguro si usa fp16 o 32, pero el archivo pesa 2 GB, que es bastante. Me gustaría ver demos con escenas más realistas, pero también me gusta que ahora mismo podría descargarlo y correrlo yo mismo en mi Mac