Trazado de rayos: qué aporta realmente más allá de las capturas bonitas

Qué aporta realmente el trazado de rayos (además del “wow”)

La rasterización es una mentira rápida que normalmente se ve bien. El trazado de rayos es una verdad más lenta que también miente, solo que de maneras más controlables.
La diferencia no es filosófica. Es operacional: qué tipo de errores obtienes, cómo los depuras y qué perillas realmente afectan el rendimiento.

1) Iluminación que se comporta como iluminación

Las características principales—reflexiones, sombras, iluminación global—no son “efectos” separados. Son preguntas distintas formuladas sobre el mismo sistema físico:
“¿De dónde viene la luz, a dónde va y qué golpea en el camino?”

Las canalizaciones raster a menudo aproximan esas respuestas con una pila de trucos locales:
mapas de sombras (desde el punto de vista de la luz), probes de reflexión, SSR (reflexiones en espacio de pantalla), oclusión ambiental, lightmaps y perillas de artista personalizadas.
El trazado de rayos reduce la cantidad de trucos que debes apilar—especialmente para reflexiones y luz indirecta—porque puede muestrear geometría que no está en pantalla y luz que no está prehorneada.

2) Menos trucos en la creación de contenido (y menos reuniones de “¿por qué este metal está mal?”)

SSR falla cuando el objeto reflejado no está visible en pantalla. Los probes de reflexión mienten cuando te mueves, porque son instantáneas congeladas.
Los artistas aprenden a manipular el sistema: “coloca un probe aquí”, “no gires ese espejo”, “haz el pasillo mate”.
Las reflexiones trazadas con rayos no eliminan la dirección artística, pero reducen la cantidad de trampas necesarias para una plausibilidad básica.

3) Un nuevo tipo de determinismo: motivado físicamente, ruidoso estadísticamente

El inconveniente: el trazado de rayos es, en esencia, muestreo Monte Carlo. Eso significa ruido, lo que implica desruido, lo que implica buffers de historial temporal, lo que implica vectores de movimiento,
lo que significa otro lugar más donde pueden esconderse bugs sutiles.

Pero aquí está la ventaja: los errores son estadísticos y medibles. Puedes cuantificar muestras por píxel, profundidad de rayo y varianza, y luego escoger un presupuesto.
Los trucos raster a menudo fallan catastróficamente—SSR “salta”, las sombras “nadie”, los probes “chirrían”. El trazado de rayos suele fallar gradualmente: más ruido, más desenfoque, menos estabilidad.
Eso es más fácil de razonar en producción porque puedes degradar de forma gradual.

4) Depurabilidad cuando tratas los rayos como solicitudes

Si gestionas sistemas de producción, ya tienes el instinto correcto: traza la solicitud, muestrea las rutas calientes, mide la latencia en la cola.
Los rayos son solicitudes. El recorrido BVH es tu enrutamiento. El sombreado es tu llamada a servicio downstream. El desruido es tu caché + capa de suavizado.

Los equipos que triunfan con trazado de rayos son los que construyen observabilidad para ello. No solo “FPS.” Desglose del tiempo de cuadro, conteos de rayos, divergencia, tasas de aciertos de caché
y tasas de rechazo de historial. Cuando puedes responder “¿qué cambió?” en dos minutos, el trazado de rayos deja de dar miedo.

Hechos y contexto que cambian tu forma de pensar

Algunos puntos históricos importan porque explican por qué el trazado de rayos parece magia para marketing pero es fontanería para ingenieros.
Son breves, concretos y útiles.

1. El trazado de rayos es anterior a la mayoría de los motores de juego. La idea central data de finales de los años 60 y principios de los 70 en renderizadores de investigación.
2. El trazado “estilo Whitted” (1979) no trataba de GI. Popularizó reflexiones/refractions recursivas y sombras duras—todavía comunes en modos “RT activado”.
3. El path tracing (mediados de los 80) es la herramienta principal para GI. Cambia exactitud por muestreo no sesgado; los modos modernos “path traced” suelen estar fuertemente guiados y desruidos.
4. La aceleración BVH lo hizo práctico. Sin estructuras de aceleración espacial, el trazado de rayos es básicamente “iterar cada triángulo”, lo cual es cosplay de rendimiento.
5. Los renderizadores offline para cine lo normalizaron primero. Las películas podían gastar minutos por fotograma; los juegos deben gastar milisegundos, así que los juegos dependen de técnicas híbridas y desruidores.
6. El trazado de rayos en tiempo real moderno fue posible con hardware dedicado. El recorrido/intersección en función fija (núcleos RT, bloques similares) no es un lujo; es la diferencia entre “demo” y “lanzar productivamente.”
7. El desruido no es opcional en tiempo real. La mayoría de títulos lanzados ejecutan dígitos simples de muestras por píxel para efectos RT; el desruidor hace la mayor parte del trabajo.
8. El render híbrido es la norma, no un compromiso. La rasterización sigue siendo la pasada principal de visibilidad; los rayos se usan para consultas específicas de transporte de luz donde los trucos raster fallan más.

