Trazado de rayos vs path tracing: ¿cuál es la diferencia en el renderizado 3D?

Introducción

Trazado de rayos vs path tracing no es una competencia entre dos técnicas rivales: el path tracing (trazado de trayectorias) es un tipo de trazado de rayos. El trazado de rayos clásico sigue un conjunto pequeño y fijo de rayos (hacia espejos, a través del vidrio, hacia cada luz), mientras que el path tracing sigue muchas trayectorias de rebote aleatorias por píxel y las promedia. Por eso captura con tanta fidelidad la luz indirecta suave y por eso exige tanto más cómputo.

Ese costo de cómputo es lo que importa en producción. Cuando un fotograma tarda 40 minutos en lugar de 4, o llega salpicado de ruido, la causa suele estar en el path tracing: cuántas muestras requiere, cuántos rebotes sigue y cómo se limpia el ruido restante. Esta guía explica ambas ideas, muestra cómo las aplican Arnold, Cycles, Karma, V-Ray y Redshift, y qué implica eso para el tiempo de renderizado.

La guía se centra deliberadamente en el renderizado offline, fotograma a fotograma, para cine, animación, visualización y producto. Cómo los videojuegos llevaron el trazado de rayos a los gráficos en tiempo real se explica en nuestra historia del trazado de rayos en tiempo real en los videojuegos, y la distinción más amplia entre renderizado interactivo y de fotograma final está en renderizado en tiempo real vs offline. Si desea repasar lo básico sobre qué hace un motor de renderizado antes de continuar, empiece por qué es el renderizado.

Diagrama comparativo: el trazado de rayos clásico envía un rayo de cámara que se divide en rayos fijos de reflexión, refracción y sombra, mientras que el path tracing envía muchas trayectorias de rebote aleatorias por píxel y las promedia

Trazado de rayos: definición

El trazado de rayos simula la luz trabajando hacia atrás: en lugar de seguir la luz desde una lámpara hasta que por casualidad llega a una cámara, el motor de renderizado lanza un rayo desde la cámara a través de cada píxel y pregunta qué golpea. La idea es antigua. El artículo de Wikipedia sobre el trazado de rayos en gráficos por computadora (consultado el 19 de octubre de 2026) atribuye a Arthur Appel el primer uso publicado en 1968, un método no recursivo que hoy suele llamarse ray casting.

La versión a la que la mayoría de las personas se refiere con "trazado de rayos" procede de Turner Whitted, cuyo algoritmo recursivo se presentó en SIGGRAPH en 1979 y se publicó en 1980. Cuando un rayo de cámara golpea una superficie, el motor de renderizado genera nuevos rayos en direcciones específicas y predecibles:

• un rayo de sombra hacia cada luz, para comprobar si algo la bloquea,
• un rayo de reflexión en la dirección del espejo, si la superficie es reflectante,
• un rayo de refracción a través de la superficie, si es transparente.

Cada uno de ellos puede generar sus propios rayos, formando un árbol ramificado que se detiene a una profundidad establecida. El resultado es determinista, bueno para reflejos nítidos, refracción limpia y sombras duras, y deficiente en todo lo que depende de luz que llega desde muchas direcciones a la vez: sombras suaves, desenfoque en reflejos glossy, sangrado de color y la luz del día que se va apagando hacia el fondo de una habitación.

Esos efectos son lo que la industria llama iluminación global, y el trazado de rayos clásico por sí solo no la calcula. Durante mucho tiempo, los motores de renderizado de producción la resolvieron con sistemas adicionales como cachés de irradiancia, mapas de fotones y final gather, cada uno con sus propios ajustes y artefactos.

Path tracing: definición

El path tracing fue introducido y bautizado por Jim Kajiya en su artículo de 1986 sobre la ecuación de renderizado, según el artículo de Wikipedia sobre path tracing (consultado el 19 de octubre de 2026). Estima esa ecuación mediante muestreo aleatorio.

