La Fundación Blender presenta Cycles X

[3dpoder]

Ya han pasado 10 años desde que se anunció el motor de render Cycles. En la última década Cycles se ha convertido en un renderizador de producción con pleno derecho, utilizado por muchos artistas y estudios.

Los desarrolladores del motor han aprendido muchas cosas en estos 10 años, cosas que funcionaron bien y también cosas que no funcionaron tan bien, o quedaron desactualizadas a medida que los algoritmos de renderizado y el hardware evolucionaban.

El equipo de desarrollo está dispuesto a hacer mejoras. Sin embargo, algunas decisiones tomadas en el pasado ahora están frenando el rendimiento y dificultando el mantenimiento del código.

Para abordar eso, hace tiempo empezaron un proyecto de investigación llamado Cycles X, con el objetivo de actualizar la arquitectura y prepararla para los próximos 10 años.

En lugar de encontrar soluciones rápidas u optimizaciones que resuelvan solo una parte del problema, estamos replanteando la arquitectura en su conjunto.

En términos generales, el objetivo del proyecto es:

• Mejorar la arquitectura para el desarrollo futuro.
• Mejor usabilidad de la ventana gráfica y la representación por lotes.
• Incrementar el rendimiento en las CPU y GPU modernas.
• Introducir algoritmos de renderizado más avanzados.

Su primer objetivo fue validar la nueva arquitectura. Para ello, han implementado el prototipo de un nuevo kernel de GPU y nuevos algoritmos de programación para presentación por lotes y ventanas gráficas.

Hoy compartimos algunos resultados iniciales de rendimiento y publicamos el código para los colaboradores de Cycles.

Hay disponible una presentación técnica para los desarrolladores sobre la nueva arquitectura, y el código se puede encontrar en la rama cycles-x en git.blender.org.

Queda mucho trabajo por delante. Calculamos que pasarán al menos 6 meses hasta que este trabajo sea parte de un lanzamiento oficial de Blender.

Primeros resultados

En primer lugar, algunos resultados de la representación de GPU con escenas de referencia conocidas. Las escenas se han modificado para eliminar entidades como la representación por volumen, que aún no se han implementado.

Ten en cuenta que los números cambiarán a medida que sigamos trabajando en la nueva arquitectura. Patrick Mours añadió el soporte de OptiX hace unos días.



Las mejoras más significativas se encuentran en escenas interiores con muchos rebotes de luz y sombreadores, donde los nuevos núcleos pueden lograr una mayor ocupación y coherencia.

El rendimiento de representación de CPU es aproximadamente el mismo que antes en este momento, pero la nueva arquitectura también abre nuevas posibilidades allí.

En segundo lugar, han estado trabajando para mejorar la representación de la ventana gráfica.

Los kernels de renderizado más rápidos ayudan, pero también encontramos que mejorar la programación, el tiempo y los mecanismos de visualización puede hacer que la ventana gráfica sea más interactiva.

El nuevo soporte de ventana gráfica para muestras de muestreo y procesamiento por lotes adaptables lo hace para que la imagen se limpie más rápido una vez que se realicen las primeras muestras.

Esperando avances

En los próximos meses probarán nuevas ideas de optimización y restauraran la funcionalidad que falta. Cuando falta funcionalidad, normalmente es porque quieren adoptar un enfoque diferente en la nueva arquitectura.

Algunos ejemplos:

Renderizado por volumen: planean implementar ray-marching y el muestreo ligero con algoritmos más modernos.
Captadores de sombras: probaran un algoritmo diferente que puede tener en cuenta la luz indirecta.
Renderizado multi-dispositivo: experimentaran con un equilibrio de carga más detallado sin tiles.

Más allá de esto, la nueva arquitectura debería permitirles encajar más fácilmente en algoritmos de renderizado como la guía de rutas, con la que experimentaran e investigaran cómo se pueden hacer compatibles con GPU.