Un modelo mental práctico: rayos, presupuestos y mentiras

Si estás decidiendo si lanzar trazado de rayos—o por qué ha retrocedido—no empieces con “¿es más rápido en esta GPU?”
Empieza con un modelo de presupuesto que se mapee directamente al tiempo de cuadro.

Los tres presupuestos que importan

• Presupuesto de rayos: rayos por píxel por efecto (reflexiones, sombras, GI), más profundidad de rayo (rebotes). Esto es tu tasa de solicitudes.
• Presupuesto de recorrido/intersección: qué tan caro es recorrer el BVH y probar geometría. Esto depende de la calidad del BVH, la complejidad de la escena y la coherencia.
• Presupuesto de sombreado/desruido: lo que haces después de impactar algo y cómo conviertes muestras ruidosas en una imagen estable.

Puedes consumir tu tiempo de cuadro en cualquiera de esos lugares, y la solución varía:
menos rayos, mejores builds de BVH, materiales más simples, mejores estrategias de muestreo o ajuste del desruidor.
“Apagar RT” no es una solución; es un botón de pánico.

Coherencia: el impuesto secreto

La rasterización prospera por la coherencia: píxeles vecinos ejecutan rutas de shader similares, obtienen texturas similares y golpean triángulos cercanos.
El trazado de rayos es un vandalismo para la coherencia. Los rayos se dispersan, golpean materiales distintos y crean divergencia de ramas.
La GPU puede manejar el caos, pero te lo cobra en ocupación y caché.

Por eso dos escenas con el mismo número de triángulos pueden diferir enormemente en coste de RT. Las reflexiones brillantes en una escena interior desordenada pueden ser brutales:
muchos rayos cortos e incoherentes; mucha variedad de materiales; mucho desajuste del historial del desruidor debido al movimiento.

Chiste #1: El trazado de rayos es como contratar a un investigador privado para cada píxel—preciso, caro, y te siguen enviando facturas etiquetadas como “misceláneo”.

El ruido no es “mala calidad”, es matemática que dice la verdad

Con muestras limitadas obtienes varianza. La varianza se ve como ruido. Si no desruides, envías brillo/centelleo.
Si desruides agresivamente, envías papilla. Si tus vectores de movimiento son incorrectos, envías fantasmas.

Entonces la pregunta correcta no es “¿por qué hay ruido?” Sino “¿qué nivel de varianza presupuestamos y cómo lo estabilizamos entre fotogramas?”
Eso lleva a ajustes accionables en lugar de discusiones estéticas.

Más allá de las capturas: valor operativo y para desarrolladores

El trazado de rayos como herramienta de corrección

En un renderizador híbrido, el trazado de rayos puede usarse en herramientas aunque no lo publiques ampliamente:
validar la colocación de probes de reflexión, detectar fugas de luz, comparar iluminación horneada vs dinámica y comprobar materiales.
Un modo “casi ground truth” en builds internas ahorra semanas de discusiones sobre si un bug es contenido, código o “así es SSR.”

El trazado de rayos como simplificador (cuando no te excedas)

La mayor ganancia de productividad no es “más bonito.” Es eliminar casos especiales.
Las cadenas de fallback de SSR, heurísticas de mezcla de probes y hacks de oclusión hechos a mano se acumulan como deriva de configuración en una flota.
Cada uno es defendible en su momento. Juntos se convierten en un pantano imposible de probar.

El trazado de rayos puede borrar una parte de ese pantano. Pero solo si eres disciplinado: elige los efectos donde RT reemplaza los peores trucos y para.
La forma más fácil de perder es intentar trazar todo con rayos, en todas partes, de una vez.

El trazado de rayos como arma de rendimiento (si ignoras la latencia cola)

Los promedios de FPS mienten. El pacing de fotogramas es lo que sienten los jugadores. El trazado de rayos tiende a introducir colas pesadas:
fotogramas ocasionales mucho más lentos por picos en la reconstrucción del BVH, horquillas de compilación de shaders o reinicios del historial del desruidor.

En términos de SRE, te importan los tiempos p95/p99, no la media. Trata un tartamudeo como un incidente.
Querrás saber: ¿los rayos se dispararon, las actualizaciones del BVH se dispararon o nos quedamos parados en la CPU enviando trabajo?

Una idea confiable de operaciones aplica aquí: “La esperanza no es una estrategia” — atribuida a ingenieros de cultura de confiabilidad (idea parafraseada).
Reemplaza la esperanza con contadores y trazas.

Dónde falla: los modos de fallo previsibles

1) Costes de construcción/actualización del BVH que te golpean en el tiempo de cuadro