Un rayo sale de la cámara a través de un píxel y golpea una superficie. En lugar de dividirse en un conjunto fijo de rayos hijos, elige una única dirección nueva al azar, ponderada por el material (un espejo lo envía casi exactamente en una dirección; una pared de yeso mate puede enviarlo casi a cualquier parte). El rayo vuelve a rebotar, y otra vez, hasta que alcanza una luz, sale de la escena o llega a un límite de rebotes. Esa cadena única y sin ramificaciones de rebotes es una trayectoria, y devuelve una estimación de cuánta luz llega al píxel por ese recorrido.

Una trayectoria es una mala estimación; mil trayectorias por el mismo píxel, promediadas, son una buena. Eso es el muestreo Monte Carlo de trayectorias de luz. Como cada trayectoria puede rebotar en cualquier cosa, el path tracing calcula la luz indirecta, las sombras suaves, los reflejos glossy, las cáusticas (en principio) y el sangrado de color como un único proceso unificado, sin una caché aparte para cada efecto.

La contrapartida es el ruido. Hasta que se han promediado suficientes trayectorias, los píxeles vecinos discrepan entre sí y la imagen se ve granulada. Esa contrapartida es la parte que aparece en su factura de renderizado.

La diferencia de un vistazo

Una síntesis útil: el trazado de rayos es la herramienta (lanzar un rayo y averiguar qué golpea), y el path tracing es una estrategia para usar esa herramienta y resolver el problema completo de la iluminación. Todo path tracer moderno se construye sobre el trazado de rayos. No todo trazador de rayos es un path tracer.

Por qué el path tracing produce ruido y por qué limpiarlo es caro

El ruido de una imagen renderizada con path tracing no es un error: cada píxel es el promedio de muestras aleatorias, y ese promedio oscila hasta que hay suficientes. El artículo de Wikipedia sobre la integración de Monte Carlo (consultado el 19 de octubre de 2026) indica que el error de la estimación disminuye con 1/√N, donde N es el número de muestras. En términos de renderizado: para reducir a la mitad el ruido visible se necesitan aproximadamente cuatro veces más muestras por píxel. Para reducirlo a la mitad otra vez, dieciséis veces las originales. Si el tiempo de renderizado escala aproximadamente con el número de muestras, como ocurre en la mayor parte del fotograma, limpiar el último resto de grano es la parte más cara de todo el render.

Cuatro mosaicos de ruido con 16, 64, 256 y 1.024 muestras por píxel, que muestran cómo el ruido visible se reduce a la mitad con cada aumento de cuatro veces en las muestras

Algunas escenas son más difíciles que otras, y los motivos son predecibles:

• Fuentes de luz pequeñas u ocultas. La luz del día a través de una rendija estrecha implica que pocas trayectorias aleatorias llegan a encontrar la luz, de modo que la estimación converge despacio.
• Materiales glossy y refractivos. El metal cepillado, el vidrio esmerilado y los líquidos son difíciles de muestrear con eficiencia.
• Muchos rebotes. Los interiores de paredes blancas dependen de varios rebotes; reducir el límite acelera el render, pero oscurece las esquinas.
• Volúmenes y dispersión subsuperficial. El humo, la niebla y la piel añaden dispersión dentro del material, lo que multiplica el trabajo por trayectoria.
• Desenfoque de movimiento y profundidad de campo. Cada muestra también elige un instante en el tiempo y un punto de la lente, por lo que se necesitan más muestras.

La resolución determina cuántos píxeles necesitan respuesta; la iluminación determina cuántas muestras necesita cada píxel antes de que su respuesta esté limpia.

Cómo usan hoy el path tracing los motores de renderizado de producción

La mayoría de los motores de renderizado offline de producción se construyen hoy en torno al path tracing, pero no todos de la misma manera. La distinción útil es entre aplicar path tracing a cada rebote y aplicarlo al primer rebote con una caché para el resto.

Arnold. La documentación de Arnold de Autodesk (consultada el 19 de octubre de 2026) lo describe como un motor de ray/path tracing Monte Carlo sin sesgo y basado en la física, y afirma que evita algoritmos de caché como el photon mapping y el final gather. La calidad se controla sobre todo mediante el número de muestras: un fotograma más limpio requiere más muestras, y más muestras requieren más tiempo.