La Fundación Blender ha anunciado Cycles X, una importante reescritura del próximo renderizador de producción del software, diseñado para probarlo en el futuro durante los próximos 10 años.

La nueva versión, que actualmente se incorporará a Blender 3.1, mejora en gran medida los tiempos de renderizado en las GPU modernas y la interactividad de la ventana gráfica, y agregará compatibilidad con la representación reanudable e incremental.

Una importante reescritura de Cycles en el décimo aniversario del renderizador desvelada por los desarrolladores Brecht van Lommel y Sergey Sharybin durante una transmisión online en Blender today, Cycles X.

La reescritura está pensada para abordar problemas de larga duración con el representador, para facilitar la compatibilidad con el nuevo hardware y para agregar características más avanzadas para la representación de producción.

A pesar del creciente uso de Eevee, el renderizador en tiempo real más nuevo de Blender, para la salida de calidad final, Cycles sigue siendo la herramienta principal de la mayoría de los usuarios de Blender para renderizado fotorrealista, particularmente para VFX y visualización arquitectónica.

Compatibilidad con el renderizado reanudable

Los cambios previstos para futuras compilaciones incluyen compatibilidad con la representación reanudable, lo que debería permitir pausar un renderizado, guardar los resultados en el disco y reiniciarlo más adelante.

Los desarrolladores también planean algoritmos más avanzados para la representación de volúmenes, cáusticas y para escenas de muestreo con un gran número de luces.

La nueva arquitectura también debería facilitar la implementación de grupos de luz: compatibles con el antiguo motor de renderizado interno de Blender, pero no actualmente en Cycles.

Más información aunque no mejor explicada en el blog de Blender.

[3dpoder]

Cycles X en GPU AMD está disponible para Blender 3.0. Las compilaciones iniciales de Cycles X se ejecutaban únicamente en GPU Nvidia. Este cambio amplía fronteras en el hardware dando cabida a más artistas.

Cycles X, es en sí una reescritura del renderizador Cycles de Blender que se presenta en la versión 3. El cambio más significativo es que ahora es compatible con las GPU AMD utilizando HIP. Un sistema de código abierto que permite que el código se ejecute tanto en hardware Nvidia CUDA como AMD.

La funcionalidad está disponible en la versión beta actual de Blender 3.0 para cualquier persona con el nuevo controlador beta de Radeon Software de AMD.

En el momento del anuncio oficial, el desarrollador de Cycles X, Brecht van Lommel, comentó que el equipo planeaba recuperar el soporte para el hardware de AMD e Intel. Pero no dijo cuándo ni de qué forma.

Para los usuarios de AMD, ambas preguntas quedan respondidas por una publicación en el Blog de desarrolladores de Blender. El gerente de producto de AMD, Brian Savery, anuncia oficialmente que Cycles X admitirá GPU AMD a través de HIP.

¿Qué es HIP?

Una API desarrollada en código C++ de código abierto y con lenguaje de kernel. HIP es la abreviatura de Heterogeneous computing Interface for Portability. HIP permite a los desarrolladores crear software que se ejecuta en GPU Nvidia y AMD a partir de la misma base de código.

A veces descrito como una forma de portar herramientas utilizando el marco informático CUDA de Nvidia a las GPU AMD. HIP ha existido desde hace años como parte de la plataforma ROCm (Radeon Open Compute) de AMD.

Sin embargo, esta es la primera vez que vemos que se utiliza para software de medios y entretenimiento. Todos los casos anteriores son para herramientas de simulación y visualización científica.

¿Funcionará Cycles X en las GPU AMD?

AMD no ha publicado ningún punto de referencia para saber cómo funcionará Cycles X en sus GPU, pero el rendimiento teóricamente debería ser similar a una tarjeta CUDA equivalente.

La documentación online describe que HIP tiene poco o ningún impacto en el rendimiento sobre la codificación directamente en modo CUDA. Esta apreciación se confirma por el Laboratorio Nacional Oak Ridge de los Estados Unidos, que utilizó la plataforma para permitir que su software interno basado en CUDA se ejecutara en GPU AMD.