La geometría estática es amistosa: construye el BVH una vez, reutiliza para siempre. La geometría dinámica es una factura recurrente.
Mallas skineadas, partículas con colisión, entornos destructibles—cualquier cosa que se mueva—obliga a actualizaciones.

Si reconstruyes demasiado en cada fotograma, verás picos periódicos. Si usas builds de baja calidad, el recorrido se vuelve más lento y el ruido aumenta porque los rayos fallan con geometría fina.
De cualquier forma: pagas.

2) Divergencia de shaders y complejidad de materiales

Los impactos de rayos pueden caer en cualquier parte. Eso significa que tus rutas de material “raras” se vuelven comunes en reflexiones.
El suelo brillante no solo refleja al héroe—refleja toda la peor biblioteca de materiales.

A menudo puedes arreglar el rendimiento de RT simplificando materiales solo para impactos de rayos (LOD de materiales para trazado).
Esto suena menos ofensivo de lo que parece. Las reflexiones ya están filtradas y desruidas; no necesitas cada microdetalle.

3) Inestabilidad del desruidor (fantasmas, smearing, desocclusión)

Los desruidores dependen de la acumulación temporal. Si los vectores de movimiento son incorrectos o los buffers de profundidad/normales no coinciden con el impacto RT, el desruidor
arrastrará historial a través de bordes y producirá fantasmas.

La desocclusión (píxeles recién visibles) es el modo de fallo clásico: no hay historial, así que o aceptas ruido o sobre-desenfocas.
La solución suele ser mejor rechazo de historial + máscaras reactivas más precisas, no “más muestras por todas partes.”

4) Stalls por envío y sincronización en CPU

Las cargas de trabajo de trazado de rayos pueden aumentar el número de pases, descriptores y puntos de sincronización.
Si tu frame en CPU ya está apretado, RT puede empujarte a la zona de “GPU inactivo esperando CPU”.

Por eso debes perfilar ambos lados. Una característica de GPU puede causar un incidente en CPU. El universo es así de grosero.

Chiste #2: El desruidor es básicamente un portero para fotones—si tus vectores de movimiento parecen falsos, no entras.

Guía rápida de diagnóstico

No tienes tiempo para un retiro de perfilado de tres días. Necesitas un triage de 20 minutos que te diga dónde excavar.
Aquí tienes una guía que funciona sorprendentemente a menudo.

Primero: ¿está limitado por GPU o por CPU?

• Revisa la utilización de GPU y la carga por motor (gráficos vs cómputo) mientras reproduces el problema.
• Revisa el tiempo de cuadro en CPU: si la CPU está al máximo y la GPU está desocupada, el trazado de rayos no es tu cuello de botella primario—aun si “RT activado” se correlaciona con el problema.

Segundo: si está limitado por GPU, ¿en qué categoría?

1. Recorrido/intersección pesado: coste de BVH, demasiados rayos, mala coherencia.
2. Sombreado pesado: materiales caros en puntos de impacto de rayos, demasiadas lecturas de texturas, divergencia.
3. Desruido/postprocesado pesado: resolución temporal, upscaling, buffers de historial, presión de ancho de banda.

Tercero: encuentra la causa de la latencia de cola (tartamudeos)

• Picos de reconstrucción del BVH (objetos dinámicos cruzando umbrales, streaming de assets).
• Horquillas de compilación de shaders activadas por nuevas permutaciones de material trazado.
• Presión de memoria (sobre-suscripción de VRAM causando paging o streaming agresivo).
• Burbujas de sincronización (CPU esperando fences de GPU, o viceversa).

Cuarto: valida los síntomas de corrección por separado del rendimiento

Los fantasmas y reflexiones incorrectas a menudo se reportan como “problemas de rendimiento” porque aparecen durante el movimiento cuando el tiempo de cuadro también cambia.
Separa los problemas: primero confirma si es un artefacto de contenido/desruidor; luego trata el rendimiento.

Tareas prácticas: comandos, salidas y la decisión que tomas

Estos son los tipos de comprobaciones rápidas y ejecutables que espero que un equipo pueda hacer en una estación de desarrollo o servidor de compilación.
El objetivo no es adorar herramientas. Es tomar una decisión a partir de cada salida.

Tarea 1: Identifica tu GPU y controlador (realidad base)

cr0x@server:~$ nvidia-smi
Tue Jan 13 12:14:02 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4   |
|-----------------------------------------+------------------------+----------------------|
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA RTX A5000               Off | 00000000:65:00.0  On   |                  Off |
| 30%   61C    P2              165W / 230W|   14520MiB / 24564MiB  |     94%      Default |
+-----------------------------------------+------------------------+----------------------+

Qué significa la salida: Tienes una GPU clase RTX con alta utilización y VRAM significativa en uso.

Decisión: Si GPU-Util está alto y los FPS son bajos, empieza por el perfilado de GPU; si el uso de VRAM está cerca del límite, sospecha presión de memoria y riesgo de paginación/tartamudeo.

