RenderFormer: renderizado neuronal basado en mallas triangulares e iluminación global
(microsoft.github.io)- RenderFormer es un pipeline de renderizado neuronal que genera imágenes directamente a partir de escenas de mallas triangulares, y su punto clave es que maneja incluso iluminación global sin entrenamiento por escena
- Define el renderizado no como un procedimiento de simulación física, sino como una transformación sequence-to-sequence que convierte tokens de triángulos y propiedades de reflexión en pequeños tokens de parches de píxeles
- El pipeline se divide en una etapa independiente de la vista y una etapa dependiente de la vista, y ambas se entrenan con una arquitectura Transformer con restricciones previas mínimas
- La etapa independiente de la vista modela la transferencia de luz entre triángulos, y la etapa dependiente de la vista convierte tokens de grupos de rayos en valores de píxeles
- Los ejemplos públicos incluyen iluminación, materiales, complejidad geométrica, animación y simulación física, y renderizan sin rasterización ni ray tracing
Estructura de renderizado de RenderFormer
- RenderFormer es un pipeline de renderizado neuronal que renderiza imágenes directamente a partir de una representación de escena basada en triángulos
- Incluye efectos completos de iluminación global sin requerir entrenamiento ni ajuste fino por escena
- El proceso de renderizado se compone como una transformación sequence-to-sequence
- La entrada es una secuencia de tokens de triángulos que incluye propiedades de reflexión
- La salida es una secuencia de tokens que representa pequeños parches de píxeles
- Un pipeline de 2 etapas separa el cálculo de transferencia de luz independiente de la vista y la generación real de píxeles
- Etapa independiente de la vista: modela la transferencia de luz entre triángulos
- Etapa dependiente de la vista: convierte tokens de grupos de rayos en valores de píxeles, guiada por la secuencia de triángulos de la etapa independiente de la vista
- Ambas etapas se basan en una arquitectura Transformer y se entrenan con restricciones previas mínimas
- No utiliza rasterización ni ray tracing en el proceso de renderizado
Resultados públicos y materiales de referencia
- La galería de renderizado muestra diversas condiciones de iluminación, materiales y complejidad geométrica sin entrenamiento ni ajuste fino por escena
- 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
- Se ofrecen reference images para comparaciones detalladas
- También se ofrecen materiales en video adicionales: uncompressed videos y reference videos
-
Escenas teaser
- Permiten ver rotación de objetos, cambios de iluminación y ajustes de materiales
- Cornell Box Roughness Adjustment
- Bunny Roughness Adjustment
- Tree Light Change
- Tree Object Rotation
- Fancy Scene Rotation
- Composed Scene View Change
-
Animación y simulación
- Los ejemplos de renderizado de animación incluyen Cascade Cube Animation, Animated Crab, Gyroscope Motion, Animated Character, Marching Cubes Animation y Robot Animation
- Los ejemplos de simulación basada en física incluyen Bowling Ball Physics Simulation, Rotating Box Dynamics y Constant Width Body Simulation
- El paper se publicará en ACM SIGGRAPH 2025 Conference Papers, y el título de la entrada BibTeX es “RenderFormer: Transformer-based Neural Rendering of Triangle Meshes with Global Illumination”
1 comentarios
Opiniones en Hacker News
Lo más impresionante aquí podría ser la velocidad: en la misma escena, RenderFormer tarda 0.0760 segundos, mientras que Blender Cycles tarda 3.97 segundos (12.05 segundos con ajustes más altos), y aun así mantiene un índice de similitud estructural de 0.9526 (de 0 a 1, donde 1 es una imagen idéntica). Basta ver las tablas 2 y 1 del paper.
Con esto, un modelo Transformer en el dispositivo podría ofrecer a diseñadores 3D una vista previa de render inmediata de mejor calidad en la web o en apps nativas.
Esa medición se hizo en una A100 con una versión del modelo en PyTorch sin optimizar. Las GPU de usuarios comunes son mucho más débiles, pero una GPU para diseñadores 3D podría ser suficiente para ver una mejora de velocidad bastante grande frente al renderizado tradicional. Si fuera un sistema basado en la web, también podría conectarse a una A100 en el backend y transmitir las imágenes al navegador.
La limitación es que, a medida que aumenta la complejidad de la escena, por ejemplo con sombras de formas complejas (probablemente también partículas o pelo), no es completamente preciso. Por eso, es probable que el render final siga haciéndose con métodos tradicionales para evitar los artefactos visuales desagradables que se ven hoy en muchas imágenes y videos generados con IA. Aun así, si alcanza un nivel suficientemente “aceptable” y la ganancia de velocidad es grande, los grandes estudios de animación que necesitan renderizar previews de largometraje para revisar música, historia, etc., podrían tener motivos para adoptarlo.
Las escenas son demos técnicas muy simples y de baja complejidad, y parece que configuraron Blender para hacer 4,000 iteraciones por píxel, lo cual no tiene mucho sentido. Blender se acerca bastante al resultado final tras unos pocos cientos de ciclos, y durante los 3,800 ciclos restantes probablemente solo quema ciclos de GPU sin mejorar.
Parece que incluyeron por error la fase de inicialización de Blender en el tiempo total de render, mientras que no incluyeron la inicialización del Transformer. Me gustaría ver el tiempo de render del segundo fotograma en cada sistema, y sospecho que Blender tendría un rendimiento mucho mejor. Los resultados del paper en sí son interesantes, pero hay matices en la configuración de Blender y en la forma de medir.
En ray tracing, el error disminuye de forma proporcional a la raíz cuadrada de la cantidad de muestras. Para las imágenes de referencia usadas en comparaciones de calidad, es normal usar una cantidad de muestras muy alta, pero en renderizadores offline reales se usan cantidades de muestras 1 o 2 órdenes de magnitud menores que en este paper.
En papers de gráficos es común incluir una imagen de referencia con muchísimas muestras para comparar calidad, pero no se suele comparar también el tiempo contra esa imagen de referencia. Si el resultado es una aproximación, lo justo sería compararlo con otros algoritmos de renderizado aproximado. Los path tracers en tiempo real modernos y los denoisers pueden renderizar escenas mucho más complejas en menos de 16 ms incluso en GPU de consumo.
La clave es “escenas mucho más complejas”. Si usas un Transformer, escala cuadráticamente tanto con la cantidad de triángulos como con la cantidad de píxeles de salida. No he seguido la investigación más reciente en machine learning, así que quizá esto ya mejoró, pero no creo que supere el escalamiento teórico de un path tracer típico: O(log n_triangles) y O(n_pixels). En la práctica, el escalamiento respecto de la cantidad de píxeles se acerca a sublineal por la alta coherencia entre píxeles vecinos.
Lo revisé rápido, pero no encontré detalles de cómo lo configuraron. Me pregunto si Cycles usó CPU en la A100 o kernels CUDA. Además, si fue el render de un solo fotograma, una parte no despreciable de esos 3.97 segundos podría haberse ido en iniciar el renderizador. Si renderizas una secuencia, el tiempo por fotograma debería bajar.
El escalamiento de complejidad por triángulo que mencionó el comentario hermano también duele.
El deep learning también se está usando con mucho éxito para eliminar ruido en imágenes renderizadas con iluminación global [1].
En este enfoque, un algoritmo tradicional de ray tracing calcula rápidamente una iluminación global aproximada de la escena, y una red neuronal elimina el ruido de la salida.
[1] https://www.openimagedenoise.org
Edición: la eliminación de ruido se ve mejor al 100% de zoom que al 125% DPI, y también se distinguen mejor los helechos de abajo.
En los papers de gráficos siempre hay que pensar en lo que no se ve.
Aquí hay muy pocos polígonos, baja resolución, no hay texturas, no hay motion blur, no hay profundidad de campo, y en la animación hay algunos artefactos.
Es una investigación interesante, pero poniéndolo en perspectiva, están usando una GPU moderna para crear imágenes parecidas a las que se hacían hace 30 años con una millonésima parte del cómputo.
Me pareció raro que ninguno de los ejemplos muestre lo que hay detrás de la cámara.
No sé si es una limitación del enfoque o una omisión al preparar los ejemplos, pero al hablar de reflejos e iluminación, lo que está detrás de la cámara es bastante importante.
Pregunto desde la ignorancia: ¿estas escenas se renderizan con base en cómo se espera que la escena sea renderizada? Si es así, no entiendo por qué usar esto en lugar de un método más directo. No parece que vaya a ser más rápido que un método directo.
Por ejemplo, si una escena es un bloque de pesos de entrada, ¿qué aspecto tendría si le agregas ruido? ¿Podrías obtener salidas interesantes que serían imposibles con métodos normales?
¿Sería interesante interpolar entre dos representaciones de escenas distintas? Ese tipo de preguntas.
Vaya, entonces el ciclo con la GPU queda cerrado. Del renderizado al cómputo, y de vuelta al renderizado.
Se ve bien, pero borroso. Me habría gustado ver una comparación de tiempos de render entre el renderizador neuronal y uno clásico.
En las animaciones, especialmente en Animated Crab y Robot Animation, se notan bastante artefactos de arte de IA que giran de forma poco natural alrededor del modelo cuando se mueven el objeto y la cámara.
https://renderformer.github.io/pdfs/renderformer-paper.pdf
Me pregunto si sería práctico usar el enfoque de red neuronal solo para la iluminación indirecta con geometría simplificada. Sería algo así como usar un rasterizador normal y añadirle iluminación global encima.
Tengo un amigo que ha trabajado con renderizadores basados en física en la industria del cine y también hizo investigación relacionada. Siempre me gusta escuchar sus historias y explicaciones sobre cómo se hacen las cosas en esa industria.
Me pregunto qué empresas están contratando hoy a este tipo de talento. ¿Las empresas de IA también estarán contratando ingenieros de renderizado para crear entornos de entrenamiento?
Si alguien busca contratar a un ingeniero de renderizado con experiencia en investigación e industria, puedo ponerlos en contacto. Mi amigo no usa redes sociales, pero está explorando oportunidades.
Es una investigación muy genial. Me encantan estos casos en los que se aplica Transformer a ámbitos que no son texto.
Creo que podría funcionar bien en áreas donde la entrada es secuencial y esos tokens de entrada están relacionados entre sí. Espero ver más investigación en este campo.
¿Qué áreas interesantes, fuera del texto, podrían encajar especialmente bien con Transformer?
La idea de entrenar un Transformer para convertir una descripción de escena —un conjunto de triángulos— en un arreglo 2D de píxeles, y hacer que el resultado se vea como los píxeles que produciría un renderizador con iluminación global para la misma escena, es brillante e interesante.
Viendo la investigación de los últimos 5 años, que esto funcione no resulta impactante en sí mismo, pero aun así se siente como un resultado bastante profundo. La arquitectura Transformer es realmente versátil.
En cualquier caso, es muy rápido, se acerca a la salida de render de Blender y parece ser aproximadamente un modelo de 1.000 millones de parámetros. No sé si es fp16 o fp32, pero si el archivo pesa 2 GB, no hay mucho de qué quejarse. Me gustaría ver demos de escenas más “realistas”, pero si quiero puedo descargarlo y ejecutarlo directamente en una Mac.