Sin embargo, además de CUDA, Cycles X utiliza la API OptiX de Nvidia para acelerar el trazado de rayos (RayTrace) de la GPU.

Eso puede significar que las GPU Nvidia actuales aún superan a las tarjetas AMD, por lo que sería interesante ver algunas puntuaciones de referencia independientes.

La Fundación Blender ha anunciado que admitirá la API de código abierto Vulkan para el trazado de rayos de GPU en Eevee. El motor de renderizado en tiempo real de Blender, pero aún no han realizado el anuncio equivalente para Cycles X.

¿En qué GPU AMD se ejecutará Cycles X?

AMD ha validado el soporte para Cycles X en su serie Radeon RX 6000, su generación actual de GPU de consumo, y la Radeon Pro W6800, su actual tarjeta de estación de trabajo de gama alta.

Sin embargo, la implementación solo requiere una tarjeta RDNA o posterior, por lo que también puede funcionar en otras GPU AMD más antiguas.

El anuncio oficial de Brian Savery

Tenemos algunos desarrollos interesantes para compartir sobre el soporte de tarjetas gráficas AMD. Blender 3.0 fue anunciado con algunas reescrituras al motor de renderizado Cycles (AKA Cycles X). Esto eliminó la compatibilidad de OpenCL para la representación en GPU AMD por razones técnicas y de rendimiento.

Para ayudar a abordar esto, AMD ha estado trabajando muy de cerca con Blender para mejorar el soporte para la representación de GPU en Blender utilizando la API AMD HIP, para garantizar que los usuarios de tarjetas gráficas AMD puedan aprovechar todas las mejoras que se encuentran en Cycles X.

Para las GPU AMD, esto estará en Blender 3.0, previsto para diciembre de 2021.

Las versiones anteriores de Cycles, el trazador de rutas basado en la física de Blender, admitía la representación a través del marco OpenCL. OpenCL es un lenguaje de programación basado en C que permite ejecutar programas en muchas GPU que lo admiten. Sin embargo, en el futuro, nuestros socios en Blender esperaban fusionar el código OpenCL separado con la CPU C ++ y el código de renderizado CUDA.

En resumen, con Cycles X, estaban buscando una manera de compilar una sola base de código que pudiera usarse en todos los diferentes dispositivos en los que Cycles puede renderizar, incluidas las tarjetas gráficas AMD.

Afortunadamente, AMD tiene una solución de código abierto para desarrolladores solo para eso. HIP (Heterogeneous-computing Interface for Portability) es una API de tiempo de ejecución de C ++ y lenguaje de kernel que permite a los desarrolladores crear aplicaciones portátiles para GPU AMD y NVIDIA a partir de un solo código fuente.

Esto permite a los desarrolladores de Blender Cycles escribir un conjunto de kernels de renderizado y ejecutarlos en múltiples dispositivos. La otra ventaja es que las herramientas con HIP permiten una fácil migración del código CUDA existente a algo más genérico.

AMD ha estado trabajando estrechamente con Blender para agregar soporte para dispositivos HIP en Blender 3.0, y este código ya está disponible en la última versión beta de Blender 3.0.

Archivo adjunto 241165

HIP Render Device para Cycles

Para usar esto con una tarjeta gráfica AMD compatible, se necesita un controlador AMD Radeon Software actualizado. Hoy estamos lanzando un controlador beta de Windows para los usuarios que deseen probar nuestro soporte para Cycles X en la última versión beta de Blender 3.0.

Como esta es una versión beta tanto de nuestro controlador como de Blender 3.0, nuestro soporte para Cycles X se encuentra actualmente en versión preliminar. Tendremos más que compartir sobre nuestro soporte en diciembre, cuando se espera que se lance Blender 3.0. (Se espera soporte para Linux Q1 2022)

Compatibilidad HIP Render Device para Cycles