Tarea 2: Comprueba la presión de VRAM a lo largo del tiempo (predictor de stutter)

cr0x@server:~$ nvidia-smi --query-gpu=timestamp,memory.used,memory.total,utilization.gpu --format=csv -l 1
timestamp, memory.used [MiB], memory.total [MiB], utilization.gpu [%]
2026/01/13 12:15:01, 14890, 24564, 96
2026/01/13 12:15:02, 21980, 24564, 88
2026/01/13 12:15:03, 24110, 24564, 91
2026/01/13 12:15:04, 24490, 24564, 79

Qué significa la salida: La VRAM está subiendo hasta el techo; la utilización baja cuando la memoria se satura.

Decisión: Reduce tamaños de buffers RT, reduce resolución de historial, ajusta presupuestos de streaming de texturas o reduce la resolución de efectos RT antes de tocar el conteo de rayos.

Tarea 3: Confirma rápidamente un cuello de botella en CPU (sanidad a alto nivel)

cr0x@server:~$ pidstat -t -p $(pidof game) 1
Linux 6.5.0 (server)  01/13/2026

12:16:10      UID      TGID       TID    %usr %system  %guest   %CPU   CPU  Command
12:16:11     1000     22541         -   165.00   12.00    0.00 177.00    10  game
12:16:11     1000         -     22578    55.00    3.00    0.00  58.00    10  RenderThread
12:16:11     1000         -     22579    46.00    2.00    0.00  48.00    12  RHIThread

Qué significa la salida: Los hilos de CPU están muy cargados; los hilos de envío de render están ocupados.

Decisión: Si la utilización de GPU es baja al mismo tiempo, optimiza la preparación RT en CPU (actualizaciones de descriptores, grabación de comandos) o reduce pases.

Tarea 4: Observa señales de pacing GPU/CPU con MangoHud (Linux)

cr0x@server:~$ mangohud --dlsym ./game -fullscreen
MangoHud v0.7.2
FPS: 72.1 (avg 68.4) | Frametime: 13.9ms (99th: 28.4ms) | GPU: 94% | VRAM: 23.8/24.0GB | CPU: 62%

Qué significa la salida: La media está más o menos bien, pero el percentil 99 del tiempo de fotograma es malo (tartamudeo).

Decisión: Busca picos: reconstrucción de BVH, streaming, compilación de shaders. No persigas primero el FPS promedio.

Tarea 5: Captura horquillas de compilación de shaders (tartamudeo común con “RT activado”)

cr0x@server:~$ journalctl --user -f | grep -i shader
Jan 13 12:18:07 server game[22541]: ShaderCache: compiling RT_REFLECTIONS_MATERIAL_143 (miss)
Jan 13 12:18:08 server game[22541]: ShaderCache: compiling RT_GI_INTEGRATOR_12 (miss)

Qué significa la salida: Está ocurriendo compilación en tiempo de ejecución durante el juego.

Decisión: Precompila permutaciones RT, distribuye una caché caliente, o reduce la explosión de permutaciones (menos variantes de material para impactos de rayos).

Tarea 6: Valida que el trazado de rayos por hardware esté realmente habilitado

cr0x@server:~$ vulkaninfo --summary | sed -n '1,80p'
Vulkan Instance Version: 1.3.275

Devices:
========
GPU0:
    apiVersion         = 1.3.275
    deviceName         = NVIDIA RTX A5000
    driverVersion      = 550.54.14
    deviceType         = DISCRETE_GPU

Device Extensions:
==================
VK_KHR_acceleration_structure     : extension revision 13
VK_KHR_ray_tracing_pipeline       : extension revision 1
VK_KHR_deferred_host_operations   : extension revision 4

Qué significa la salida: La GPU y el controlador exponen extensiones de trazado de rayos; la plataforma lo soporta.

Decisión: Si el rendimiento es terrible a pesar del soporte, comprueba si el juego ha recurrido a RT por software debido a una incompatibilidad de funciones.

Tarea 7: Detecta throttling de PCIe o degradación del enlace (cliff de rendimiento oculto)

cr0x@server:~$ lspci -s 65:00.0 -vv | grep -E "LnkCap|LnkSta"
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 8GT/s (downgraded), Width x8 (downgraded)

Qué significa la salida: La GPU está funcionando con un enlace PCIe degradado.

Decisión: Arregla la configuración de la BIOS, el riser/cableado o la elección de ranura. El trazado de rayos demanda ancho de banda; no depures shaders cuando el bus está cojo.

Tarea 8: Detecta signos de expulsión/paginación de VRAM (logs del kernel + driver)

cr0x@server:~$ dmesg --ctime | grep -iE "nvrm|xid|evict|oom" | tail -n 5
[Tue Jan 13 12:20:41 2026] NVRM: Xid (PCI:0000:65:00): 31, pid=22541, name=game, Ch 0000002b, MMU Fault
[Tue Jan 13 12:20:41 2026] NVRM: GPU memory page fault, likely due to invalid address or eviction