Cycles. Cycles, de Blender, es un path tracer, y sus ajustes de muestreo (manual de Blender 5.2 LTS, consultado el 19 de octubre de 2026) muestran con claridad el conjunto de herramientas moderno: un número máximo de trayectorias por píxel, un umbral de ruido que detiene el muestreo de las regiones una vez que están suficientemente limpias (muestreo adaptativo), un límite de tiempo opcional y una selección de denoisers.

Karma. La propia documentación de Karma de SideFX (documentación de Houdini 22.0, consultada el 19 de octubre de 2026) lo define como el path tracer de Houdini basado en la física.

V-Ray. Chaos divide el trabajo en un motor de iluminación global primario y uno secundario. En V-Ray GPU para 3ds Max, la página de GPU Global Illumination de Chaos (consultada el 19 de octubre de 2026) indica que el motor primario es siempre Brute Force (muestreo puro con path tracing del primer rebote), con Brute Force o Light Cache para los rebotes secundarios. Light Cache es una aproximación precalculada de los rebotes posteriores, que sacrifica algo de precisión a cambio de un gran ahorro de muestras.

Redshift. La documentación de iluminación global de Redshift de Maxon (consultada el 19 de octubre de 2026) describe Brute Force como el motor de GI más preciso y más lento, con ruido cuando el número de rayos es bajo, y ofrece Irradiance Point Cloud como motor secundario que hace más rápido y más limpio el Brute Force primario en iluminación difícil, a costa de algo de almacenamiento.

Ese último patrón, path tracing para el rebote que más se ve y una caché para el resto, es la razón por la que las palabras "con sesgo" y "sin sesgo" aparecen en las conversaciones sobre motores de renderizado. El promedio de un motor sin sesgo converge hacia la respuesta físicamente correcta a medida que aumentan las muestras. Uno con sesgo acepta una pequeña diferencia sistemática (por una caché, un clamp o un límite de rebotes) a cambio de converger mucho antes. Ninguno es incorrecto. En animación, las cachés requieren cuidado, porque una caché calculada fotograma a fotograma puede parpadear; en imágenes fijas, suelen ser el camino más rápido hacia una imagen limpia.

Denoising: menos muestras, la misma fecha de entrega

Si reducir el ruido a la mitad cuesta cuatro veces las muestras, el atajo evidente es detenerse antes y filtrar el ruido restante. Eso es lo que hacen los denoisers modernos.

Los dos denoisers que más conocen los artistas son Intel Open Image Denoise y NVIDIA OptiX. Intel describe Open Image Denoise (consultado el 19 de octubre de 2026) como una biblioteca de código abierto de filtros de denoising para imágenes renderizadas con trazado de rayos. La página de muestreo de Cycles citada arriba enumera ambos como opciones, señala que OptiX solo está disponible en GPU de NVIDIA y describe el ajuste automático como una preferencia por Open Image Denoise frente a OptiX.

Los denoisers se entrenan para distinguir el ruido de muestreo del detalle real, pero tienen efectos secundarios:

• Pérdida de detalle fino. Las texturas finas, el pelo y la geometría delgada pueden quedar suavizados si entraron muy pocas muestras.
• Parpadeo temporal. Un denoiser que trabaja sobre cada fotograma por separado puede producir resultados ligeramente distintos en fotogramas consecutivos, lo que en animación se percibe como destello.
• Pases de composición. Si se aplica denoising al pase beauty pero no a los AOV (o al revés), los pases dejan de sumar correctamente en el compositing.

La regla práctica es aplicar denoising a un fotograma que ya esté razonablemente convergido, no a uno que sea sobre todo ruido. Un denoiser reduce el número de muestras que usted necesita. No las sustituye.

Qué significa el path tracing para el tiempo de renderizado

El tiempo de renderizado de un trabajo con path tracing es el producto de unos pocos números: fotogramas, píxeles por fotograma, muestras por píxel y cuán difícil resulta cada muestra en esa escena.