Cycles X en Blender 3.0 está habilitado en tarjetas gráficas AMD con arquitectura RDNA y versiones posteriores. AMD ha validado la compatibilidad con las siguientes tarjetas gráficas de escritorio.

• AMD Radeon PRO W6800
• AMD Radeon 6900 XT
• AMD Radeon 6800 XT
• AMD Radeon 6800
• AMD Radeon 6700 XT
• AMD Radeon 6600 XT
• AMD Radeon 6600

Por si te interesa el código fuente de HIP, lo puedes ver en GitHub.

[3dpoder]

La Fundación Blender ha publicado un resumen de las últimas características de Cycles X. Se ha reescrito el código del motor de render Cycles para adaptarlo a Blender, antes de su lanzamiento estable en Blender 3.0 la próxima semana.

Los cambios desde la versión alfa inicial incluyen una mejor representación del cabello y de la piel; funcionamiento de la oclusión ambiental mejorado y se elimina más ruido que en las versiones anteriores. Además de ofrecer soporte para micro-jittering.

Cycles X también será compatible con sistemas AMD y GPU de Nvidia trabajando sobre sistemas operativos Windows. El soporte para la GPU AMD bajo Linux estará disponible a partir de Blender 3.1, junto con un nuevo backend Metal para macOS.

Mejor rendimiento en volúmenes y cabello

Anunciado por primera vez en abril, Cycles X es una reescritura importante del principal motor de renderizado de producción de Blender, destinado a ser el motor oficial durante los próximos 10 años.

Las pruebas iniciales mostraron que Cycles X renderizaba hasta siete veces más rápido que Cycles en las escenas de referencia de Blender cuando se ejecutaba una GPU Nvidia Quadro RTX 6000.

Ese aumento de velocidad máxima es ligeramente mayor en la compilación actual. Los resultados del benchmark en la publicación del blog muestran que Blender 3.0 se renderiza entre una y ocho veces más rápido que Blender 2.93 en la última GPU RTX A6000 de Nvidia.

Ciertos tipos de escenas se benefician más, en particular aquellos con volúmenes; ya que la representación de volúmenes de GPU no se admitía en las compilaciones alfa iniciales de Cycles X.



Solucionado el problema que ralentizaba el cabello o pelo en capas

Si bien la mayoría de las escenas de referencia se renderizaban más rápido con Cycles X, algunas que involucraban muchas capas de cabello transparente mostraban regresiones de rendimiento.

El problema es que en la representación de GPU, cuando un pequeño subconjunto de toda la imagen es lento de renderizar (como el cabello de un personaje), la ocupación de la GPU sería baja. Esto se mejoró al hacer que el algoritmo estimara el número de muestras a renderizar en un lote de manera más inteligente.

Otra parte de la solución fue cambiar la programación del kernel de sombras (Shaders). Anteriormente, para continuar con el siguiente rebote se tenía que esperar a que todas las luces y sombras se resolvieran en el rebote anterior. Ahora esto está desvinculado, y el trabajo de rastreo de sombras para muchos rebotes se puede acumular en una cola. Esto da un mayor número de rayos de sombra para rastrear a la vez, mejorando la ocupación de la GPU. Resulta importante especialmente cuando solo una pequeña cantidad de píxeles rebota profundamente en el cabello transparente, como en la escena de primavera.

Además, encontraron que la transparencia en el cabello suele ser bastante simple, ya sea un valor fijo o un gradiente simple para desvanecerse desde la raíz hasta la punta. En lugar de evaluar el sombreador para cada intersección de sombras. Ahora bakeamos la transparencia en las curvas del cabello y simplemente las interpolamos. Los resultados del renderizado son idénticos en todas las pruebas. A continuación se muestran dos imágenes de muestra para comparar los resultados.

Otras mejoras importantes en Cycles X

Según la publicación oficial, desde entonces, han restaurado la representación de volúmenes y lo que conlleva un aumento del rendimiento en la representación por GPU en escenas de volumen.