Qué significa la salida: El controlador reporta fallos de memoria GPU; podría ser presión de expulsión o un bug real.

Decisión: Si se correlaciona con VRAM cerca del límite, reduce el uso de memoria primero; si ocurre con baja VRAM, sospecha un bug de tiempo de vida de recursos/sincronización.

Tarea 9: Verifica relojes base y throttling (termales/potencia)

cr0x@server:~$ nvidia-smi -q -d CLOCK,POWER,TEMPERATURE | sed -n '1,120p'
Temperature
    GPU Current Temp                  : 83 C
Power Readings
    Power Draw                        : 229.50 W
    Power Limit                       : 230.00 W
Clocks
    Graphics                          : 1290 MHz
    Memory                            : 6001 MHz

Qué significa la salida: Estás en el límite de potencia y con alta temperatura; los relojes pueden estar más bajos de lo esperado.

Decisión: Atiende la refrigeración/política de potencia antes de micro-optimizar rayos. Una GPU que hace throttling falsea cualquier benchmark.

Tarea 10: Comprueba si el sistema está intercambiando (amplificador de stutter en CPU)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            64Gi        61Gi       1.2Gi       1.1Gi       1.8Gi       1.6Gi
Swap:           16Gi        7.9Gi       8.1Gi

Qué significa la salida: La máquina está usando swap bajo carga.

Decisión: Arregla el uso de memoria (caché de assets, sobrecarga del editor, símbolos de depuración) y deja de tocar ajustes de GPU hasta que el swap desaparezca.

Tarea 11: Identifica escalado de frecuencia o throttling de CPU (realidad de portátil)

cr0x@server:~$ lscpu | grep -E "Model name|CPU\(s\)|MHz"
Model name:                           Intel(R) Core(TM) i9-12900K
CPU(s):                               24
CPU MHz:                              998.762

Qué significa la salida: La CPU está funcionando alrededor de ~1GHz, a menudo por ahorro de energía o restricciones térmicas.

Decisión: Arregla el plan de energía / refrigeración. Los stalls en envío de CPU pueden hacerse pasar por “trazado de rayos lento.”

Tarea 12: Contabilidad básica de procesos GPU (quién te está robando la GPU)

cr0x@server:~$ nvidia-smi pmon -c 1
# gpu        pid  type    sm   mem   enc   dec   command
# Idx          #   C/G     %     %     %     %   name
    0      22541     G    92    61     0     0   game
    0      1042      G     8     4     0     0   Xorg

Qué significa la salida: El juego es el principal consumidor de GPU; poca interferencia.

Decisión: Si ves procesos inesperados (grabadores, navegadores, trabajos ML), mátalos antes de creer cualquier número de rendimiento.

Tarea 13: Captura stalls de E/S durante el streaming de assets (causa raíz de stutter)

cr0x@server:~$ iostat -xz 1
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          34.21    0.00    6.18   18.77    0.00   40.84

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await  aqu-sz  %util
nvme0n1         812.0  92480.0    12.0   1.46    9.12   113.90   122.0   15488.0    5.44    8.12   92.4

Qué significa la salida: Alta utilización de disco y iowait; el streaming puede causar picos de fotogramas.

Decisión: Reduce cargas de shader/material a demanda, aumenta la caché de streaming o mueve assets a almacenamiento más rápido antes de afinar el conteo de rayos.

Tarea 14: Valida hugepages/THP para rendimiento consistente en CPU (aburrido pero real)

cr0x@server:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]

Qué significa la salida: THP está deshabilitado (a menudo bueno para consistencia de latencia dependiendo de la carga).

Decisión: Si persigues stalls esporádicos en herramientas/builds, fija una política conocida y mide. No cambies a ciegas por máquina.

Tres mini-historias corporativas desde las trincheras

Mini-historia 1: El incidente causado por una suposición errónea

Un estudio lanzó una actualización que habilitó reflexiones trazadas por defecto en GPUs “de gama alta”. Clasificaron “gama alta” según una lista simple de IDs de dispositivo.
QA pasó. Las comparaciones de capturas eran preciosas. Las notas de parche eran confiadas.

Dos días después, los tickets de soporte se dispararon: usuarios con GPUs supuestamente soportadas reportaron fuertes tartamudeos al entrar en nuevas áreas.
El FPS promedio parecía bien en capturas internas, pero los usuarios describían “cada pocos segundos se congela.”
El equipo asumió que era compilación de shaders y dijo a los jugadores que “esperaran un poco por la caché.”