Un ejemplo hipotético, solo a modo ilustrativo. Un plano de diez segundos a 24 fotogramas por segundo son 240 fotogramas. Supongamos que cada fotograma necesita 16 minutos en una máquina con el número de muestras que lo deja limpio. Son 64 horas-máquina. Ahora el cliente pide menos grano en las sombras. Si reducir el ruido a la mitad significa cuatro veces las muestras, y el tiempo escala con las muestras, el mismo plano pasa a unas 256 horas-máquina. Un buen denoiser puede recuperar buena parte de ese tiempo, y por eso el número de muestras y el denoiser se deciden juntos sobre un fotograma de prueba.

Aritmética del tiempo de renderizado de un plano con path tracing: 240 fotogramas por 16 minutos por fotograma equivalen a 64 horas-máquina, y cuatro veces más muestras para reducir el ruido a la mitad dan unas 256 horas-máquina

Tres hábitos mantienen esa aritmética bajo control:

1. Mida sobre un fotograma representativo. El fotograma más difícil del plano (el que tiene más vidrio, volumen o desenfoque de movimiento) es el que hay que probar, no el primero.
2. Use muestreo adaptativo y un umbral de ruido donde el motor de renderizado lo ofrezca, para que las zonas limpias, como el cielo y las paredes lisas, dejen de muestrearse pronto.
3. Invierta las muestras donde mira el ojo. Aumente las muestras de las luces o los materiales concretos que siguen ruidosos, no las de todo el fotograma.

La lista completa de ajustes que modifican el tiempo de renderizado, desde los límites de rebotes hasta el tamaño de las texturas, está en nuestra guía de optimización del tiempo de renderizado. Si esas muestras se ejecutan más rápido en procesadores o en tarjetas gráficas depende del motor de renderizado y de la escena, algo que se trata en renderizado con GPU vs renderizado con CPU.

Cómo ejecutar trabajos con path tracing en una render farm

Cada fotograma de una secuencia con path tracing se renderiza de forma independiente, así que 240 fotogramas repartidos entre muchas máquinas terminan en el tiempo de unos pocos, mientras que el cómputo total, que es lo que factura una render farm, sigue siendo el mismo. Si la idea de una render farm le resulta nueva, nuestra guía sobre qué es una render farm explica el modelo.

En Super Renders Farm, que es una render farm completamente gestionada, usted sube la escena y la render farm se ocupa del software y de las licencias de render, de modo que no hay sesión de escritorio remoto ni nada que instalar. La mayor parte del trabajo que vemos se renderiza en CPU (V-Ray y Corona en 3ds Max, Arnold en Maya, Cycles en Blender, Karma y Mantra en Houdini), y se ejecuta en nuestros nodos de CPU.

El path tracing en GPU se ejecuta en nuestros nodos de GPU, cada uno con 2x NVIDIA RTX 5090 y 32 GB de VRAM por tarjeta. La memoria es por tarjeta y no se agrupa entre las dos tarjetas, de modo que un fotograma en GPU tiene que caber en 32 GB. Redshift se renderiza solo en nodos de GPU. Redshift en Cinema 4D, Maya y Houdini, y Cycles en GPU, se ejecutan ahí sin necesidad de una solicitud de configuración; el hardware de GPU y los motores compatibles figuran en nuestra página de render farm en la nube con GPU. Si una escena no cabe en la memoria de una sola tarjeta, un path tracer en CPU suele ser la vía más segura para ese trabajo.

Las tarifas actuales están en la página de precios; hemos dejado las cifras fuera de este texto explicativo porque cambian, y porque el número de muestras que usted establezca altera el costo final más que cualquier tarifa por hora. Las cuentas nuevas reciben $25 en Render Credits gratuitos, que pueden gastarse en un fotograma de prueba representativo antes de comprometer una secuencia, y nuestro equipo de soporte atiende por chat en vivo 24/7.

Malentendidos frecuentes

"El path tracing y el trazado de rayos son tecnologías que compiten." No lo son. El path tracing es un método construido sobre el trazado de rayos. Hoy, un motor de renderizado de producción descrito como trazador de rayos suele ser, por debajo, un path tracer.

"Más muestras siempre significan una mejor imagen." Una vez superado el punto en que el ruido es invisible a la resolución de entrega, las muestras adicionales solo añaden tiempo de renderizado. Ese punto es el que el muestreo adaptativo y los umbrales de ruido están diseñados para encontrar.