También se ha mejorado el manejo de la oclusión ambiental y las escenas con muchas capas de cabello transparente.

Se ha restaurado el soporte para las pasadas de profundidad del denoiser y se ha mejorado la eliminación de volúmenes.

El soporte para micro-jittering mejora aún más el rendimiento al renderizar en GPU Nvidia bajo OptiX.
Las compilaciones actuales de Cycles X ahora admiten la codificación de distancia. También conocida como "micro-jittering", cuando se usan las opciones Sobol o Progressive Multi-Jitter para muestrear la iluminación en una escena.

Codificación de distancia

Los usuarios pueden establecer el valor de codificación de distancia manualmente o hacer que Cycles elija un valor automáticamente.

Según la Blender Foundation, la codificación a distancia puede mejorar el rendimiento entre un 1 y un 5 por ciento al renderizar en GPU. Aunque hay que tener claro que esto solo supone un beneficio constante cuando se usa el backend OptiX.

Cuando se utiliza el backend CUDA, el uso de la codificación automática de distancia actualmente aumenta los tiempos de renderizado en la mayoría de las escenas de referencia estándar.

Cycles X admite la representación por GPU en AMD y GPU Nvidia

Si bien las compilaciones iniciales eran solo para Nvidia, las actuales admiten la representación por GPU en hardware AMD a través del marco HIP (Heterogeneous-computing Interface for Portability); que reemplaza al antiguo backend OpenCL de Cycles.

Tienes más información en el blog oficial.

[3dpoder]

La Fundación Blender ha publicado una descripción general del trabajo realizado con Facebook Reality Labs en el renderizador Cycles de Blender. El comunicado abarca el primer año de la empresa matriz Meta como patrocinador corporativo de la aplicación 3D de código abierto.

El trabajo, destinado a mejorar la representación en tiempo real de personajes digitales, incluye un nuevo procedimiento Alembic que acelera la carga de cachés de animación.

Facebook (ahora Meta) se unió al fondo de desarrollo Blender durante 2020 con el propósito principal de dar soporte al desarrollo de Cycles. Un equipo de Facebook Reality Labs dirigido por Feng Xie y Christophe Hery está interesado en utilizar Cycles como renderizador para algunos de sus proyectos. Eligieron Cycles porque es un renderizador de producción con todas las funciones; sin embargo, también están interesados en mejorar las posibilidades y características de renderizado en tiempo real de Cycles para el renderizado humano digital de alta calidad.

Hay tres áreas principales de colaboración

Optimización de la actualización de escenas: esta área pretende reducir el esfuerzo para sincronizar los datos de la escena y sus copias en el dispositivo para permitir la representación de animaciones persistentes en tiempo real.

Agregar la API de procedimiento nativa y procedimiento Alembic para acelerar la carga de animaciones de geometría bakeada y la reproducción en tiempo real. Mejorar los modelos BSDF para la representación de la piel y los ojos. En particular, dar soporte al modelo anisotrópico BSSRDF para la representación de la piel, y acelerar la convergencia de los efectos cáusticos importantes para la representación ocular.

Este artículo pone de manifiesto el trabajo realizado hasta ahora.

Optimización de actualización de escenas

Para admitir tantas plataformas como sea posible, Cycles almacena los datos de toda la escena en búferes unificados y específicos. Por ejemplo, todas las UV de todos los objetos se almacenan juntas en un único búfer contiguo en la memoria; de manera similar para triángulos o gráficos de sombreado. Un problema importante con este enfoque es que si algo cambia, los búferes se destruyen antes de ser recreados, lo que implica copiar todos los datos otra vez, primero en los búferes, luego en los dispositivos. Estas copias y transferencias de datos pueden llevar mucho tiempo.


Todas las geometrías se empaquetan en búferes unificados y específicos antes de copiarse en el dispositivo.


Cuando se modifica cualquier geometría, todos los datos se invalidan, se vuelven a empaquetar y se copian en el dispositivo.