El problema real fue más desagradable y más simple: se subestimó el margen de VRAM. El equipo midió en máquinas con tarjetas de 24GB y asumió que las de 12GB eran seguras
porque el uso estático de VRAM cabía. Pero en la nueva actualización, las reflexiones cargaban variantes de materiales en alta resolución adicionales y extendían buffers de historial.
Bajo movimiento y cortes de cámara, el motor temporalmente excedió la VRAM y empezó a expulsar recursos.

Los tartamudeos fueron tormentas de expulsión. En algunos controladores se manifestaron como picos en el tiempo de fotograma; en otros, como cuelgues intermitentes del dispositivo que se recuperaban.
Su “lista de GPUs soportadas” no codificaba margen de memoria ni comportamiento del controlador.

La solución no fue glamorosa: añadieron un escalador de calidad consciente de VRAM, redujeron la resolución de historial RT en tarjetas de 12GB y limitaron la distancia de las reflexiones.
También dejaron de usar “modelo de GPU” como proxy de “puede permitirse esta característica.” El incidente terminó cuando empezaron a medir lo que importaba.

Mini-historia 2: La optimización que salió mal

Otro equipo vio que las reconstrucciones de BVH eran caras para objetos dinámicos. Alguien propuso una optimización:
“Marquemos más cosas como estáticas y actualicemos solo transforms.” Los números en un benchmark simple mejoraron.
El cambio pasó la revisión de código porque parecía una ganancia de rendimiento inofensiva.

Luego llegaron los informes de bugs: las reflexiones de los personajes a veces carecían de extremidades. Las sombras estaban mal solo en modo trazado.
Era intermitente. Empeoró en escenas con mucha gente. El equipo persiguió configuraciones del desruidor durante una semana porque los artefactos parecían inestabilidad temporal.

La causa real: trataron mallas skineadas como si solo actualizaran transformaciones. Pero el skinning cambia posiciones de vértices, no solo transforms de objetos.
El BVH ahora se construía para geometría obsoleta. Los rayos intersectaban la pose antigua y fallaban en la nueva, produciendo “colisiones fantasma” y impactos perdidos.

El rendimiento “mejoró” porque el motor dejó de hacer trabajo necesario. Eso no es optimizar; es mentirle a tu propio renderizador.
El rollback arregló la corrección, y entonces hicieron una optimización real: actualizaciones BLAS por hueso o por clúster donde se soportaba, además de LOD agresivo para RT.

La lección es dolorosamente familiar desde ops: si tu cambio hace el tablero más verde rompiendo la instrumentación, no mejoraste el sistema.
Lo hiciste más difícil de ver que está peor.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo que preparaba una característica de GI trazada tenía una regla que sonaba aburrida: cada afirmación de rendimiento debía respaldarse con una captura de un escenario nombrado,
una trayectoria de cámara fija y un conjunto almacenado de contadores del motor. Nada de “se siente más rápido.”

También mantenían un pequeño zoo de máquinas: un escritorio de gama alta, una GPU de gama media con menos VRAM, un portátil con límites agresivos de potencia,
y una máquina “desordenada” con apps en segundo plano—porque los jugadores son desordenados.

Tarde en el desarrollo vieron una regresión: el tiempo p99 se duplicó, pero solo en el portátil. La GPU no estaba al máximo; la CPU tampoco.
Sin sus capturas estructuradas, esto habría sido una caza de fantasmas.

La captura mostró picos periódicos en actualizaciones de BVH alineados con el streaming de assets. En el portátil, el SSD era más lento y la CPU bajaba frecuencia por calor,
ampliando la ventana de streaming. Eso extendía el periodo durante el cual la canalización RT debía reconstruir/actualizar estructuras de aceleración para assets recién cargados.

La solución fue aburrida y efectiva: repartieron las builds de BVH en varios fotogramas, pre-streaming de un subconjunto de mallas antes de cortes de cámara,
y añadieron una puerta para “no compilar shaders a mitad de fotograma” para permutaciones RT. La característica se lanzó estable.
Nadie escribió un post de blog celebratorio sobre ello. Los usuarios simplemente no tartamudearon. Ese es el sueño.

Errores comunes (síntoma → causa raíz → solución)

1) Síntoma: las reflexiones saltan o desaparecen en los bordes de la pantalla

Causa raíz: Sigues viendo comportamiento de SSR o una táctica híbrida que cambia abruptamente.

Solución: Fusiona SSR con reflexiones RT mediante una heurística estable (rugosidad, confianza del rayo) y evita cambios duros. Asegura que la distancia máxima de RT cubra los casos esperados.

2) Síntoma: estelas fantasma en reflexiones al mover la cámara

Causa raíz: Los vectores de movimiento para objetos reflejados son incorrectos o faltan; el desruidor reutiliza historial inválido.

Solución: Valida vectores de movimiento para toda la geometría en movimiento, implementa máscaras reactivas para brillos especulares y aprieta el rechazo de historial en regiones de alta velocidad.

3) Síntoma: “chispas” aleatorias en superficies brillantes