"Con sesgo significa incorrecto." Las técnicas con sesgo, como las cachés, convergen antes y son habituales en producción. La elección correcta depende del plano, sobre todo de si es una imagen fija o una animación.

"El path tracing en GPU siempre es más rápido." A menudo es más rápido por fotograma, pero solo si la escena cabe en la memoria de la tarjeta y el motor de renderizado admite todas las funciones que usa la escena. Las escenas grandes de visualización arquitectónica y los volúmenes pesados suelen renderizarse con más fiabilidad en CPU.

FAQ

Q: ¿Cuál es la diferencia entre el trazado de rayos y el path tracing? A: El trazado de rayos clásico sigue un conjunto fijo de rayos desde cada punto de impacto (hacia las luces, en la dirección del espejo y a través de las superficies transparentes) y produce un resultado determinista y sin ruido, pero sin luz indirecta. El path tracing sigue muchas trayectorias de rebote aleatorias por píxel y las promedia, lo que calcula de forma natural la luz indirecta, las sombras suaves y el sangrado de color, pero produce ruido hasta que se han promediado suficientes muestras.

Q: ¿Qué es el path tracing, explicado de forma sencilla? A: El path tracing envía un rayo desde la cámara hacia la escena y deja que rebote en una dirección aleatoria en cada superficie hasta que encuentra luz; luego repite el proceso muchas veces por píxel y promedia los resultados. Lo introdujo Jim Kajiya en su artículo de 1986 sobre la ecuación de renderizado y es la base de la mayoría de los motores de renderizado de producción offline actuales.

Q: ¿Es el path tracing un tipo de trazado de rayos? A: Sí. El path tracing usa el trazado de rayos para averiguar qué golpea cada rayo y después aplica muestreo Monte Carlo para decidir hacia dónde va el siguiente rayo. Todo path tracer es un trazador de rayos, pero no todo trazador de rayos es un path tracer.

Q: ¿Por qué las imágenes renderizadas con path tracing tienen ruido? A: Cada píxel es el promedio de muestras aleatorias, y ese promedio es incierto hasta que hay suficientes. El error disminuye en proporción a uno dividido por la raíz cuadrada del número de muestras, así que reducir el ruido a la mitad requiere aproximadamente cuatro veces las muestras y, en la mayoría de las escenas, aproximadamente cuatro veces el tiempo de renderizado.

Q: ¿V-Ray, Arnold, Cycles y Redshift usan path tracing? A: Sí, de formas distintas. Arnold, Cycles y Karma son path tracers que controlan la calidad principalmente mediante las muestras. V-Ray y Redshift ofrecen un motor Brute Force que aplica path tracing al primer rebote y que puede combinarse con una caché para los rebotes posteriores (Light Cache en V-Ray, Irradiance Point Cloud en Redshift), lo que converge antes a costa de un pequeño sesgo.

Q: ¿El denoising sustituye a un mayor número de muestras? A: No del todo. Los denoisers, como Intel Open Image Denoise y NVIDIA OptiX, permiten detenerse con menos muestras, pero son más eficaces en fotogramas que ya están razonablemente limpios. Con muy pocas muestras se puede perder detalle fino en imágenes fijas y provocar parpadeo en animación.

Q: ¿El path tracing es más rápido en GPU o en CPU? A: Depende del motor de renderizado y de la escena. El path tracing en GPU suele ser más rápido por fotograma cuando la escena cabe en la memoria de la tarjeta, mientras que el path tracing en CPU maneja escenas muy grandes, volúmenes pesados y funciones que un motor de GPU no admite. En nuestra render farm, los nodos de GPU llevan 2x RTX 5090 con 32 GB por tarjeta, sin agrupar entre tarjetas.

Q: ¿Puede una render farm acelerar el path tracing? A: Una render farm no reduce el cómputo que necesita un fotograma, pero renderiza muchos fotogramas al mismo tiempo, de modo que una secuencia termina en una fracción del tiempo real transcurrido. El tiempo total de máquina, que depende en gran medida del número de muestras que usted elija, es lo que determina el costo.