Arquitectura Nanite de Unreal Engine 5: Análisis Técnico Completo, Estrategias de Optimización y Guía de Desarrollo para PlayStation 5
Fundamentos de la Geometría de Micropolígonos Virtualizada y el Cambio de Paradigma
Una de las restricciones más prolongadas durante décadas en el desarrollo de tecnologías de renderizado en tiempo real (real-time rendering) y en la industria de los gráficos por computadora ha sido el cuello de botella inevitable creado en la comunicación entre la unidad central de procesamiento (CPU) y la unidad de procesamiento gráfico (GPU) debido a los presupuestos de polígonos y las cantidades de llamadas de dibujo ("draw calls") en pos del uso eficiente de los recursos de hardware. 1 En los flujos de trabajo tradicionales de desarrollo de juegos, para que los artistas 3D y los directores técnicos pudieran transferir modelos de alto detalle (por ejemplo, esculturas de ZBrush con calidad cinematográfica, escaneos láser o datos de fotogrametría) a los motores de juego, era obligatorio realizar optimizaciones manuales de la topología, crear cadenas de "Level of Detail" (LOD) y hornear (baking) los detalles de alta resolución en un mapa de normales ("Normal Map"). 1 Este proceso no solo creaba una carga de trabajo ardua que alargaba el calendario de producción, sino que también atrapaba el nivel de detalle en pantalla en un límite artificial debido a las restricciones de memoria. 1 Con Unreal Engine 5 (UE5), la tecnología Nanite, que se ha convertido en el estándar de la industria, es un sistema de geometría de micropolígonos virtualizada (virtualized micropolygon geometry) que elimina de raíz estos obstáculos tradicionales. 1 Nanite elimina los presupuestos de polígonos como una restricción técnica, permitiendo que los archivos fuente compuestos por miles de millones de polígonos directamente con calidad de cine se transmitan a la escena en tiempo real, sin requerir ningún proceso manual de LOD. 1 El sistema está diseñado para procesar únicamente los detalles que son visibles en ese momento en la pantalla por la cámara del jugador; ningún triángulo o fragmento de geometría más pequeño que el tamaño de un píxel se renderiza innecesariamente. 3 Esta tecnología ofrece un sistema LOD automático continuo, fluido e ininterrumpido, reemplazando por completo la canalización de renderizado (rendering pipeline) tradicional con una arquitectura de transmisión (streaming) de datos orientada exclusivamente a la GPU. 1 Las innovaciones fundamentales de Nanite se agrupan en cuatro títulos principales 1:
Geometría Virtualizada: Toda la escena se trata como una única malla estática gigante y solo las partes visibles en pantalla participan en el procesamiento.
Nivel de Detalle Automático (LOD): En lugar de cambios de LOD graduales y discretos (LOD popping), se proporciona un cambio de detalle continuo y fluido según la distancia y la resolución de la pantalla.
Canalización Orientada a la GPU (Pipeline): Las llamadas de dibujo ("draw calls") y las operaciones de eliminación ("culling") se trasladan de la CPU a la potencia de procesamiento paralelo de la GPU.
Transmisión Eficiente (Efficient Streaming): Se proporciona transmisión directa de memoria a través de SSD, cargando instantáneamente en la memoria solo los datos de geometría necesarios.
Este informe de investigación examina en un marco analítico exhaustivo los principios de funcionamiento en profundidad del sistema Nanite, los pasos necesarios para la integración de proyectos, los requisitos de optimización, cómo superar los cuellos de botella y las dinámicas de desarrollo de juegos específicas para la plataforma PlayStation 5 (PS5), que cuenta con una compresión inigualable a nivel de hardware y transmisión de datos de alta velocidad (I/O).
Arquitectura Técnica y Estructuras de Datos de Nanite
La filosofía subyacente en el núcleo del sistema Nanite es tratar los datos de geometría no como mallas estáticas gigantescas (static meshes) que intentan ajustarse a los límites de memoria, sino como conjuntos de datos fragmentados que se transmiten (streaming) dinámicamente y se gestionan bajo demanda, tal como ocurre en las texturas virtuales (virtual texturing). 3 Mientras que los motores tradicionales intentan cargar y procesar todo el objeto en la memoria incluso si solo una pequeña parte del mismo está en el campo de visión (frustum) de la cámara, Nanite evalúa esta visibilidad con una precisión de píxel milimétrica. 3
Estructura de Clústeres Jerárquicos (Hierarchical Cluster Structure)
Durante la fase de importación (import), los algoritmos de Nanite analizan los modelos 3D y los dividen en árboles de clústeres (cluster) jerárquicos. 1 Cada malla estática procesada se divide en pequeños paquetes de datos (clústeres) compuestos exactamente por 128 triángulos para ofrecer el mejor rendimiento a nivel de hardware. 1 Este tamaño fijo de 128 triángulos es una unidad óptima seleccionada específicamente para adaptarse plenamente a los tamaños de frente de onda ("wavefront") o "warp" de las GPU modernas, maximizando la eficiencia de procesamiento de las unidades de cálculo paralelo y los límites de caché ("cache limits"). 1 Estos clústeres forman entre ellos una estructura de datos de árbol similar a un Gráfico Acíclico Dirigido (Directed Acyclic Graph - DAG) que contiene información de cuadros delimitadores ("bounding box"), métricas de error geométrico para la selección de LOD en el espacio de pantalla ("screen space") y relaciones de padre a hijo (parent-child). 1 A medida que la cámara se acerca o se aleja del objeto en cuestión, el sistema navega en tiempo real sobre esta estructura de árbol para decidir qué clúster es el más adecuado para la densidad de píxeles en pantalla en cada región de la pantalla. 1 A diferencia de los enfoques tradicionales, el todo del objeto no cambia de repente. En lugar de un cambio de LOD discreto, las diferentes regiones de la superficie del objeto se pueden procesar simultáneamente a diferentes niveles de detalle de clúster, uniéndose suavemente por los bordes de manera que no se produzca ninguna rotura visual o grieta ("crack") en la rasterización del hardware. 3
Tampones de Visibilidad (Visibility Buffer) y Sombreado Desacoplado
La estructura más crítica que permite a Nanite superar los cuellos de botella de la CPU y revoluciona las arquitecturas de renderizado modernas es trasladar una gran parte de la canalización de renderizado ("pipeline") directamente a la GPU y reemplazar la lógica de sombreado ("shading") tradicional Avanzada (Forward) o Diferida (Deferred) con el "Visibility Buffer" (Tampón de Visibilidad). 1 El concepto de tampón de visibilidad en el ciclo de renderizado de Nanite funciona de la siguiente manera: en las estructuras G-Buffer tradicionales, al calcular los píxeles, se escriben en la memoria datos de gran tamaño para cada píxel, como color, normal y rugosidad ("roughness"). Nanite, en cambio, registra solo un número de identificación (Primitive ID y Cluster ID) con un tamaño de 32 bits o 64 bits para cada píxel en la pantalla. 1 Este búfer de memoria no contiene datos de color ni de sombreado; es solo un mapa de referencia que muestra qué triángulo y qué clúster aparecen en ese píxel específico de la pantalla. 1 Una vez que el búfer de visibilidad se llena por completo, los datos del material se invocan solo una vez para cada píxel en el espacio de pantalla y se realiza el proceso de sombreado. Gracias a esta arquitectura "desacoplada" (decoupled), no se realizan cálculos de material innecesarios para millones de triángulos que quedan detrás de la cámara, se ocultan detrás de otro objeto o no aportan nada a la imagen final. Esta situación elimina por completo el problema del "Overdraw" (sobreescritura), uno de los mayores enemigos de la GPU, en base al cálculo de materiales. 9
Mecanismos de Eliminación Orientados a la GPU (Culling)
En la arquitectura Nanite, las operaciones de eliminación ("culling") no se realizan en base a objetos ("actor") en la CPU como en los motores tradicionales. Las preparaciones tradicionales de llamadas de dibujo ("draw calls") en el lado de la CPU se omiten por completo y el proceso de eliminación se delega directamente a los "compute shaders" dentro de la GPU. 10 En la fase de oclusión y eliminación (Occlusion Culling), Nanite utiliza una estructura llamada HZB (Hierarchical Z-Buffer), donde varios niveles de profundidad (mipmaps) en el espacio de pantalla se almacenan logarítmicamente. 9 El HZB compara el cuadro delimitador ("bounding box") de cada clúster de 128 triángulos con los datos de profundidad en el espacio de pantalla. 9 Si un clúster permanece detrás de otro objeto en la escena, se descarta inmediatamente del proceso de renderizado. Esta eliminación es tan precisa que, al realizarse por clústeres y no por objetos, mientras se descartan los clústeres pertenecientes únicamente a las partes de los árboles de un bosque masivo que quedan detrás de una montaña gigante, los clústeres de hojas que sobresalen de la cima de la montaña continúan procesándose. 8
Rutas de Rasterización: Dinámicas de Procesamiento de Software y Hardware
Para convertir los triángulos en píxeles de pantalla (rasterización), en lugar de utilizar una única unidad de procesamiento uniforme, Nanite utiliza dos rutas de rasterización (raster paths) independientes que se deciden dinámicamente según el tamaño del triángulo en la pantalla y las propiedades del material. 9 La optimización del rendimiento se basa en establecer un equilibrio perfecto entre estas dos rutas.
Rasterización por Software (Software Raster Path)
La rasterización por software es la ruta de procesamiento central más eficiente, rápida e innovadora de Nanite. 9 Esta ruta se activa cuando los triángulos son más pequeños que un píxel (subpíxel) o tienen exactamente el tamaño de un píxel en la pantalla. 9 En este escenario, Nanite omite por completo las unidades de dibujo de triángulos de hardware de la GPU y ejecuta el proceso a través de "Compute Shaders" (Sombreadores de Cómputo). Se logra escribir píxeles en el búfer de visibilidad a una velocidad extraordinaria mediante el uso de operaciones atómicas de 64 bits ("atomic interlocks"). Cuando el modo de visualización Raster Bins se activa desde la consola de desarrollo con el comando r.Nanite.Visualize.Advanced 1 o r.nanite.showmeshdrawevents 1, los clústeres que pasan por la rasterización por software se muestran en color azul. 9 En una escena bien optimizada, se debe buscar que la gran mayoría de la geometría sea de color azul. 9
Rasterización por Hardware (Hardware Raster Path)
La rasterización por hardware es el método de dibujo clásico de GPU que se activa cuando los triángulos son más grandes que el tamaño de un píxel en la pantalla o cuando se utilizan atributos de materiales especiales que la rasterización por software basada en cómputo de Nanite no puede procesar. 9 Esta ruta se muestra en color rojo en los modos de visualización. 9 Es normal que el sistema cambie a la rasterización por hardware, especialmente cuando la cámara se acerca a una pared gigante, ya que los triángulos se vuelven más grandes que los píxeles. 9 Sin embargo, si los objetos lejanos o los micropolígonos todavía se ven en rojo frente a la cámara, esto indica que se ha producido un "Hardware Fallback" (Reserva de Hardware) y constituye un problema grave de optimización. 9 La razón principal de las caídas indeseadas en la rasterización por hardware es el uso de materiales enmascarados ("masked"), transparentes o con desplazamientos de deformación complejos. 9
Raster Bins (Contenedores de Rasterización) y Gestión de Materiales
El corazón del rendimiento de Nanite no está tanto en la geometría en sí, sino en cómo los materiales aplicados sobre la geometría se distribuyen en contenedores virtuales llamados "Raster Bins". 9 Nanite toma todos los materiales estándar, opacos y que no contienen ningún desplazamiento de profundidad de píxel (PDO) o desplazamiento de posición mundial (WPO) en un solo contenedor Raster Bin gigante, y el sistema procesa este contenedor a una velocidad vertiginosa en un solo pase ("pass"). 9 Sin embargo, cuando se utilizan materiales en los objetos que se desplazan ("displacement"), se enmascaran ("masked/alpha test") o contienen un WPO denso utilizado para efectos de viento, estos objetos se eliminan de esta vía de paso rápido de Nanite, lo que provoca la creación de un Raster Bin diferente e independiente para cada tipo de material. 9
Clase de RendimientoTipo de material y propiedadEfecto Nanite y Estado de ProcesamientoRecomendación Estratégica para DesarrolladoresEl mejor (Best)Materiales puros que no contienen Opaque (Opaco), WPO, PDO ni desplazamiento (Displacement).Se mezclan dentro de un único Raster Bin. La rasterización por software funciona activamente, el coste de llamada de dibujo es cercano a cero.9Más del 90% de los diseños de entorno, edificios y superficies duras ("hard surface") del proyecto deben consistir definitivamente en este tipo.9Bueno (Good)Opaco (Opaque), pero con WPO (World Position Offset) mínimo.Como se utiliza WPO, los clústeres estáticos comienzan a calcularse por separado en la GPU. Dado que los cuadros delimitadores ("bounding boxes") cambiarán debido al movimiento, el proceso de eliminación ("culling") se vuelve más difícil.La distancia de movimiento del WPO debe limitarse estrictamente ("clamp") para evitar la corrupción del cuadro delimitador y la eliminación errónea.3 La deformación debe hornearse ("baked") si es estática.9Medio (Okay)Masked (Enmascarados/Con bordes transparentes, Alpha Cutout).Cae obligatoriamente en la rasterización por hardware (Hardware Raster Path). Como resultado de la evaluación continua de píxeles vacíos, genera un severo "Overdraw" (sobreescritura).Se utiliza en el modelado clásico de hojas o vallas, pero dado que merman el rendimiento, deben utilizarse con mucha moderación.8El peor (Worst)Materiales deformados complejos (WPO denso + PDO).Cada variación crea un Raster Bin separado. Aumenta los cambios de estado ("state changes"), llevando instantáneamente los tiempos de fotograma más allá de los límites del presupuesto.Debe cancelarse definitivamente en objetos a larga distancia (LOD fallback) o se debe optar por alternativas más modernas como Nanite Skinning que viene con UE 5.7.9
La formación de demasiados Raster Bins significa un aumento en los cambios de estado ("state changes") en la GPU y un aumento en las variaciones de llamadas de dibujo ("draw calls"), lo que ralentiza significativamente la GPU.9 En un proyecto con un objetivo de 60 FPS (16.66 ms por fotograma), es obligatorio mantener el proceso VisBuffer por debajo de 4 ms y el proceso BasePass por debajo de 3 ms; de lo contrario, no quedará tiempo para otros sistemas como el posprocesamiento, Lumen y la inteligencia artificial.7
Integración de Nanite: ¿Cómo se utiliza en los proyectos?
La integración de Nanite está diseñada para incorporarse a los flujos de trabajo de desarrollo de juegos en Unreal Engine existentes con la menor fricción posible. Al eliminar los procesos de creación manual de LOD de la vieja escuela o el horneado de mapas normales, este sistema optimiza el rendimiento por sí solo cuando se configura correctamente.1
Tipos de geometría y componentes compatibles
Para que una geometría pueda aprovechar las capacidades de Nanite, es necesario activar esta característica durante la fase de importación (import) o posteriormente a través del Editor de mallas estáticas (Static Mesh Editor).3 En las versiones actuales de Unreal Engine 5, los tipos de componentes (component) compatibles con Nanite se han ampliado considerablemente:
● Mallas estáticas (Static Meshes): Cualquier Static Mesh incluido en el proyecto se puede convertir marcando la opción "Enable Nanite Support" dentro del Editor. En escenas gigantescas con miles de objetos, toda la biblioteca se puede migrar al formato Nanite simultáneamente mediante la selección por lotes (batch-enable) a través del Content Browser.3 El público objetivo principal del sistema Nanite son estas mallas.
● Mallas esqueléticas (Skeletal Meshes): Mientras que en las primeras versiones de UE5 solo se admitían objetos estáticos, gracias a la compatibilidad con la API de Skeletal Mesh introducida en las versiones UE 5.3 y posteriores, los personajes, criaturas y vehículos que se deforman dinámicamente (con animación) también se pueden utilizar con Nanite.3 La mayor novedad para las mallas esqueléticas es que solo se genera una única llamada de dibujo (one draw call) para toda la malla. Los Skeletal Mesh de Nanite funcionan utilizando LOD de animación en lugar de los LOD de geometría clásicos.3
● Mallas spline (Spline Meshes) y terreno (Landscape): Nanite es compatible de forma nativa con Spline Meshes que cambian de forma a lo largo de curvas como carreteras, tuberías y paredes, así como con la topología de Landscape de mundo abierto grande (a través de Nanite Tessellation).3 Los pequeños detalles de desplazamiento (displacement) en los suelos se pueden lograr directamente a través de materiales, sin crear densidad poligonal y sin reducir el rendimiento.3
● Mallas instanciadas (Instanced Static Meshes - ISM / HISM): Los objetos con millones de copias (por ejemplo, rocas en un bosque gigantesco o ladrillos de edificios) se renderizan con una sola huella de memoria gracias al búfer de visibilidad de Nanite. Sin embargo, no hay que olvidar que el número máximo de instancias (instance) de Nanite que puede haber en la escena está limitado por hardware a 16 millones.3
Generación y función de la malla de reserva (Fallback Mesh)
Cuando se marca la casilla "Build Nanite" al crear datos de Nanite, el motor deriva automáticamente una geometría simplificada con un número de polígonos tradicional llamada "Fallback Mesh" (Malla de reserva) junto a la malla de alto detalle.13
La existencia de esta malla de reserva es de vital importancia: el sistema de rasterización centrado en la GPU de Nanite no se puede utilizar directamente para cálculos complejos de colisiones físicas (collision), mapas de iluminación precalculados con Lightmass (baked lighting) y, lo más importante, reflejos de trazado de rayos por hardware (hardware ray tracing / Lumen HWRT).13 Los sistemas lógicos del lado de la CPU del motor de juego necesitan estos datos de triángulos tradicionales. El nivel de detalle de la malla de reserva se puede controlar cambiando el parámetro "Fallback Relative Error" (Error relativo de reserva).3 A medida que se reduce la tasa de error, aumenta el número de polígonos de la malla de reserva, lo que garantiza que los reflejos de trazado de rayos por hardware (Lumen Hit Lighting) se calculen con mayor precisión, pero también aumenta el uso de memoria (VRAM) en la misma proporción.14
Nanite Foliage: Sistemas de vóxeles y ensamblaje (Assembly) con UE 5.6/5.7
En los motores de juego, las zonas forestales y la vegetación densa se consideraban tradicionalmente el punto más débil de Nanite durante años debido a las numerosas superficies de hojas transparentes (masked) superpuestas.15 El modelado de césped u hojas tradicional (alpha cards) creaba el problema del "Overdraw" (sobregrabación), que provocaba que los píxeles se evaluaran repetidamente unos sobre otros y caía en el rasterizador de hardware (HW Raster).8
Las versiones de Unreal Engine 5.6 y especialmente la 5.7 han resuelto este problema de raíz y con un cambio arquitectónico gracias al sistema "Nanite Foliage" 12:
Nanite Voxels (Vóxeles): Los triángulos de hojas complejos y generadores de overdraw de los árboles o la vegetación que se alejan de la cámara se convierten en vóxeles en la distancia configurando el ajuste "Voxelize" en el menú "Shape Preservation".17 Estos vóxeles, similares a los bloques de Minecraft, se procesan como píxeles volumétricos en lugar de triángulos, eliminando por completo la necesidad de transparencia (alpha) y evitando así el problema del overdraw a nivel de hardware.15 Cientos de miles de árboles distantes se procesan con un coste extremadamente bajo como vóxeles volumétricos del tamaño de un píxel de pantalla, mientras que al acercarse, la transición a micropollígonos de detalle completo se realiza sin problemas.15
Nanite Assemblies (Ensamblajes): Cuando los árboles gigantescos se modelan en alta resolución, alcanzan tamaños increíbles en el disco y en la memoria. Gracias a la función Nanite Assemblies, cada rama, hoja y tronco de un árbol no se lee como una malla estática gigantesca independiente, sino como un todo jerárquico (assembly) a través del importador de USD (Universal Scene Description).12 Gracias a los esquemas NaniteAssemblyRootAPI preparados en programas como Houdini Solaris, miles de hojas son en realidad la versión llamada de la misma malla de hoja pequeña mediante el método de instanciación (instancing).19 Esta estructura reduce drásticamente la huella de memoria.
Nanite Skinning: Las animaciones de viento tradicionales basadas en WPO (World Position Offset) cambiaban la caja delimitadora de cada cúmulo en cada fotograma, lo que requería un recálculo continuo (culling invalidation) en la CPU/GPU.15 Con Nanite Skinning, introducido en UE 5.7, los árboles se importan como una malla esquelética (skeletal mesh); los efectos de viento físicos y procedurales se calculan a través de los huesos (bones) utilizando el complemento "Dynamic Wind".12 De este modo, Nanite ofrece interacciones de viento mucho más orgánicas y coherentes sin sacrificar el rendimiento de los contenedores de rasterización (Raster Bins). La nueva biblioteca Quixel Megaplants y el Editor de Vegetación Procedural (PVE) utilizan estas tecnologías de forma totalmente integrada para garantizar que los objetivos de 60 FPS se alcancen con facilidad.15
Procesos de optimización: ¿A qué se debe prestar atención?
Aunque Nanite está diseñado para mejorar el rendimiento, la promesa de "polígonos ilimitados" no es una varita mágica. Es un sistema complejo que puede poner en serio peligro los tiempos de fotograma (frame) si se utiliza incorrectamente y no se respetan los límites del hardware.11
Translucidez (Translucency), enmascaramiento y el problema del Overdraw
En la optimización de juegos tradicional (UE4 y anteriores), era un enfoque estándar simular un objeto detallado en superficies de pocos polígonos aplicándoles máscaras transparentes (alpha texture / masked material).8 Sin embargo, en la arquitectura de Nanite, este enfoque es completamente erróneo y tiene resultados catastróficos.8
Nanite necesita pases de hardware adicionales para omitir los píxeles transparentes (vacíos) al calcular el búfer de visibilidad. Cuando los materiales enmascarados se disponen uno tras otro (por ejemplo, una valla metálica o las hojas de un árbol), el sistema se ve obligado a leer y procesar la profundidad y la transparencia del mismo píxel decenas de veces, lo que se conoce como "Overdraw".10
Regla crítica: En el sistema Nanite, "la geometría es muy barata, pero la transparencia es muy cara". Al crear objetos con agujeros como hojas, vallas o redes, en lugar de utilizar una textura enmascarada (masked material), la forma debe modelarse completamente (fully modeled) con cientos de miles de polígonos adicionales si es necesario, y el material debe configurarse estrictamente como "Opaque".8 Un árbol modelado por completo se renderizará mucho más rápido que una superficie plana enmascarada (plane).8
Integración de Mapas de Sombras Virtuales (Virtual Shadow Maps - VSM)
Los mapas de sombras tradicionales (Cascaded Shadow Maps - CSM) no pueden adaptarse al masivo nivel de detalle a nivel de micropollígono que ofrecen los objetos Nanite. Diseñados específicamente para su uso con Nanite, los Mapas de Sombras Virtuales (Virtual Shadow Maps - VSM) ofrecen sombras nítidas al hacer coincidir dinámicamente la resolución de las sombras con los píxeles de la pantalla.23
Por su propia naturaleza, los VSM requieren una gran cantidad de memoria VRAM. Si un objeto que proyecta sombras se mueve constantemente (por ejemplo, hojas que oscilan con WPO), la caché de sombras de los VSM (shadow cache) se invalida en cada fotograma (invalidated) y el mapa de sombras se calcula desde cero, lo que provoca una caída importante de los FPS.22 Por lo tanto, mientras que las escenas estáticas o los edificios funcionan perfectamente con el dúo Nanite y VSM, en las zonas boscosas con mucho movimiento se deben introducir restricciones de WPO o se debe evaluar el cambio a mapas de sombras clásicos (Shadow Maps) en función de las pruebas de rendimiento.25
Creación de perfiles (Profiling) y comandos de lectura de rendimiento
Para encontrar la causa raíz de los problemas de optimización y determinar si el cuello de botella proviene de la unidad central de procesamiento (CPU) o de la tarjeta gráfica (GPU), es fundamental leer regularmente los comandos de perfil (stat) integrados en UE5 desde el principio del proyecto (principio de optimización temprana).26
Los comandos de perfil y las herramientas de visualización que los desarrolladores deben utilizar regularmente son los siguientes 28:
Comando de perfil / ModoDescripción y Propósito de UsoAcción del desarrolladorstat unitDetección básica de cuellos de botella. Muestra el tiempo total en pantalla desglosado en milisegundos (ms) como "Frame" (Tiempo general), "Game" (Bucle de juego de la CPU), "Draw" (Preparación de renderizado de la CPU) o "GPU".28Si el tiempo de GPU supera los 16.66 ms, se debe orientar hacia restricciones gráficas; si se supera el tiempo de Game, hacia la optimización de la inteligencia artificial o los ticks de Blueprint.
Comando / HerramientaFunción y DescripciónAcción de optimizaciónstat gpu o stat scenerenderingEnumera las cargas de renderizado específicas dentro de la GPU. Detalla cuánto tiempo tardan Nanite BasePass, Lumen, las sombras (Shadow Depths) y las cargas de Post Process.Si Nanite VisBuffer supera los 4 ms o BasePass supera los 3 ms, se debe comprobar Raster Bins o el Overdraw.r.nanite.showmeshdrawevents 1Examina jerárquicamente dentro del generador de perfiles de GPU (Ctrl+Shift+,) cuánto tiempo dedica cada material y objeto Nanite específico.Se utiliza para detectar y aislar materiales WPO costosos o NaniteStatsDibuja una interfaz directamente en la esquina de la pantalla con la tecnología "ShaderPrint". Filtra en tiempo directos si las sombras virtuales o el campo de visión principal (Primary View) generan la carga de dibujo en Nanite.Se introducen parámetros en la consola (primary, VirtualShadowMaps) para determinar la carga de los pases activos.View Mode > Nanite Visualization > OverdrawColorea las áreas densas de la pantalla donde se superponen los píxeles en un espectro de azul (bueno), naranja y rojo (malo).Se identifican las áreas con una alta concentración de materiales transparentes y se procede a una revisión de modelado completo (opaque).
Relación entre la arquitectura de E/S de PlayStation 5 (PS5) y la transmisión (streaming) de Nanite
Al desarrollar juegos para PlayStation 5, el único factor que lleva el potencial de Nanite desde los límites teóricos hasta la cúspide del rendimiento en el mundo real es la revolucionaria arquitectura de almacenamiento SSD y descompresión por hardware de la consola. Los clústeres de 128 triángulos de Nanite están diseñados bajo el principio de carga bajo demanda (páginas de streaming bajo demanda) y la jerarquía de E/S (entrada/salida) de PS5 se encuentra en perfecta armonía con este diseño.
Compresión por hardware Kraken e integración de Oodle Texture
En los sistemas de PC tradicionales y consolas de anterior generación (PS4, Xbox One), los datos comprimidos leídos desde el disco (mediante algoritmos de propósito general como ZLIB) deben transferirse primero a la RAM y luego ser descomprimidos por el procesador central (CPU). Cuando los tamaños masivos de los clústeres de Nanite, compuestos por miles de millones de polígonos, exigen un flujo de datos nuevos de varios gigabytes por segundo (GB/s) con cada movimiento de la cámara, este método de descompresión por software provoca que la CPU se bloquee en PCs y consolas antiguas, impidiendo que procese las mecánicas de juego (inteligencia artificial, físicas, etc.).
Al diseñar el hardware de PS5, Sony no se limitó a seguir los estándares; integró un chip decodificador por hardware especializado a nivel de silicio (bloque de descompresión por hardware) en el complejo de E/S para poder descomprimir el algoritmo de compresión Oodle Kraken, desarrollado por RAD Game Tools. En comparación con el formato ZLIB de la generación anterior, Kraken puede reducir los datos de forma totalmente sin pérdida (lossless) en un 29 % adicional y es entre 3 y 4 veces más eficiente en su velocidad de descompresión.
Cuando se utiliza junto con el formato sin pérdida "Oodle Texture" (junto con optimizaciones de compresión de texturas como BC7Prep), el chip Kraken de PS5 multiplica la velocidad de lectura nativa de 5.5 GB/s del SSD para ofrecer una transferencia de datos a velocidades de ancho de banda increíbles que promedian entre 8 y 9 GB por segundo, y alcanzan entre 17 y 22 GB por segundo en su punto máximo (peak).
Superación del cuello de botella de la CPU y multiplicador de ancho de banda
El significado de esta arquitectura de E/S para Nanite es muy profundo. La siguiente tabla resume cuánto ahorro de CPU proporciona la tecnología de compresión de PS5 en comparación con la competencia y las generaciones anteriores:
Métrica de hardware y algoritmo de compresiónPS4 / Generación anteriorXbox Series XPlayStation 5Algoritmo de compresión básicoZLIB (Enfoque por software)BCPack (Variante de HW de ZLIB)Oodle Kraken + Oodle Texture (HW personalizado)Velocidad de salida máxima (Peak Bandwidth)~100-200 MB/s~6 GB/s (efectivo con SFS)~22 GB/sVelocidad de salida promedio (Average Bandwidth)< 100 MB/s~4.8 GB/s8-9 GB/s (17 GB/s con Oodle)Ahorro de rendimiento equivalente en procesador (CPU)Sobrecarga totalmente a la CPUEquivalente a ~5 núcleos Zen 2Equivalente a ~9 núcleos Zen 2
Esta tabla demuestra claramente que el complejo de E/S de PS5 asume por sí solo el esfuerzo que requeriría que exactamente 9 núcleos de procesador Zen 2 independientes abrieran los datos desde el SSD en un ordenador tradicional.
Cuando Nanite solicita decenas de miles de nuevos clústeres (páginas de streaming) desde el disco en cada fotograma (dentro de los 16 ms) según el nuevo punto de vista de la cámara, estos datos leídos desde el SSD se alimentan directamente a los pools de RAM y GPU a través del chip Kraken por hardware, omitiendo por completo a la CPU. Los desarrolladores de juegos pueden utilizar la filosofía de Nanite de "Virtual Texturing for Geometry" (Texturizado virtual para geometría) al máximo sin temor a que los datos "no lleguen a tiempo" (pop-in). Al ver este potencial masivo, los ingenieros de Epic Games reescribieron desde cero y exclusivamente para PS5 los subsistemas principales de carga (core I/O subsystems) de Unreal Engine 5 para esta arquitectura de E/S única de PS5.
Gestión de VRAM y optimización del Streaming Pool
PlayStation 5 cuenta con una memoria GDDR6 unificada y superrápida con una capacidad de 16 GB. Sin embargo, a diferencia de las arquitecturas de PC, los límites de memoria en las consolas son estrictos y tienen una estructura inflexible (memoria fija); los desbordamientos de memoria virtual no se toleran y provocan el bloqueo directo del sistema (OOM - Out of Memory).
Los pools de memoria (streaming pools) utilizados por Nanite crecen de forma geométrica según la resolución de pantalla. Nanite utiliza un búfer de visibilidad directamente proporcional al tamaño de pantalla para almacenar los identificadores de los triángulos. Cuando la resolución pasa de 1080p a 4K (dado que el número de píxeles se multiplica por cuatro), el requisito de VRAM del Visibility Buffer también se multiplica directamente por 4.
Para garantizar la optimización en los proyectos de PS5 y gestionar la VRAM, el tamaño del "Nanite Streaming Pool" debe ser limitado por el desarrollador. Mientras que el tamaño predeterminado del pool ronda los 512 MB en proyectos vacíos, en un proyecto AAA con una alta carga de Nanite, se debe configurar el siguiente parámetro en la línea de comandos o en los archivos .ini (por ejemplo, dentro de DefaultEngine.ini en ``):
r.Nanite.Streaming.StreamingPoolSize = 2048
(Alrededor de 2000-3000 MB, dependiendo del peso de la escena y de otros sistemas). Si este presupuesto del pool se mantiene demasiado ajustado, los clústeres de alto detalle de los objetos lejanos no se podrán cargar a tiempo y Nanite recurrirá a los modelos alternativos (fallback); si se mantiene demasiado amplio, no quedará RAM para las cachés de superficie de Lumen (Surface Cache), las texturas de alta resolución y el sistema operativo. Con UE 5.7, los desarrolladores verán que se activa un sistema de advertencia en situaciones de StreamingPoolSize que superen los límites de la consola (generalmente un exceso de 2-4 GB).
Requisitos de desarrollo y configuraciones de consola para PlayStation 5
Aunque el proceso de desarrollo para la plataforma PS5 con Unreal Engine 5 se ha vuelto bastante refinado como resultado del trabajo conjunto de Epic Games y Sony, es obligatorio cumplir con el kit de desarrollo de software (SDK) específico y las configuraciones del sistema para que el proyecto se pueda compilar y ejecutar a una velocidad óptima.
Versiones de SDK y flags del compilador
Los requisitos de hardware y de la biblioteca de software que se deben tener en cuenta al compilar (build) en el hardware de PS5 con las versiones actuales 5.6 y 5.7 de Unreal Engine son los siguientes:
Versiones de SDK y del sistema compatibles: El requisito básico para el entorno de desarrollo de PS5 se ha establecido como "Prospero SDK 11.00.00.40" (o SDK 12 para sistemas de almacenamiento avanzados) y "Software de sistema 11.00.00.43". Las discrepancias de versión en la configuración del proyecto (al trabajar con complementos de terceros como IntlNetwork SDK o Interhaptics) son motivo de bloqueos.
Configuración del compilador: Durante los procesos de compilación, además de la propia cadena de herramientas (toolchain) de Sony, se utiliza clang-cl. El código fuente ahora se compila obligatoriamente con el flag -fhonor-nans para evitar comportamientos indefinidos (undefined behavior) y errores de tipo NaN (Not a Number) en Clang 19. Además, el parámetro -ffp-contract=off, que causaba problemas multiplataforma en el pasado, se ha eliminado del compilador de PS5 debido a que entra en conflicto con -ffast-math.
Transición de la biblioteca estándar (Stdlib): Junto con UE 5.7, se ha añadido soporte para la biblioteca estándar de C++20 (stdlib v2) para PS5. Se recomienda encarecidamente a los desarrolladores que asignen StandardLibVersion = 'v2' a través de los archivos de configuración UEBuildPS5.cs o BuildConfiguration.xml para garantizar la compatibilidad a futuro y un mayor rendimiento.
Ajustes de optimización del sistema: Se ha introducido un nuevo sistema de caché LRU (Least Recently Used) en la arquitectura AgcRHI para evitar la acumulación de estados de muestreador (sampler) en la GPU. Este límite se ha configurado por defecto como r.Agc.MaxSamplerStates 4096.
Perfiles de escalabilidad para el objetivo de 60 FPS
UE5 está configurado por defecto para apuntar a 30 FPS (33.3ms por fotograma) en el nivel de calidad "Epic" en las consolas PS5 y Xbox Series X. Apuntar a 60 FPS (16.6ms por fotograma) en juegos modernos bajo la carga de trazado de rayos y una enorme cantidad de polígonos requiere hacer sacrificios conscientes en la resolución de renderizado y la calidad de Nanite y Lumen.
Los estudios que deseen lanzar un juego en PS5 con una experiencia fluida de 60 FPS deben reducir la calidad de los sistemas de iluminación global (GI) y reflejos de Lumen al nivel de escala "High" (Alto) en la configuración DeviceProfiles.ini a nivel de hardware del motor, adaptándola así al presupuesto de 60 FPS. En este perfil, el juego se renderiza internamente (resolución interna) a alrededor de 1080p o 1440p antes de ser reescalado (upscale) con Temporal Super Resolution (TSR).
El siguiente bloque de configuración debe añadirse directamente al archivo [ProjectName]\Platforms\PS5\Config\PS5DeviceProfiles.ini dentro del directorio del juego:
; Set Lumen GI and reflection quality to High, targeting 60 fps console budget
+CVars=sg.GlobalIlluminationQuality=2
+CVars=sg.ReflectionQuality=2
Esta configuración lleva el peso computacional de Lumen a los límites de la consola, dejando margen de maniobra dentro de los 16.66ms por fotograma para los millones de polígonos procesados con Nanite. Además, para mejorar el rendimiento de Nanite, es importante mantener activas las capacidades de detección de geometría fina (Thin Geometry detection) de TSR.
Mejoras específicas para PS5 en la sincronización de Lumen y Nanite
Por sí solo, el sistema Nanite es responsable únicamente del dibujo geométrico estático; sin embargo, lo que determina la calidad visual del juego es Lumen, el sistema de iluminación global (Global Illumination) que rebota en las superficies de Nanite y genera sombras fotorrealistas. Cuando ambos sistemas se combinan, el hardware de PS5 se exprime hasta sus límites.
Lumen tiene dos modos de funcionamiento: Trazado de rayos por software (SWRT), que utiliza campos de distancia (Distance Fields), y Trazado de rayos por hardware (HWRT), que calcula directamente los triángulos. Nanite alimenta la compleja geometría que posee al mecanismo HWRT a través de las mallas de reserva (Fallback Meshes) mencionadas anteriormente. Mientras que en las versiones de motores de generaciones anteriores se recomendaba obligatoriamente SWRT para alcanzar los 60 FPS, en las versiones 5.6 y 5.7 de Unreal Engine se han realizado mejoras profundas en HWRT que aligeran el hardware de las consolas (especialmente los núcleos de trazado de rayos basados en AMD RDNA2 de PS5):
Si el desarrollador choca contra los límites de renderizado de PS5 a pesar de las altas optimizaciones de Nanite en su escena, debe medir el costo de HWRT con el perfil "stat gpu" y, si es necesario, probar el escenario de volver de Virtual Shadow Maps (VSM) a Shadow Maps clásicos en las luces direccionales en las primeras etapas del proyecto (optimizar pronto / optimize early) para abaratar los cálculos de sombras. 25
Conclusión estratégica y recomendaciones para desarrolladores
En consonancia con los análisis detallados realizados, la arquitectura Nanite de Unreal Engine 5 crea una verdadera revolución en la industria de los gráficos por ordenador al combinar las capacidades modernas de los compute shaders de la GPU, la integración de trazado de rayos por hardware y los algoritmos de compresión de datos de nueva generación. Esta tecnología, que elimina los recuentos de polígonos y los cuellos de botella de llamadas de dibujo (draw calls) para que dejen de ser un obstáculo, trae consigo diferentes flujos de trabajo (Assemblies, Voxelization) y disciplinas estrictas de presupuesto de memoria (Streaming Pools).
Los hallazgos estratégicos más fundamentales que los artistas técnicos (Technical Artists) y programadores de motores (Engine Programmers) que desarrollarán juegos en la plataforma PlayStation 5 deben tener en cuenta son los siguientes:
1. Utilizar la ventaja de E/S de forma correcta y al límite: El exclusivo descompresor por hardware Kraken de PS5 proporciona un ancho de banda de E/S increíble a través del SSD. Es más adecuado para el flujo natural del sistema que los desarrolladores se alejen de las estrategias manuales de LOD de generaciones anteriores que restringen el streaming de Nanite y se orienten directamente hacia el uso de la malla original (source mesh) con calidad de cine.
2. Evitar los costos de transparencia y sobreescritura (Overdraw): Las animaciones basadas en WPO (World Position Offset) y el uso de Alpha Mask/Cutout, que son el talón de Aquiles de Nanite, son destructivas para el rendimiento, especialmente en la vegetación. Las funciones Nanite Voxels, Nanite Assemblies y Nanite Skinning introducidas con UE 5.6 y 5.7 deben adoptarse como el método principal en lugar del modelado de césped tradicional en los objetivos de mundos abiertos a 60 FPS en PS5. En lugar de la optimización de modelos, es obligatorio orientarse hacia geometrías "Oopaque" (Opacas) de alto poligonaje pero fluidas.
3. Realizar una presupuestación precisa de la VRAM: La estructura de memoria fija de PS5 puede ser consumida rápidamente por los identificadores de visibilidad de Nanite (Visibility Buffer) y las cachés de superficie de Lumen. Los límites de StreamingPoolSize deben establecerse meticulosamente y, en lugar de una escala de renderizado nativo en 4K, se deben utilizar objetivos de resolución interna de 1080p a 1440p acompañados de Temporal Super Resolution (TSR) para sintetizar una alta calidad visual con una velocidad de fotogramas estable.
4. Análisis de perfil regular y temprano (Optimize Early): Las herramientas de perfilado stat gpu, stat unit y NaniteStats deben seguirse de manera activa sin esperar al final del proceso de desarrollo. Se deben detectar y fusionar las configuraciones de materiales que crean Raster Bins problemáticos para reducir al mínimo el cambio de estado (state change) entre la CPU y la GPU.
Nanite no es una varita mágica que aumenta el rendimiento; por el contrario, es un ecosistema muy potente que no restringe la visión cuando sus capacidades se utilizan correctamente, pero que choca severamente contra las barreras del hardware cuando no se siguen sus reglas (por ejemplo, mediante el uso excesivo de materiales enmascarados). Cuando la arquitectura de E/S dedicada del hardware de PS5 y las innovaciones de renderizado de Unreal Engine 5 trabajan de forma sincronizada, los límites visuales y volumétricos de los medios interactivos se expanden de una manera sin precedentes.
*Nota informativa: Las imágenes han sido generadas por Google Gemini.