Causa raíz: Muy pocas muestras y muestreo pobre (fireflies), a menudo por emisivos brillantes o entornos HDR.

Solución: Limita la radiancia para la entrada del desruidor, mejora el muestreo (MIS, muestreo por importancia) y trata emisivos con cuidado en los caminos RT.

4) Síntoma: stutters masivos al entrar en un área nueva

Causa raíz: Compilación de shaders y/o builds de BVH coinciden con streaming.

Solución: Precompila permutaciones de shader RT; preconstruye BLAS/TLAS donde sea posible; programa builds en varios fotogramas; calienta cachés durante las pantallas de carga.

5) Síntoma: el modo RT funciona bien 10 minutos y luego empeora

Causa raíz: Fragmentación/sobresuscripción de VRAM a medida que se acumulan más materiales y buffers de historial.

Solución: Limita el historial RT, usa escalado de resolución, aplica presupuestos de streaming de texturas y audita asignaciones transitorias en pases RT.

6) Síntoma: las sombras RT se ven “demasiado nítidas” o con “suavidad errónea”

Causa raíz: Estás haciendo de facto sombras duras (una sola muestra) sin muestreo de luces de área.

Solución: Muestrea luces de área (o aproxima) y desruide; ata la suavidad al tamaño y distancia de la luz; no prometas “físicamente correcto” si no lo muestreaste.

7) Síntoma: el rendimiento se desploma en escenas con mucho vidrio/vegetación

Causa raíz: Geometría alpha-tested y materiales transmisivos crean muchas intersecciones y rutas de sombreado divergentes.

Solución: Usa geometría “proxy” simplificada para RT, limita la profundidad de rayo para refracción y añade LOD de material para impactos de rayos (shaders/texturas más baratos).

8) Síntoma: picos en tiempo de cuadro de CPU cuando RT está activado

Causa raíz: Demasiados pases/descriptores, actualizaciones AS por fotograma, batching pobre, sobrecarga de sincronización.

Solución: Reduce el churn de estado por fotograma, agrupa actualizaciones, prealoca descriptores y perfila hilos de envío—no solo kernels de GPU.

9) Síntoma: RT funciona en un proveedor pero está roto en otro

Causa raíz: Comportamiento indefinido en shaders, suposiciones de precisión o dependencia de rarezas del controlador.

Solución: Ejecuta capas de validación, aplica barreras/sincronización explícitas y prueba entre proveedores desde temprano. “Funciona en mi GPU” no es una estrategia de render.

10) Síntoma: “RT activado” hace la imagen más borrosa incluso a la misma resolución

Causa raíz: El desruidor está difuminando en exceso por alta varianza, normales/profundidad incorrectas para reproyección o acumulación demasiado agresiva.

Solución: Incrementa calidad donde importa (muestras en efectos clave), arregla la consistencia del G-buffer, ajusta umbrales del desruidor y añade enfoque con cuidado después del desruido.

Listas de verificación / plan paso a paso

Checklist A: Decidir si el trazado de rayos vale la pena para tu proyecto

1. Elige el punto de dolor, no la palabra de moda. ¿Tu problema peor son las reflexiones (fallos de SSR), las sombras (aliasing) o la GI (iluminación plana)? Elige uno.
2. Define el presupuesto en ms. “Podemos gastar 2.5ms en reflexiones a 1440p con upscaling” es un plan. “Queremos RT” no lo es.
3. Define tu modo de fallo. Bajo carga, ¿prefieres ruido, desenfoque o rango reducido? Decide e implementa degradación elegante.
4. Comprométete con la observabilidad. Añade contadores para conteos de rayos, tiempo de build de AS, tiempo de pase de desruido, rechazo de historial y margen de VRAM.
5. Planifica las permutaciones. Si cada material se duplica en variante “RT”, necesitas gobernanza o acabarás con horquillas de compilación.

Checklist B: Publicar una característica RT sin avergonzarte

1. Bloquea un path de benchmark estándar. Misma trayectoria de cámara, misma escena, mismas banderas de build. Almacena capturas.
2. Prueba el caso de VRAM de gama media. Si solo pruebas en la tarjeta insignia, estás construyendo una demo, no un producto.
3. Precompila o cachea shaders. Verifica que no ocurran compilaciones de shaders durante el juego con logging.
4. Programa builds de AS. No reconstruyas todo en un fotograma al hacer streaming; amortiza.
5. LOD de materiales para impactos de rayos. Elimina ramas costosas para el sombreado RT donde no se notará.
6. Valida vectores de movimiento. Especialmente para mallas skineadas, partículas y UVs animadas—los desruidores te castigarán.
7. Vigila el tiempo p99. Si p99 es malo, los usuarios dirán “tartamudea” aunque el FPS promedio esté bien.

Checklist C: Cuando el rendimiento empeora tras cambios “pequeños”