La solución, propuesta por Feng, fue preservar los búferes, siempre y cuando el número de objetos o sus topologías permanezcan sin cambios. Pero copiar en los búferes solo los datos de los objetos que han cambiado. Por ejemplo, si solo han cambiado las posiciones de una malla, solo se copian sus posiciones en el búfer global, mientras que no se copian otros datos. Anteriormente, todos los datos (UV, atributos, etc.) tenían que ser copiados. De la misma manera, si solo cambia una malla en la escena, solo se copiarán sus datos: no se realizará ninguna otra copia de ningún otro dato de ningún otro objeto.


Solo se invalidan y copian los datos específicos de la geometría modificada. Sin embargo, todavía necesita ser copiado en el dispositivo.

La detección de cambios se realiza a través de una nueva API para los nodos de los que se compone la escena de Cycles, (que no debe confundirse con los nodos de sombreado). Mientras que en el pasado las aplicaciones cliente podían tener acceso directo a los sockets de los nodos, estos ahora están encapsulados y tienen indicadores específicos para indicar si su valor proviene de una modificación. Estos indicadores entran en acción al establecer un nuevo valor en el socket si difiere del anterior. Por lo tanto, para cada socket, ahora podemos detectar automáticamente lo que ha cambiado al sincronizar datos con Blender o cualquier otra aplicación. Tener esta información por socket es crucial para evitar hacer trabajos innecesarios, y esto con una mayor granularidad de lo que Cycles podía hacer hasta ahora.

Otra optimización es la adición de BVH Refit para OptiX: los BVH de los objetos se mantienen en la memoria y solo se reconstruyen si cambia la topología del objeto. De lo contrario, el BVH simplemente se modifica para tener en cuenta las nuevas posiciones de vértice.

Con todos estos cambios se ha conseguido reducir el consumo de memoria en Cycles, y han echo posible dividir el tiempo de sincronización a la mitad en términos generales. Los resultados de referencia utilizando el carácter Trudy 1.0 de FRL se comparten a continuación.

Sistema procesal

Otra novedad fue la adición de un sistema procesal. Los procedimientos son nodos que pueden generar otros nodos en la escena justo antes de la representación. Tal mecanismo es común en otros motores de renderizado de producción.

Alembic fue el sistema elegido para implementar el procedimiento de las primeras versiones de Cycles. Alembic es ampliamente utilizado por los programas para crear contenido 3D para intercambiar animaciones de geometría bakeada; incluidas las deformaciones de la piel y el cabello. En el futuro, esto permite explorar el desarrollo de un procedimiento USD nativo.

El procedimiento Alembic permite la carga de archivos Alembic de forma nativa, evitando pasar por Blender y su ARN; que resulta lento para traspasar y convertir. El procedimiento es accesible a través de Blender, y cuando está activo, Blender no cargará datos del archivo Alembic, ahorrando un tiempo precioso. El procedimiento también tiene su propia memoria caché para precargar datos desde el disco para limitar las costosas operaciones de E/S. Con este procedimiento podemos cargar datos mucho más rápido que desde Blender.

Mejores BSDF

El equipo de Facebook también está interesado en mejorar la corrección física de los BSDF de Cycles. Por ejemplo, una contribución reciente vio la representación de la dispersión del subsuelo mejorada a través de la adición de una función de fase anisotrópica para simular mejor la interacción entre la luz y la piel. Esta contribución fue hecha por Christophe Hery, el coautor de la publicación original de Pixar que presenta esta mejora a la comunidad de renderizado.

Colaboraciones futuras

Aunque esta colaboración se centraba anteriormente en la velocidad de sincronización, ahora se centra en la corrección física y la velocidad de RayTrace. Pronto se publicará que mejorará la representación de cáusticas. También hay varias optimizaciones posibles para mejorar el rendimiento de la transferencia de datos y el uso de memoria de Cycles, especialmente en VRAM.