1. Confirma el entorno (driver, límites de potencia, termales, enlace PCIe). No depures fantasmas.
2. Compara capturas de frame GPU entre builds buenos y malos en el mismo escenario.
3. Revisa deltas de VRAM (nuevos buffers, mayor resolución de historial, BLAS/TLAS más grandes).
4. Revisa deltas de conteo de rayos (duplicación accidental vía configuración de calidad o interacciones de escalado de resolución).
5. Revisa el alcance de actualización del BVH (¿más objetos se volvieron “dinámicos?”)
6. Revisa entradas del desruidor (normales, profundidad, vectores de movimiento). Los artefactos pueden causar “arreglos” que incrementan el coste.

Preguntas frecuentes

1) ¿El trazado de rayos es solo reflexiones y sombras?

No. Esos son los usos más fáciles de mercadear. El valor más profundo es consultas unificadas de transporte de luz: visibilidad a luces, rebotes indirectos y oclusión precisa.
En la práctica, la mayoría de títulos usan RT selectivamente porque los presupuestos son reales.

2) ¿Por qué el trazado de rayos se ve ruidoso?

Porque estás muestreando una integral compleja con muy pocas muestras por píxel. El ruido es varianza.
El RT en tiempo real típicamente usa cuentas muy bajas de muestras y confía en desruido + acumulación temporal para verse estable.

3) ¿Por qué activar RT a veces reduce la utilización de GPU?

Puede introducir puntos de sincronización, aumentar el coste de envío en CPU o causar presión de memoria que detiene la GPU.
La alta utilización no está garantizada si la canalización tiene muchas burbujas.

4) ¿Cuál es la diferencia entre trazado de rayos y path tracing en juegos?

“Trazado de rayos” en juegos suele significar efectos específicos (reflexiones/sombras/GI) con rayos limitados y fuerte desruido.
“Path tracing” busca simular la iluminación global completa con muchos rebotes, pero en tiempo real sigue siendo agresivamente optimizado y desruido.

5) ¿Los núcleos RT dedicados hacen que el trazado de rayos sea “gratuito”?

No. Aceleran el recorrido/intersección, que es enorme, pero aún pagas por generación de rayos, sombreado, ancho de banda de memoria y desruido.
Puedes perfectamente estar limitado por sombreado o por ancho de banda aun con hardware RT.

6) ¿Por qué los espejos todavía a veces se ven mal con RT?

Porque muchas implementaciones limitan la distancia de rayo, la profundidad de rayo o la complejidad del material; y los desruidores pueden emborronar detalles.
Además, algunas canalizaciones usan fallback híbrido que puede no coincidir entre SSR/probes/RT en casos límite.

7) ¿Cuál es la causa más común de tartamudeo con RT?

Compilación de shaders en tiempo de ejecución y streaming de assets que coinciden con builds/actualizaciones de BVH.
El tiempo medio puede verse bien mientras p99 es horrible. Arregla las horquillas primero.

8) ¿Deberíamos aumentar muestras por píxel para arreglar artefactos?

Solo después de verificar vectores de movimiento, rechazo de historial y entradas del desruidor. Más muestras pueden ayudar, pero son costosas y pueden ocultar un bug de corrección.
Arregla datos incorrectos antes de comprar más matemática.

9) ¿El render híbrido es “menos correcto” que el trazado completo?

Es menos uniforme, pero a menudo más publicable. La rasterización es extremadamente eficiente para visibilidad primaria.
Usa rayos donde los trucos raster fallan: reflexiones fuera de pantalla, sombras suaves y ciertos casos de GI.

10) ¿Qué debo medir primero: rayos, BVH o desruidor?

Mide primero el desglose del tiempo de fotograma. Si no puedes desglosar el tiempo de GPU por pase, estás adivinando.
Luego mira conteos de rayos y tiempo de actualización de BVH—esos son los costes de primer orden habituales.

Siguientes pasos que no te harán perder el tiempo

Si estás evaluando el trazado de rayos, no empieces activando todas las casillas y admirando los charcos.
Empieza decidiendo qué error visual intentas eliminar de tu canalización: reflexiones rotas, sombras inestables o luz indirecta plana.
Elige uno, asígnale un presupuesto en milisegundos y construye la observabilidad para mantenerlo honesto.

Si ya lo lanzaste y te está perjudicando, haz el triage en este orden:
tiempo de fotograma p99 (tartamudeo) → margen de VRAM → compilación de shaders → alcance de actualización del BVH → entradas del desruidor.
Esa secuencia evita los dos desastres clásicos: pasar semanas afinando muestras cuando estás paginando VRAM, y “optimizar” rompiendo la corrección.

El trazado de rayos no es un modo mágico de gráficos. Es un nuevo servicio en tu canalización de fotogramas, con un modelo de costes y un modelo de errores.
Trátalo como infraestructura de producción: instruméntalo, presupuestalo y mantenlo aburrido. Las capturas se encargarán del resto.