Optimización de juegos 3D para móviles en Unity 6 en 2026: DOTS, GPU Resident Drawer y nuevos pipelines híbridos

Guía práctica completa para lograr 60–120 FPS estables en proyectos móviles 3D exigentes basados en Unity 6 y URP. Analizamos los pipelines gráficos modernos, la transferencia de procesamiento a la GPU mediante GPU Resident Drawer, la arquitectura DOTS y los requisitos técnicos vigentes de la App Store y Google Play en 2026.

El desarrollo de juegos 3D de alto rendimiento en Unity 6 en 2026 requiere una comprensión clara de los cambios en el stack de hardware móvil ocurridos en los últimos años. La era de la API gráfica obsoleta OpenGL ES 3.x ha llegado a su fin definitivo: Google Play y Apple App Store han consolidado a Vulkan 1.3 y Metal 3 como el estándar indiscutible para los gráficos modernos. Intentar mantener pipelines de renderizado obsoletos en Unity 6 priva al proyecto del acceso a características arquitectónicas críticas, desde la gestión directa de la sincronización de búferes hasta el dibujado de comandos acelerado por hardware en el GPU.

Para el diseño de perfiles gráficos objetivo y sistemas de escalado en 2026-2027, se destacan tres categorías clave de hardware de dispositivos:

• Low-End (Perfil mínimo / Mercado masivo 30 FPS): Dispositivos basados en chipsets de nivel Arm Mali-G610/G710, Snapdragon serie 6 y procesadores Exynos básicos. Equipados con 4-6 GB de RAM LPDDR4X/LPDDR5. API gráfica: Vulkan 1.3 sin soporte para capacidades avanzadas de vinculación de recursos (bindless). Principal limitación: un ancho de banda de memoria estrecho (hasta 25-30 GB/s) y un alto riesgo de fallos de caché (cache misses) al utilizar shaders PBR pesados.
• Mid-Tier (Perfil objetivo 60 FPS): Dispositivos de segmento medio-alto con Snapdragon serie 7 (incluidos Gen 4/5), Dimensity 8300/8400 y Apple A16/A17. Se caracterizan por 8-12 GB de LPDDR5X y soporte completo para Vulkan 1.3 (con `VK_EXT_descriptor_indexing` y `VK_KHR_dynamic_rendering` obligatorios). Este segmento es capaz de procesar con solvencia pipelines híbridos de Unity 6 mediante GPU Resident Drawer y heurísticas complejas de culling.
• High-End / Flagship (High-FPS, 90-120 FPS, Ray Tracing por hardware): Soluciones insignia basadas en Apple A19 Pro / M5, Qualcomm Snapdragon 8 Elite / Gen 5 y MediaTek Dimensity 9500+. Equipados con 12-16 GB de memoria ultrarrápida LPDDR5X/LPDDR6. Admiten Mesh Shading por hardware, trazado de rayos en tiempo real y bloques NPU integrados para reescalado por red neuronal (MetalFX Spatial/Temporal, FidelityFX Super Resolution 3.1 Mobile).

El factor clave al optimizar para GPU móviles sigue siendo la especificación de la arquitectura TBDR (Tile-Based Deferred Rendering), utilizada por chips Arm Immortalis, Qualcomm Adreno y Apple GPU. A diferencia de las arquitecturas de renderizado directo de escritorio (Immediate Mode), los chips TBDR dividen la pantalla en pequeños tiles o mosaicos (generalmente de 16x16 o 32x32 píxeles), procesando la geometría y los fragmentos dentro de una memoria rápida integrada en el chip (On-Chip SRAM/Tile Memory).

La regla principal de optimización para TBDR en 2026 es evitar el estrangulamiento del ancho de banda de memoria (bandwidth throttling). El envío de datos intermedios desde la memoria de tiles hacia la memoria LPDDR principal y viceversa sobrecalienta críticamente el dispositivo. Entre los principales cuellos de botella arquitectónicos de TBDR se encuentra la interrupción del pase de tiles:

• Render Passes no optimizados: El uso de post-efectos no agrupados y cambios frecuentes de búferes de fotogramas (Render Targets) sin especificar explícitamente `StoreAction.DontCare` o `LoadAction.Clear` obligan al GPU a volcar el contenido del tile en la RAM global, destruyendo el rendimiento.
• Profundidad excesiva de Alpha Blending: El renderizado de múltiples capas semitransparentes (partículas, vegetación densa, UI) genera una fuerte carga en el recalculado de fragmentos dentro del tile (Overdraw), provocando caídas en la tasa de fotogramas.
• Depth Pre-pass ineficiente: En arquitecturas TBDR, el bloque de hardware HSR (Hidden Surface Removal, por ejemplo en Apple GPU o Early-Z en Adreno) funciona de forma automática a nivel de tile. El uso innecesario de un pase manual de profundidad (Depth Pre-pass) crea una carga excesiva en la etapa de vértices del pipeline e incrementa el tráfico de geometría.

Una amenaza adicional en 2026 sigue siendo el Thermal Throttling (estrangulamiento térmico). Los procesos de fabricación modernos de 2 nm y 3 nm permiten que los SoC móviles muestren un rendimiento pico fenomenal; sin embargo, sin un control estricto del TDP (Thermal Design Power), el dispositivo se sobrecalienta en los primeros 3 a 5 minutos de juego. La caída de frecuencia del GPU durante el throttling puede alcanzar del 40 % al 50 %. El objetivo del pipeline de optimización moderno en Unity 6 no es solo mostrar 60 FPS estables en un teléfono frío durante un benchmark, sino mantener un Frame Pacing uniforme y un consumo de energía mínimo durante una sesión de juego de 45 minutos.

La transición de Unity 6 a la nueva API Render Graph en URP y la implementación de GPU Resident Drawer se diseñaron específicamente atendiendo a las particularidades del hardware de 2026-2027. Estas tecnologías permiten reducir de forma drástica la sobrecarga del CPU al preparar los comandos de renderizado (Draw Calls), ofreciendo la posibilidad de delegar la gestión de recursos directamente al GPU y aprovechar al máximo la memoria de tiles del procesador con un uso mínimo del bus de memoria LPDDR.

La evolución de Universal Render Pipeline (URP) en la arquitectura de Unity 6 marca la transición definitiva de los modelos de renderizado imperativos a un pipeline basado en grafos totalmente declarativo. En la práctica actual del desarrollo móvil, la optimización no se logra tanto reduciendo el número de polígonos, sino mediante una gestión eficiente del ancho de banda de memoria (Memory Bandwidth) y la prevención del estrangulamiento térmico (Thermal Throttling) en los SoC móviles. Las GPU móviles con arquitectura TBDR (Tile-Based Deferred Rendering), como ARM Mali, Qualcomm Adreno y las soluciones de Apple Silicon, son extremadamente sensibles a las operaciones innecesarias de lectura/escritura entre la memoria local del tile (SRAM) y la memoria del sistema (DRAM). La principal respuesta arquitectónica de Unity 6 a estas limitaciones es el mecanismo Render Graph, el cual ha sido rediseñado y se ha vuelto obligatorio.

En las generaciones anteriores del motor, los ingenieros controlaban manualmente las texturas temporales a través de llamadas a `RenderTexture.GetTemporary`, lo que provocaba con frecuencia fragmentación de la VRAM, llamadas poco evidentes a `CopyTexture` y operaciones innecesarias de `Load/Store` del framebuffer en las GPU móviles. En Unity 6, la Render Graph API construye automáticamente un grafo acíclico dirigido (DAG) de todos los pases de renderizado incluso antes de enviar las órdenes a la API gráfica de bajo nivel (Vulkan 1.3 o Metal 3). Esto permite al motor realizar una optimización estática y dinámica integral del fotograma.

Principales novedades arquitectónicas de URP en Unity 6 que impactan directamente en el rendimiento de los proyectos 3D móviles:

• Gestión automática de recursos temporales (Transient Resources) y Memory Aliasing: Los búferes de fotograma (búferes de profundidad, mapas de sombras, attachments de MSAA, texturas HDR intermedias) se asignan estrictamente durante la ejecución de un nodo específico del grafo. El mecanismo de Memory Aliasing superpone físicamente los búferes que no se traslapan en el tiempo sobre el mismo rango de direcciones de memoria de la GPU, reduciendo la huella general de VRAM del juego.
• Fusión automática de pases (Pass Merging) y Subpasses nativos: Render Graph analiza los pases adyacentes y los traduce automáticamente a Vulkan Subpasses nativos o Metal Render Command Encoders. Los datos (como normales y profundidad) se transfieren entre pases directamente dentro de la rápida Tile Memory (SRAM) del procesador sin volcar a DRAM, reduciendo el consumo energético del chip durante el renderizado hasta en un 35–40 %.
• Zero-Allocation a nivel de C# API: La ejecución de Render Graph en Unity 6 está completamente libre de asignaciones en el heap administrado (Managed Heap) durante la construcción y validación del fotograma. Los pases y contextos de llamada utilizan estructuras de datos rápidas basadas en `NativeArray` y búferes de comandos de bajo nivel especializados, reduciendo a cero el trabajo del recolector de basura (GC) durante el renderizado.
• Integración directa de Compute Shaders: Ahora es posible integrar sin problemas cómputos en la GPU (culling en GPU, simulación de partículas, generación procedimental) en el grafo general del fotograma con una colocación automática de barreras de memoria (Execution & Memory Barriers) por parte de Unity.

Una parte fundamental de la arquitectura actualizada es la herramienta Frame Debugger. Esta no solo muestra una cadena de `DrawCall`, sino la topología real de Render Graph: límites físicos de RenderPass/Subpass, alias de memoria y puntos de volcado de tiles no deseados (Tile Flush). Esto permite detectar errores arquitectónicos (como un volcado de tile provocado accidentalmente por la lectura a destiempo de una textura desde un script) desde la fase de profiling en el editor.

La arquitectura de URP en Unity 6 desplaza el enfoque de la optimización móvil del simple recorte en la cantidad de llamadas de dibujo (draw calls) al diseño de un grafo de fotograma correcto. Para los juegos 3D móviles modernos, una configuración adecuada de Render Graph es el cimiento para alcanzar 60 o 120 FPS estables sin agotar rápidamente la batería ni sobrecalentar el dispositivo.

Durante muchos años, el principal cuello de botella en la optimización de juegos 3D para móviles fue el procesamiento en la CPU. En las arquitecturas de renderizado basado en tiles (TBDR), características de los chipsets móviles modernos como Snapdragon, Dimensity y las series A de Apple, el procesamiento gráfico es capaz de procesar la geometría con gran eficiencia; sin embargo, la preparación de la escena en la CPU genera un cuello de botella crítico. En cada fotograma, la CPU debe realizar el Frustum Culling, ordenar los objetos transparentes u opacos, generar las listas de llamadas de renderizado (draw calls) y transferir las matrices de transformación a la VRAM de la GPU. En Unity 6, la tecnología GPU Resident Drawer (GRD), integrada en el Universal Render Pipeline (URP) actualizado, cambia por completo este paradigma al trasladar el procesamiento de geometría y la preparación de las llamadas de renderizado íntegramente al chip gráfico.

El funcionamiento de GPU Resident Drawer se basa en la evolución de la API de bajo nivel BatchRendererGroup (BRG). En los pipelines tradicionales (incluyendo el SRP Batcher clásico), la CPU continuaba iterando sobre cada objeto registrado, incluso si no cambiaba su posición en el espacio, para confirmar su visibilidad y actualizar los búferes Uniform. GPU Resident Drawer traslada las matrices de transformación, los datos de materiales y de instancias a un almacenamiento persistente en la memoria de video: el denominado GPU Resident Data Buffer (implementado mediante StructuredBuffers o SSBO). Ahora, las transformaciones se cargan en la VRAM una sola vez al generar o instanciar un objeto, y cuando cambian, se actualizan de forma puntual mediante Compute Shaders o comandos de escritura asíncronos.

El principal avance de GRD en 2026 es la transferencia completa de la etapa de GPU Frustum & Occlusion Culling a los Compute Shaders. El proceso de renderizado de fotogramas utilizando GPU Resident Drawer se basa en el siguiente algoritmo de alto rendimiento:

• Persistencia de datos: La escena almacena la geometría, los niveles de LOD y los datos de materiales directamente en la memoria de video como estructuras de datos compactas, eliminando la transferencia host-to-device en cada fotograma.
• GPU-Culling: El Compute Shader se ejecuta antes de la fase de renderizado de la geometría. Comprueba en paralelo miles de Bounding Boxes de objetos con respecto a la pirámide de visión de la cámara (Frustum) y, si el Hierarchical Z-Buffer (Hi-Z) está activado, descarta los objetos ocluidos (Occlusion).
• Formación de Indirect Buffers: En lugar de transmitir listas de Draw Calls desde la CPU, el Compute Shader genera de manera autónoma los artefactos de comandos en la memoria de la GPU (Count y Offset), preparando los argumentos para las llamadas de renderizado indirecto.
• Ejecución de Indirect Drawing: La GPU ejecuta los comandos mediante instrucciones de hardware como vkCmdDrawIndexedIndirect en Vulkan 1.3/1.4 o drawIndexedPrimitives en Metal 3. El ensamblado del fotograma se realiza sin ninguna intervención del hilo principal (Main Thread) ni del hilo de renderizado (Render Thread) de la CPU.

En las arquitecturas gráficas móviles (ARM Mali-G720/G820, series Qualcomm Adreno 750/800, Apple Graphics), esto proporciona una reducción fundamental del consumo de energía y del throttling térmico. Anteriormente, al renderizar escenarios abiertos complejos con decenas de miles de elementos del entorno (vegetación, rocas, props menores, edificios), el CPU Render Thread tardaba entre 6 y 12 milisegundos solo en preparar las llamadas. Con el uso de GPU Resident Drawer, la carga en el hilo de renderizado de la CPU se reduce a una fracción de milisegundo (a menudo entre ~0,2 y 0,5 ms), ya que la CPU solo transmite a la GPU una única llamada general de control para la fase de renderizado.

Para aprovechar todo el potencial de GPU Resident Drawer en Unity 6, los desarrolladores deben cumplir ciertos requisitos en cuanto a shaders y datos estructurales. Los materiales gráficos deben ser compatibles con DOTS Instancing. En Shader Graph, esto se configura activando la casilla Enable DOTS Instancing en las propiedades de Target Settings. Si utilizas shaders HLSL escritos a mano, se requiere la implementación de las macros UNITY_DOTS_INSTANCING_START y UNITY_DOTS_INSTANCED_PROP, las cuales redirigen correctamente las referencias a las matrices a través de búferes de direcciones de bytes (ByteAddressBuffer).

Un análisis comparativo del rendimiento al renderizar un escenario móvil pesado (50 000 objetos estáticos y semidinámicos) muestra los siguientes resultados:

• SRP Batcher (enfoque clásico): CPU Render Thread: 8,4 ms | Draw Calls: ~4 200 | Throttling limitado por CPU después de 4 minutos de juego.
• GPU Resident Drawer (Unity 6 URP): CPU Render Thread: 0,3 ms | Instanced Draw Calls: ~18 (agrupadas por tipo de material) | 60 FPS estables limitados por GPU en dispositivos de gama media.

A pesar de su superioridad tecnológica, el uso de GPU Resident Drawer en el pipeline móvil requiere tener en cuenta ciertas limitaciones específicas. En primer lugar, impone exigencias estrictas a la arquitectura de memoria: los búferes estructurados deben estar alineados en límites de 16 bytes para evitar penalizaciones por accesos incorrectos a la VRAM en los chips Mali. En segundo lugar, aunque Unity 6 ha ampliado significativamente la compatibilidad con Skinned Mesh Renderers dentro de GRD gracias a la ejecución del skinning en Compute Shaders (Compute Skinning), los personajes con alta densidad de huesos y blendshapes requieren un ajuste preciso del presupuesto de memoria en el GPU Allocator.

En el pipeline práctico para los años 2026–2027, un enfoque híbrido se considera el estándar de la industria: el entorno, los props, la geometría interactiva destructible y las unidades masivas basadas en ECS se trasladan por completo bajo la gestión de GPU Resident Drawer, mientras que los personajes principales (hero characters) únicos con una lógica compleja de materiales y efectos de transparencia se pueden renderizar a través del flujo estándar de Render Graph. Esto garantiza el máximo ahorro de ciclos de CPU y evita el sobrecalentamiento de los dispositivos móviles durante sesiones de juego prolongadas.

La transición a pipelines de renderizado híbridos y el uso completo de la tecnología GPU Resident Drawer en Unity 6 cambia fundamentalmente los requisitos para la preparación de assets de juego. En el renderizado tradicional orientado a CPU, el procesador ejecuta Frustum y Occlusion Culling antes de cada frame, ordena los objetos por materiales y genera paquetes de comandos (Draw Calls). Al activar GPU Driven Rendering, esta carga se traslada por completo a los Compute Shaders de la GPU. Sin embargo, la GPU solo procesa los datos de manera eficiente cuando la geometría y los materiales están estrictamente estructurados, son monolíticos y resultan predecibles para los flujos paralelos de las unidades de ejecución (execution units) del chip móvil (Apple Silicon, Snapdragon, Dimensity).

1. Geometría estricta: estandarización de buffers de vértices y submeshes
El requisito clave de GPU Resident Drawer en Unity 6 es minimizar la cantidad de submeshes a nivel de modelos 3D. Cada subsección individual del mesh con un material único genera un descriptor de instancia independiente en el buffer estructurado de la GPU. Si un asset 3D de un edificio contiene 8 submeshes con diferente mapeado de textura (UVs), el híbrido GPU Driven pierde hasta un 70% de eficiencia de muestreo (el Occlusion Culling se ejecuta para cada submesh por separado, cargando la caché L2 del procesador gráfico).

• Monolitismo de la geometría: Un mesh, un submesh. Todos los elementos del entorno, props e incluso bloques arquitectónicos complejos deben combinarse en la etapa de exportación desde software DCC (Blender, Maya) en un único mesh con un solo material.
• Optimización del Layout de vértices (Vertex Stream Packing): Unity 6 requiere un alineamiento estricto de los datos de vértices en límites de 16 bytes. En los chips móviles de 2026 con arquitectura ARM TBDR, es necesario eliminar los canales no utilizados (UV3, UV4, Vertex Colors, Tangents, si en el mesh se utiliza un shader con máscara sin mapas de normales). El uso de formatos de datos `FP16` (mitad de precisión) para coordenadas UV y normales comprimidas `Octahedral Vector Encoding` reduce el volumen del buffer de vértices en VRAM entre un 40 y un 50%.
• Buffers de índices de 16 bits: En la medida de lo posible, mantén la cantidad de vértices de un prop móvil dentro del límite de 65 535 (Index Format: `UInt16`). La transición a `UInt32` duplica el volumen de memoria leído por el pipeline de vértices de la GPU en una sola pasada del bloque de fetch.

2. Arquitectura de shaders para DOTS Instancing y GPU Resident Drawer
Los shaders personalizados, escritos a mano o creados mediante Shader Graph en la URP de Unity 6, deben mantener compatibilidad total con la arquitectura `BatchRendererGroup` (BRG). El error principal al pasar al renderizado orientado a GPU es el uso de instancias individuales de materiales (`MaterialPropertyBlock` o cambio dinámico de parámetros a través de scripts de CPU en `Update`), lo que provoca la ruptura forzada (break) de los batches de instancias.

Para mantener un único Draw Call con cientos de objetos diferentes en la escena, se debe implementar el siguiente enfoque de shaders:

• Shader Graph: Activación obligatoria del flag `DOTS Instancing` en los ajustes del Master Node. El shader transmite automáticamente las propiedades (colores, coeficientes de rugosidad, offsets) a un buffer constante global único `StructuredBuffer`, accesible para lectura en la GPU.
• Uso de Texture Arrays (Texture2DArray): En lugar de inflar la cantidad de materiales con mapas de albedo individuales, los artistas técnicos combinan las texturas en arrays únicos (Texture Arrays). En los datos de instancia del objeto se transmite únicamente un índice entero de textura `TextureIndex` a través de los atributos de vértice o el buffer de instancia. El shader lee la textura requerida directamente por índice sin cambiar los estados del shader en el controlador (driver) Vulkan 1.3 / Metal 3.

3. Sistemas LOD dirigidos por GPU (GPU-driven) y Dithering dinámico
El componente estándar `LODGroup`, gestionado a través de la CPU, genera una sobrecarga (overhead) considerable al procesar miles de instancias. En Unity 6, un art pipeline optimizado se basa en el muestreo de niveles de detalle dirigido por GPU, donde el compute shader de culling calcula de forma autónoma la distancia de la cámara al objeto y escribe el índice LOD visible en el buffer de comandos generado `DrawIndexedInstancedIndirect`.

Para evitar saltos bruscos en la geometría (popping) al cambiar de LOD y evitar la proliferación de materiales con Alpha Blend estándar (el cual destruye el rendimiento de las GPU móviles debido a la desactivación del Early-Z), se utiliza un suavizado transparente por degradado: Dithered Cross-Fade:

• Se añade al shader una máscara de ruido fragmentada (Screen-space Dither Pattern), controlada por un coeficiente global `FadeValue` transmitido desde el buffer de culling de la GPU.
• Al pasar de LOD0 a LOD1, ambos meshes se renderizan simultáneamente durante un breve momento, disolviéndose el uno en el otro mediante la máscara de píxeles sin escribir en el buffer Alpha, manteniendo así el funcionamiento del bloque Early-Z / Tile-Based Deferred Rendering.
• Presupuesto de LOD para dispositivos móviles: Para proyectos móviles en 2026, el estándar de oro es una geometría con la siguiente progresión: LOD0 (100% de detalle), LOD1 (40–50% de triangulación, eliminación de elementos pequeños), LOD2 (15–20% de geometría, sin mapas de normales, uso de mapas horneados agresivos).

La implementación de estas reglas strictly estrictas en el pipeline de modelado y texturizado permite aprovechar al máximo el GPU Resident Drawer en Unity 6: reducir miles de llamadas de renderizado (Draw Calls) únicas a tan solo unas pocas órdenes en buffer, liberar a la CPU móvil del cálculo de visibilidad y eliminar por completo los tirones de frames (freezes) causados por el cambio de estados gráficos.

Con el lanzamiento de Unity 6, la arquitectura de Universal Render Pipeline (URP) ha completado definitivamente su transición hacia el paradigma de Render Graph API. En los proyectos móviles modernos de 2026, el uso de métodos obsoletos para trabajar con `ScriptableRenderPass` sin una descripción explícita del grafo de renderizado se considera un error técnico crítico. Las GPU móviles (incluidos los chips modernos Apple A18/M4, Qualcomm Snapdragon 8 Gen 4/5 y ARM Immortalis) funcionan sobre la base de una arquitectura basada en tiles (TBDR, por sus siglas en inglés: Tile-Based Deferred Rendering). Para alcanzar el objetivo de 60 a 120 FPS en dispositivos móviles, es fundamental minimizar la reescritura de datos entre la memoria rápida en el chip (Tile SRAM) y la memoria RAM principal (LPDDR5X/LPDDR6). La Render Graph API en Unity 6 proporciona al desarrollador una herramienta directa para el aislamiento preciso de pases personalizados y la gestión del tiempo de vida de los recursos gráficos.

El principal problema del pipeline clásico radicaba en las operaciones no controladas de exportación e importación de texturas. Si un pase personalizado (por ejemplo, el cálculo del brillo especular para agua estilizada o un pase de cálculo de niebla volumétrica) no está aislado en el grafo, el controlador de video de Vulkan o Metal se ve obligado a volcar de forma forzada el contenido del tile a la VRAM global (StoreAction) y luego volver a cargarlo (LoadAction). En dispositivos móviles, estos viajes de ida y vuelta («Tile a DRAM») provocan caídas instantáneas de cuadros debido al agotamiento del ancho de banda del bus de memoria y causan throttling térmico en el procesador. Render Graph resuelve este problema mediante una descripción declarativa de las dependencias de los recursos, construyendo automáticamente la cadena de comandos óptima para la API gráfica.

La estructuración de un pase personalizado en Unity 6 se basa en la separación entre la fase de registro del grafo (Record Phase) y la fase de ejecución (Execute Phase). En lugar de asignar texturas temporales mediante llamadas heredadas (legacy) como `CommandBuffer.GetTemporaryRT`, el desarrollador debe recurrir a la declaración de recursos gráficos efímeros (Transient Resources) dentro del Render Graph Context:

• Declaración de recursos y dependencias: En la fase de construcción del grafo, se invoca `builder.UseColorBuffer()` o `builder.UseDepthBuffer()`, indicando claramente la dirección del flujo de datos (`AccessFlags.Read`, `AccessFlags.Write` o `AccessFlags.ReadWrite`). Esto permite al compilador del grafo de Unity 6 combinar pases independientes o aplicar tecnologías de Resource Aliasing, donde una misma región de memoria es reutilizada por diferentes texturas temporales en distintos momentos.
• Acciones explícitas de Load y Store: Para cada búfer adjunto, se deben definir estrictamente los flags de carga y guardado. Si un pase personalizado redibuja por completo su búfer de pantalla, es obligatorio especificar `LoadOp.Clear` o `LoadOp.Discard` (DontCare) para evitar que la GPU desperdicie ciclos leyendo el fotograma anterior desde la DRAM. Al finalizar el pase, si la textura solo se necesita dentro de esa ejecución (por ejemplo, un búfer intermedio de desenfoque Bloom), se establece `StoreOp.Discard`.
• Adjuntos efímeros (Transient Attachments / Memory-Less): En iOS (Metal) y Android (Vulkan), Render Graph en Unity 6 permite marcar los render targets intermedios como `Transient`. Dichos búferes se asignan físicamente solo dentro de la memoria SRAM del tile y no ocupan memoria RAM física en absoluto (costo de VRAM = 0 MB). Esto es ideal para búferes de resolución MSAA en Render Graph o mapas de profundidad intermedios.

Se ha prestado especial atención en Unity 6 a la compatibilidad con Native Render Passes en Vulkan y Metal. Cuando los pases personalizados se estructuran correctamente mediante la API `RasterRenderPassData`, el compilador de Render Graph puede fusionar físicamente (Subpass Merging) varios pases consecutivos en un único RenderPass a nivel de API de bajo nivel. Por ejemplo, un pase de descomposición de dispersión subsuperficial (SSS) personalizado y un pase posterior de posprocesamiento pueden ejecutarse dentro de un mismo pase de búfer de tile sin una sola consulta a la memoria externa.

Para garantizar el aislamiento y la optimización de un pase personalizado, se recomienda la siguiente secuencia de decisiones de arquitectura:

• Renuncia total a UnsafePass siempre que sea posible: Unity 6 introduce el contrato preciso `AddRasterRenderPass`. El uso del obsoleto `AddUnsafePass` interrumpe el análisis automático del grafo y obliga al pipeline a establecer barreras de sincronización de memoria conservadoras (las más lentas).
• Perfilado del grafo mediante Frame Debugger y RenderDoc: El Frame Debugger actualizado de Unity 6 incluye visualización de barreras de memoria. Verifique que entre sus pases personalizados no existan flags de `Global Memory Barrier` ni cambios no planificados de formato de píxel que provoquen un restablecimiento del contexto del tile.
• Control de la precisión de bits de los búferes: En pipelines móviles en 2026, evite el uso de búferes float de 16 bits donde sea suficiente utilizar `R8G8B8A8_UNorm` o formatos intermedios comprimidos. Cuanto menor sea el tamaño del píxel del fotograma, más píxeles se ajustarán en la caché del tile en el chip del acelerador gráfico móvil.

Una transición adecuada a Render Graph API enfocada en el aislamiento de pases permite ahorrar entre un 30 % y un 40 % del ancho de banda de memoria en dispositivos móviles. Esto reduce de manera directa el consumo energético del dispositivo, previene el sobrecalentamiento del chasis y garantiza una tasa de fotogramas estable en proyectos móviles 3D de alta carga.

La migración completa de un proyecto móvil a una Data-Oriented Technology Stack (DOTS/ECS) "pura" es una tarea que, incluso en 2026, no siempre resulta justificada debido a la complejidad de integrar SDK de terceros, sistemas de UI (como UI Toolkit o Canvas) y plugins específicos. Sin embargo, en el entorno de Unity 6, el enfoque híbrido (Hybrid DOTS) se ha convertido en el estándar por defecto para juegos 3D de presupuesto medio y a gran escala. Permite combinar los GameObjects tradicionales para facilitar la maquetación, las animaciones de personajes y la lógica de interfaz con el rendimiento sin concesiones de los sistemas de componentes puros (Entities) y el compilador Burst para el cálculo de sistemas con gran carga matemática.

El objetivo principal de la arquitectura híbrida en proyectos móviles modernos es aprovechar el 100% de la capacidad de procesamiento de los procesadores ARM multinúcleo (arquitecturas ARMv9.2-A y superiores), evitando al mismo tiempo los dos problemas principales del desarrollo móvil: el estrangulamiento térmico (throttling) por sobrecalentamiento del SoC y los picos de retraso del recolector de basura (GC Spikes). Para lograr este efecto, Unity 6 utiliza un pipeline de baking actualizado (Baking API), interfaces ISystem y colas de sincronización de datos de bajo nivel.

Patrones arquitectónicos de interacción entre ECS y GameObject

La práctica de desarrollo de 2026–2027 destaca tres patrones clave para vincular el sistema de componentes con la jerarquía MonoBehaviour:

• Patrón "Entity-Driven Presentation" (Presentación guiada por entidades): Toda la lógica (movimiento, detección de colisiones, búsqueda de rutas, IA de enemigos o proyectiles) se traslada por completo a estructuras IComponentData y se ejecuta en sistemas no administrados (ISystem). Los GameObjects se utilizan exclusivamente como "envoltorios" visuales (partículas, mallas de alta calidad, fuentes de luz) que leen las transformaciones de ECS mediante arreglos optimizados para trabajos TransformAccessArray o el paquete Entities.Graphics.
• Patrón "Baking & Hybrid Components": El diseño de niveles se realiza de forma clásica en el editor de Unity. Durante el proceso de autoría (Authoring), los Bakers (IBaker<T>) convierten los datos pesados en componentes ECS. Los MonoBehaviors solo se conservan donde se requiere una vinculación directa con el Animator o componentes de física PhysX/Unity Physics.
• Patrón "Native Events Bridge": La comunicación entre el código C# administrado (UI, analítica, gestores de audio) y los datos ECS no almacenados en caché se implementa mediante colas NativeQueue<T> y eventos EntityCommandBuffer. Esto elimina por completo la asignación de memoria en el Heap administrado (Managed Heap) durante el combate o el juego intenso.

Optimización para procesadores ARM multinúcleo y prevención de estrangulamiento térmico

Los chipsets móviles modernos utilizan una arquitectura heterogénea (por ejemplo, una combinación de núcleos de cálculo Cortex-X, Cortex-A7xx y Cortex-A5xx). El C# Job System predeterminado de Unity 6 distribuye automáticamente las tareas entre subprocesos; sin embargo, sin una configuración adecuada del compilador Burst, los sistemas ECS de alta carga pueden sobrecargar los núcleos de alto rendimiento (Super/Big Cores), provocando la regulación térmica rápida del dispositivo y la reducción de frecuencias.

Para evitar esto, en 2026 se aplican las siguientes metodologías al escribir código Burst:

• Uso de instrucciones vectoriales NEON y SVE2: El compilador Burst en Unity 6 admite la vectorización automática de código para instrucciones ARM SVE2. Al calcular matemáticas masivas (por ejemplo, miles de unidades o proyectiles en un Bullet Hell), la estructuración de datos en forma de NativeArray con alineación secuencial de memoria permite procesar hasta 4 u 8 operaciones de punto flotante por ciclo de reloj del procesador.
• Escalado dinámico de subprocesos (Worker Thread Scaling): Uso de la API JobsUtility.JobWorkerCount junto con servicios móviles de regulación térmica del sistema (Adaptive Performance / Android Thermal API). Al acercarse a temperaturas críticas, los sistemas ECS híbridos escalan la cantidad de chunks procesados por fotograma o reducen temporalmente la frecuencia de actualización de sistemas secundarios (por ejemplo, desactivando parte del cálculo de rutas de IA a largas distancias).
• Minimización de fallos de caché (Cache Misses): Las estructuras de datos (IComponentData) se diseñan estrictamente teniendo en cuenta el tamaño de las líneas de caché L1/L2 de los procesadores ARM (normalmente 64 bytes). La disposición de datos en bloques estrechos y densos (SoA — Structure of Arrays) permite al procesador leer datos de la memoria sin tiempos de espera en el bus RAM.

Gestión de cambios de arquetipo y EntityCommandBuffer (ECB)

El error más común al implementar DOTS híbrido en juegos móviles es provocar los llamados Structural Changes (cambios estructurales). Agregar o eliminar componentes, así como crear y destruir entidades durante la ejecución de un `Job`, provoca el vaciado de la caché de arquetipos, el bloqueo instantáneo de subprocesos y tirones de fotogramas (frame freezes).

En el pipeline actual de Unity 6, el trabajo con cambios dinámicos se basa en dos reglas:

1. Uso de puntos de reproducción optimizados del sistema (Playback Points):
Todos los cambios de estructura se envían a un EntityCommandBuffer.ParallelWriter paralelo. La grabación de comandos ocurre dentro de funciones Execute multihilo, y su aplicación (Playback) se pospone hasta fases estrictamente asignadas del fotograma, por ejemplo, EndSimulationEntityCommandBufferSystem. Esto reduce el número de reordenaciones de memoria a una sola fase por fotograma.

2. Uso de Enableable Components en lugar de crear/eliminar:
En lugar de agregar un componente Frozen o Poisoned a una entidad (lo que cambia su arquetipo y la mueve de un chunk de memoria a otro), en 2026 la práctica estándar es aplicar la interfaz IEnableableComponent. Activar y desactivar el indicador ocurre en tiempo O(1) sin alterar la estructura de la memoria y sin bloquear los subprocesos paralelos de Burst.

Caso práctico: Sistemas masivos en 3D móvil

Consideremos una tarea típica: la simulación de 2 000 objetos activos (por ejemplo, una horda de enemigos o disparos en un juego de acción móvil) transfiriendo sus coordenadas a componentes visuales GameObject.

Con el enfoque clásico, 2 000 Update() de MonoBehaviour provocarán una caída inevitable de los FPS por debajo de 30, incluso en dispositivos de gama alta. En el modelo híbrido de Unity 6, el cálculo de la física, la lógica y la búsqueda de objetivos se realiza en un único ISystem compilado con Burst:

1. El sistema itera sobre los chunks de RefRW<LocalTransform> y RefRO<TargetPosition> en paralelo a través de varios subprocesos.
2. Al finalizar los cálculos, el arreglo nativo con las nuevas coordenadas se pasa a TransformAccessArray.Schedule(), el cual actualiza las transformaciones físicas de los GameObjects a nivel del motor en código C++, omitiendo la capa administrada de C#.
3. Como resultado, el rendimiento aumenta entre 10 y 15 veces: el tiempo de procesamiento del fotograma en la CPU disminuye de 18 ms a 1.2 ms, dejando la mayor parte del presupuesto de tiempo por fotograma para el renderizado y los shaders complejos.

De este modo, un DOTS híbrido bien diseñado en 2026 permite crear juegos 3D móviles con una escala y densidad de interacción antes solo alcanzables en consolas y PC, manteniendo la flexibilidad de desarrollo y el control sobre el consumo de energía de los dispositivos móviles.

En los proyectos 3D móviles actuales de 2026, el cálculo de la física sigue siendo una de las tareas que más recursos consume en los sistemas en chip (SoC) móviles. A diferencia del pipeline gráfico, los cálculos de física cargan principalmente los núcleos de la CPU y el subsistema de memoria. Al migrar a Unity 6, el módulo estándar PhysX da paso a soluciones híbridas y totalmente orientadas a DOTS. El paquete Unity Physics, impulsado por Burst Compiler, permite trasladar el ciclo de simulación física a un flujo de cálculos SIMD; sin embargo, sin un control estricto de la estructura de datos y un correcto aislamiento de colisiones, incluso un motor determinista agotará rápidamente el presupuesto de fotogramas en chips móviles del nivel de Snapdragon y la serie A de Apple.

El principal desafío metodológico al configurar Unity Physics en dispositivos móviles es maximizar el uso de instrucciones vectoriales (NEON para ARM64) manteniendo la precisión de colisiones (Collision Accuracy). Para lograrlo, el pipeline de física se divide en tres etapas críticas: la optimización de la fase de búsqueda de contactos potenciales (Broadphase), la vectorización SIMD de la fase de cálculo preciso (Narrowphase) y la implementación de zonas de culling jerárquicas.

1. Vectorización y SIMD a través de Burst Compiler
El subcódigo estándar de procesamiento de colisiones suele sufrir a causa del código administrado (memoria administrada) y las asignaciones del recolector de basura (GC). En Unity 6, la optimización de la física comienza con el abandono total de los clásicos `OnCollisionEnter` en favor de trabajos paralelos `ICollisionEventsJob` e `ITriggerEventsJob`. Burst Compiler compila los núcleos matemáticos del solver de física en código máquina con soporte para registros de 128 bits ARM NEON. Para que Burst pueda autovectorizar los cuellos de botella de la manera más eficiente:

• Utilice primitivas simplificadas: Reemplace `MeshCollider` por una combinación de cápsulas, esferas y cajas (`BoxCollider`, `SphereCollider`). En Unity Physics, las colisiones entre primitivas se calculan analíticamente mediante SIMD en fracciones de nanosegundo.
• Optimice la estructura de datos: Pase arreglos de posiciones y orientaciones como búferes continuos (`NativeArray`), evitando punteros dispersos. Esto minimiza los fallos de caché (Cache Misses) en la CPU.
• Ajuste las Solver Iterations: Para dispositivos móviles, el valor de `Physics Step Solver Iterations` se reduce a entre 2 y 4 iteraciones. La precisión se compensa mediante el uso de algoritmos de predicción de contacto.

2. Descarte espacial: Zonas de culling dinámicas
No tiene sentido calcular la física para objetos que están fuera del campo de visión del jugador o más allá de su radio de interacción. En 2026, el estándar en el desarrollo móvil es el sistema de hashing espacial (Spatial Hashing) y culling por distancia física (Physics Distance Culling):

• Jerarquía de zonas de culling: La escena se divide en una cuadrícula regular o un árbol Octree. Los objetos ubicados en sectores inactivos pasan de la categoría de cuerpos dinámicos a una topología estática o se excluyen por completo de la simulación (desactivando el componente `PhysicsBody`).
• Frecuencia de simulación híbrida (Physics Tick LOD): Para objetos de la primera zona (dentro de un radio de 15 metros de la cámara), la simulación se ejecuta en cada `FixedUpdate` (por ejemplo, a 50 Hz). Para objetos distantes, la frecuencia se reduce a 10–25 Hz mediante interpolación temporal de fotogramas intermedios en la GPU.

3. Mantención de la precisión de colisiones sin Continuous Collision Detection (CCD)
Los objetos de alta velocidad (proyectiles, vehículos) tradicionalmente requieren activar Speculative CCD, lo que provoca caídas de rendimiento en la CPU a medida que aumenta drásticamente el número de objetos. En los pipelines de Unity 6, este problema se resuelve mediante predicción matemática basada en Raycast/Shapecast dentro del paquete SIMD:

En lugar de un pesado cálculo de física continua, en cada fotograma se ejecuta un trabajo de Burst altamente paralelo que realiza `Physics.CastRay` o `Physics.CastCapsule` a lo largo del vector de velocidad del objeto para el siguiente paso de tiempo. Si no se detecta intersección, el objeto se mueve mediante un paso cinemático normal. Si se detecta, la colisión se procesa de forma preventiva. Esto permite mantener un 100 % de precisión en los impactos para elementos de juego de alta velocidad, reduciendo la carga sobre el motor de física hasta en un 70 % en comparación con el CCD estándar.

Durante mucho tiempo, la iluminación horneada en móviles se asociaba entre los desarrolladores con la compleja colocación manual de Light Probe Groups y enormes volúmenes de mapas de luz (lightmaps) que inflaban el tamaño de la compilación. Con el lanzamiento del ecosistema Unity 6, el sistema Adaptive Probe Volumes (APV) se ha consolidado definitivamente como el estándar de la industria para Universal Render Pipeline (URP), desplazando por completo el flujo de trabajo manual obsoleto. En el entorno de las arquitecturas móviles modernas (desde Snapdragon 8 Gen 3/Gen 4 y Apple A18/M4 hasta chips masivos con GPU Mali-G720 y Adreno 750), APV ofrece un equilibrio ideal entre una iluminación global (GI) completa y precisa y un estricto presupuesto de rendimiento.

La principal ventaja de APV en dispositivos móviles es la voxelización automática del espacio y la generación de probes con densidad adaptativa basada en la geometría de la escena. Sin embargo, el uso descontrolado de APV puede agotar instantáneamente el ancho de banda de memoria (Memory Bandwidth) de la GPU móvil. Para lograr 60 o 120 FPS reales en dispositivos de gama alta y 30 FPS estables en dispositivos de gama media, se requiere un ajuste preciso del pipeline híbrido, combinando APV para la luz indirecta y fuentes dinámicas optimizadas para la iluminación directa.

Especificaciones técnicas de configuración de APV en URP 6 para dispositivos móviles:

• Elección del orden de armónicos esféricos (Spherical Harmonics): Para proyectos móviles es de vital importancia utilizar L1 Spherical Harmonics en lugar de L2. Pasar a L1 reduce el volumen de datos transmitidos por probe de 27 a 9 floats, lo que ahorra hasta un 66% de VRAM y reduce drásticamente la carga sobre el renderizador basado en tiles móvil (TBDR). La diferencia visual en los reflejos suaves de luz indirecta en una pantalla móvil de 6,7 pulgadas es prácticamente imperceptible.
• Limitación de niveles de subdivisión (Max Subdivision Level): No utilice el detalle máximo de probes en todo el escenario. Para espacios abiertos en móviles es suficiente fijar el parámetro Max Subdivision en un nivel de 3 o 4, con un tamaño de celda base (Cell Size) de 16 a 32 metros. La densidad máxima solo debe generarse en las zonas de interacción del jugador y en interiores estrechos.
• Configuración de APV Probe Streaming: Unity 6 implementa la carga por transmisión (streaming) de datos de probes desde el disco hacia la memoria. En dispositivos móviles, el tamaño del pool APV Memory Budget debe limitarse a un rango de 16–32 MB. Configurar el streaming basándose en la cámara virtual evitará tirones (freezes) al desplazarse rápidamente por un mundo abierto continuo.
• Prevención de filtraciones de luz (Light Leakage): Para corregir artefactos de filtración de luz en GPU móviles, no se debe utilizar el pesado Virtual Offset por trazado de rayos en tiempo de ejecución. Utilice el horneado de máscaras de validez (Validity Masks) y el parámetro Dilation en la etapa de compilación; esto excluirá las probes no válidas dentro de las mallas (meshes) sin costo de cálculos en la GPU en tiempo real.

El esquema de iluminación híbrida en 2026 se basa en la combinación de APV + Forward+ Rendering. En lugar de intentar hornear los rayos directos del sol o luces en texturas estáticas, la iluminación directa se delega por completo a una Directional Light dinámica con mapas de sombras en cascada (Cascaded Shadow Maps, con un límite de 2 cascadas para móviles), mientras que toda la luz difusa reflejada y la iluminación indirecta se obtienen de APV. Para objetos dinámicos (héroes, enemigos, entorno interactivo), la lectura desde APV ocurre de manera extremadamente rápida a través de Compute Shaders en un solo pase.

Merece especial atención la implementación del cambio de hora del día sin la carga sobre el hardware que supone el GI en tiempo real dinámico. Mediante el mecanismo Lighting Scenario Blending integrado en APV, puede hornear dos o más estados de iluminación (por ejemplo, "Día" y "Noche") en una sola estructura APV. En tiempo de ejecución (runtime), Unity 6 realiza una interpolación lineal (lerp) ligera entre los coeficientes de las probes en la GPU, requiriendo solo un pequeño volumen de memoria adicional para los datos del segundo escenario y un cálculo ínfimo en el fragment shader, manteniendo plenamente los FPS objetivo.

Por último, APV se integra a la perfección con GPU Resident Drawer (GRD). Al realizar instanciamiento de miles de props estáticos en la escena (vegetación, rocas, elementos de edificios), la GPU solicita por sí misma los datos de iluminación desde un buffer único de APV basándose en las coordenadas del mundo de cada instancia. Esto elimina por completo la carga en la CPU al transferir `MaterialPropertyBlock` para cada instancia, reduciendo el proceso de renderizado del fotograma a un número mínimo de Indirect Draw Calls.

En 2026, las arquitecturas de procesadores gráficos móviles (como las series Qualcomm Adreno 7xx/8xx y ARM Mali/Immortalis) poseen una potencia de cálculo impresionante; sin embargo, el principal cuello de botella al renderizar escenas 3D complejas en Unity 6 sigue siendo el uso eficiente del archivo de registros (Register File). El pipeline gráfico URP (Universal Render Pipeline) en las versiones actuales de Unity 6 ofrece el editor visual Shader Graph, pero la generación no controlada de código HLSL suele provocar el fenómeno de Register Pressure: una sobrecarga crítica de los registros de propósito general (GPR). En las GPU móviles con arquitectura TBDR (Tile-Based Deferred Rendering), esto afecta de inmediato al paralelismo (occupancy) y provoca el vertido de datos temporales a la memoria externa (register spilling), destruyendo el rendimiento.

El archivo de registros físico de un multiprocesador de comandos móvil está estrictamente limitado y se comparte entre todos los hilos activos (threads/lanes). Cuantas más variables temporales, nodos matemáticos complejos y vectores de alta precisión genere tu shader, menos hilos podrá ejecutar la GPU simultáneamente dentro de un mismo warp (Adreno) o wavefront (Mali). Si el shader requiere demasiados registros, la GPU reduce la cantidad de píxeles procesados al mismo tiempo, lo que provoca que las unidades aritmético-lógicas (ALU) queden inactivas esperando el muestreo de texturas desde la memoria del sistema.

Optimización de la precisión de datos y del perfil de registros

Para evitar el Register Pressure al trabajar con Shader Graph en Unity 6, es necesario mantener una disciplina estricta en la asignación de precisión y en la estructura del grafo:

• Control total de la precisión (Precision Control): Configura la precisión tanto a nivel global del grafo en Graph Settings como para nodos individuales. Todos los cálculos de color, vectores de iluminación, máscaras alfa y desplazamientos simples de UV deben forzarse al modo Half (FP16). El uso de Float (FP32) debe limitarse strictly a las coordenadas de espacio de mundo (World Position), operaciones de profundidad (Depth) y UV escalables para eliminar efectos de tramado (dithering). En las arquitecturas Mali y Adreno, el uso de FP16 permite empaquetar dos variables en un solo registro de 32 bits (ejecución SIMD), reduciendo a la mitad la carga sobre el archivo de registros e incrementando el rendimiento máximo de las ALU.
• Empaquetado de interpoladores (Varying Packing): El paso de datos desde el vertex shader al fragment shader consume valiosos registros de interpolador. Combina valores escalares aislados y vectores 2D en estructuras half4 unificadas. Por ejemplo, las coordenadas UV0.xy y UV1.xy se deben transmitir como un único vector half4(uv0.x, uv0.y, uv1.x, uv1.y), desempaquetándolas directamente en el stack de fragmentos.
• Eliminación de nodos redundantes y duplicaciones: En Shader Graph 2026, presta especial atención a las conexiones entre subgrafos (Sub-Graphs). Si una misma operación matemática compleja (como la normalización de un vector o el cálculo de iluminación Fresnel) se utiliza en varias ramas del grafo, extráela a un nodo independiente y distribuye el resultado a las entradas correspondientes. El optimizador automático de HLSL en Unity no siempre es capaz de simplificar cadenas complejas de nodos, lo que genera variables temporales innecesarias.

Ramificación dinámica y barreras de rendimiento SIMD

El segundo problema fundamental de los shaders móviles sigue siendo la ramificación dinámica: la aplicación de condiciones if/else que dependen de datos por píxel, mapas de textura o resultados de cálculos en el fragment shader. Los procesadores gráficos procesan píxeles en bloques (cuadrículas de 2x2 / quads). Si dentro de un mismo warp al menos un píxel toma la rama true y los 31 restantes la rama false, la GPU móvil se ve obligada a ejecutar secuencialmente ambas ramas de código para todo el grupo, limitándose a enmascarar los resultados inactivos (warp divergence).

Para evitar la divergencia de hilos en GPU móviles, utiliza las siguientes soluciones alternativas:

• Sustitución de ramificaciones por aritmética sin ramas: En lugar de nodos Branch o Comparison, utiliza las funciones integradas step(), saturate(), lerp(), sign() y mad() (Multiply-Add). Las ALU móviles modernas ejecutan operaciones como lerp(a, b, step(threshold, x)) en un solo ciclo de reloj a nivel de hardware, sin provocar paradas en el pipeline.
• Uso de máscaras multipaquete: Es más eficiente alternar efectos visuales (por ejemplo, cambios en los tipos de superficie o imperfecciones) mediante interpolación lineal (Lerp) a través de los canales RGBA de una textura de máscara que mediante la comprobación de condiciones lógicas.
• Aislamiento de ramificaciones Uniform: Si la ramificación es realmente necesaria (por ejemplo, al cambiar el algoritmo de sombreado), asegúrate de que la condición dependa de una propiedad del material (Material Property) o de un buffer global de fotograma. En Unity 6, estas ramificaciones deben estructurarse mediante mecanismos de Shader Keywords. Esto permite al generador de shaders crear variantes independientes (variants), eliminando las comprobaciones dinámicas durante la ejecución del código de fragmento. Controla estrictamente la cantidad de variantes mediante las nuevas reglas de Stripping en URP para evitar el aumento excesivo del tamaño de la compilación (build size).

Pipeline práctico de análisis de shaders en 2026

El desarrollo de shaders optimizados para Unity 6 móvil en 2026 se basa en el perfilado estático del código generado. La evaluación final de la eficiencia de un shader no debe realizarse desde la interfaz del editor, sino mediante herramientas externas de análisis de ISA (Instruction Set Architecture). Utiliza Mali Offline Compiler (incluido en Arm Mobile Studio) o Adreno GPU Inspector (AGNI). Exporta el código HLSL generado desde Shader Graph y verifica dos métricas críticas: la cantidad de GPR utilizados (General Purpose Registers, con un límite objetivo de no más de 16–24 registros por hilo para mantener una ocupación del 100 %) y la relación entre instrucciones matemáticas y de textura (relación ALU/TEX). Minimizar el uso de FP32 y eliminar las ramas divergentes garantiza una tasa de fotogramas estable de 60–120 FPS incluso en dispositivos móviles de gama media.

En el desarrollo de videojuegos móviles en 2026, los volúmenes de memoria RAM disponible en los dispositivos técnicamente han aumentado; sin embargo, el presupuesto real de VRAM para una aplicación de juego sigue estando estrictamente limitado. En los smartphones modernos con chipsets insignia, los algoritmos agresivos del sistema operativo, el thermal throttling y los procesos en segundo plano de otras aplicaciones limitan el margen seguro de memoria para un juego 3D a unos 2.5–4 GB. Dado que en el pipeline URP moderno de Unity 6 las texturas ocupan hasta el 65–70 % de toda la memoria gráfica, una estrategia adecuada de compresión, entrega y streaming en segundo plano de assets de textura se convierte en el factor principal para mantener un FPS estable y evitar cierres por falta de memoria (OOM / Out-Of-Memory).

El estándar fundamental de compresión para las GPU móviles modernas (series A17/A18/M de Apple Silicon, Qualcomm Adreno 7xx/8xx y ARM Immortalis) sigue siendo la familia de formatos ASTC (Adaptive Scalable Texture Compression). Sin embargo, los enfoques para su uso en Unity 6 han cambiado significativamente con la adopción generalizada de ASTC HDR. Anteriormente, para los mapas de emisión (Emissive), la iluminación horneada (Lightmaps) y las texturas HDR de alto rango dinámico, los desarrolladores debían recurrir a formatos sin comprimir como RGBA16Float o a algoritmos pesados de compromiso, lo que generaba un consumo colosal de memoria. En 2026, el soporte completo por hardware del perfil ASTC HDR en los chips móviles permite comprimir datos HDR con una pérdida mínima de calidad utilizando la misma cuadrícula de bloques.

La matriz de perfiles de compresión para un material PBR móvil en 2026 se estructura de la siguiente manera:

• Albedo / Base Color: ASTC 6x6 (en perfiles económicos, 8x8). Esto ofrece un equilibrio óptimo entre detalle y tamaño.
• Normal Maps: ASTC 4x4 o ASTC 5x5 con asignación forzada de dos canales (RG) para prevenir artefactos visuales en las normales bajo iluminación dinámica.
• Mask Maps (Metallic, Roughness, Ambient Occlusion, Smoothness): ASTC 5x5 o 6x6. Empaquetar de tres a cuatro mapas en un solo conjunto de texturas RGBA reduce las llamadas de dibujado (Draw Calls) innecesarias y ahorra descargas de la VRAM.
• Emissive & Baked Lightmaps: ASTC 4x4 HDR o 6x6 HDR. Proporciona gradientes de luz suaves y un funcionamiento correcto de Bloom sin banding ni exceso de uso de memoria.

Para la entrega de texturas a través de la red (LiveOps, bundles de actualización) y la reducción del tamaño de la build en las tiendas, la combinación híbrida de KTX2 y la supercompresión Basis Universal pasa a primer plano. El formato KTX 2.0 permite almacenar texturas en un estado intermedio súper comprimido. Al cargar el asset en tiempo de ejecución, Unity 6 transcodifica rápidamente Basis Universal directamente al formato objetivo de la GPU (en nuestro caso, ASTC) al vuelo mediante hilos de trabajo paralelos (Worker Threads). Esto reduce el volumen de descarga de los bundles de Addressables entre un 40 y un 60 % en comparación con las texturas empaquetadas estándar, sin sobrecargar la VRAM con arrays originales sin comprimir.

La optimización en disco no resuelve el problema si todas las texturas de la escena se cargan en la memoria al mismo tiempo. En Unity 6, la integración del sistema Texture Streaming (Mipmap Streaming) con el framework Addressables funciona a nivel de core del motor y está estrechamente vinculada con el pipeline de visibilidad GPU Resident Drawer. En lugar de cargar la textura completa de alta resolución, el motor asigna memoria solo para los niveles Mip base. Los niveles Mip de alta resolución se cargan de forma asíncrona únicamente cuando el objeto entra en el frustum de la cámara (Frustum Culling) y ocupa un área significativa en la pantalla.

La arquitectura práctica de gestión de memoria de texturas incluye tres reglas:

• Establecimiento de límites estrictos de presupuesto de VRAM: En la configuración `QualitySettings.streamingRayscreenBudget` se define el límite de memoria para las texturas (por ejemplo, 1000 MB para dispositivos de gama media). Si se supera este umbral, el motor descarta automáticamente los niveles Mip superiores de los objetos lejanos.
• Separación de bundles por prioridades de visibilidad: Mediante Addressables, las texturas de alto detalle (4K/2K) se mueven a un grupo separado con la opción de carga en segundo plano a petición (On-Demand), mientras que los mipmaps de 512x512 permanecen en el bundle base de la localización.
• Descarga agresiva mediante conteo de referencias (Reference Counting): Uso de `Addressables.Release()` inmediatamente después de destruir u ocultar un sector del mapa. En combinación con llamadas a `Resources.UnloadUnusedAssets()` durante las pausas entre sesiones de juego, esto evita la fragmentación de la memoria VRAM, eliminando microtirones.

En los pipelines modernos de Unity 6, el diagnóstico de rendimiento de un proyecto 3D móvil ya no se reduce al simple conteo de Draw Calls y la cantidad de polígonos por fotograma. Con la adopción masiva de GPU Resident Drawer, la ejecución híbrida de DOTS y el cómputo asincrónico en la GPU, el enfoque clásico para identificar cuellos de botella ha quedado obsoleto: el número de llamadas de renderizado en el inspector puede acercarse a uno, pero el fotograma aún puede caer a 25 FPS en los SoC objetivo. Una optimización integral en 2026 requiere la triangulación del problema a través de un conjunto de herramientas de tres etapas: el nivel superior con Unity Profiler, el análisis estructural con Frame Debugger y el análisis a nivel de hardware con Snapdragon Profiler (o su equivalente para chips Mali/PowerVR).

Cada una de estas herramientas se encarga de su propia capa de abstracción. Intentar diagnosticar el sobrecalentamiento del hardware de la GPU a través de Unity Profiler conducirá a conclusiones falsas, al igual que intentar encontrar una fuga de memoria en scripts de C# utilizando los contadores de sistema del chipset. A continuación, se presenta un algoritmo probado para la localización de cuellos de botella en CPU/GPU, actualizado para el ecosistema actual de Unity 6.x.

Etapa 1: Análisis de sistema de alto nivel en Unity Profiler
La tarea primaria en esta etapa es determinar el perfil de carga de la aplicación (CPU Bound o GPU Bound) y garantizar que no haya retrasos en el hilo de renderizado (RenderThread). En Unity 6, el módulo de perfilado cuenta con una integración profunda con el nuevo Job System y una API ampliada del perfilador de memoria (Memory Profiler 2.x API):

• Análisis de Main Thread vs. Render Thread: Si el marcador Gfx.WaitForPresentOnExecute consume más del 40% del tiempo de fotograma, el juego está limitado por la GPU (GPU Bound). Si dominan WaitForTargetFPS o JobSystem.Execute, el problema se encuentra en la CPU.
• Control de memoria administrada (C# Allocations): En 2026, el estándar exige cero asignaciones dinámicas de memoria en la sección Update(). El módulo GC Alloc permite detectar operaciones ocultas de conversión de tipos (boxing), llamadas a LINQ o asignaciones de expresiones lambda dentro de los sistemas DOTS.
• Inspección de Job Worker Threads: Al utilizar Hybrid DOTS de forma activa, es crítico supervisar los hilos de trabajo (worker threads). Las pausas prolongadas de espera (stalls) en la sincronización de JobHandle.Complete() indican un paralelismo no óptimo o una programación incorrecta de las dependencias.

Etapa 2: Auditoría estructural de geometría y batching mediante Frame Debugger
Una vez establecida la carga en el subsistema gráfico, es necesario analizar en detalle la estructura del fotograma. El Frame Debugger en Unity 6 se ha adaptado para trabajar con las novedades del pipeline de URP, incluyendo la fusión automática de mallas a través de GPU Resident Drawer.

El ingeniero de optimización debe monitorear el pase GPU Culling & Occlusion Pass. En el Frame Debugger, es necesario verificar que las llamadas DrawMeshInstancedIndirect combinen correctamente los objetos en búferes unificados. Si la cadena de instanciación se rompe, la herramienta mostrará la razón específica (Break Reason): diferencias en parámetros únicos de materiales, modificaciones dinámicas del Lightmap Index o sobrepaso de los límites de los búferes de constantes (CBUFFER). Se debe prestar especial atención a los pases de la fase Shadow Caster. La geometría de sombras generada de forma incontrolada para pantallas móviles de alta resolución (WQHD+) a menudo duplica la carga de vértices sin una mejora visible en la calidad.

Etapa 3: Perfilado de hardware de bajo nivel en Snapdragon Profiler
Las herramientas de Unity ofrecen una visión clara de la arquitectura del motor, pero ocultan los procesos físicos dentro del acelerador gráfico móvil (por ejemplo, la serie Qualcomm Adreno 700/800). En este paso, el dispositivo móvil se conecta mediante ADB en modo Low-Level Trace a Snapdragon Profiler (Layout: Real-Time System Trace / Graph Debugger).

• Análisis de ancho de banda de memoria (Memory Bandwidth): El principal enemigo del rendimiento móvil es la transferencia excesiva de texturas y búferes a través del bus DRAM. Los contadores Read/Write Bytes Per Second no deben superar los límites del paquete térmico permitido. El uso de compresión UBWC (Universal Bandwidth Compression) y texturas ASTC se verifica precisamente aquí.
• Carga de ALU vs. Texture Units (Fragment Bound): La métrica % Shaders Busy combinada con % ALU Capacity Utilized muestra si el fragment shader está limitado por cálculos matemáticos o por la lectura de texturas (Sampler Fetch Stalls).
• Desbordamiento de memoria de tiles (GMEM Stalls): Dado que las GPU móviles utilizan arquitectura basada en tiles (TBDR), el vaciado del contenido del tile a la memoria principal (Flush GMEM to System Memory) provoca caídas en la tasa de fotogramas. El perfilador resaltará de inmediato las llamadas parásitas de operaciones Discard/Store si el Clear Flag está mal configurado en el URP Render Pass.
• Dinámica de Thermal Throttling: Grabar el perfil durante 15 minutos permite observar la curva de reducción de frecuencias de reloj del núcleo (GPU Clocks) debido al sobrecalentamiento, lo que ayuda a encontrar el equilibrio entre el FPS máximo y un consumo de energía estable en el dispositivo objetivo.

Algoritmo paso a paso para la eliminación de cuellos de botella (Pipeline de diagnóstico 2026):

1. Obtén las métricas de Unity Profiler en el dispositivo físico objetivo (¡no en el editor!). Determina el sistema limitante: CPU (Main/Jobs) o GPU.
2. Si el cuello de botella está en la CPU: perfila las llamadas de C#, busca синхронизации innecesarias de Job System, optimiza el código de los sistemas de componentes (ECS/DOTS) y reduce la sobrecarga de TransformChangeDispatch.
3. Si el cuello de botella está en la GPU: abre el Frame Debugger, verifica la eficacia de GPU Resident Drawer, elimina las razones de ruptura del SRP Batcher y reduce el overdraw (sobreposición de píxeles) en shaders transparentes heterogéneos.
4. Ejecuta Snapdragon Profiler en modo de contadores de hardware. Encuentra la causa del bajo rendimiento en la GPU: alta carga en la lectura de texturas, cálculos demasiado complejos en compute shaders (Compute Shaders) o vaciados de GMEM.
5. Realiza cambios puntuales en LOD Group, materiales o ajustes gráficos de URP y repite el ciclo de perfilado para verificar tu hipótesis.

La implementación de este pipeline regular en las etapas de CI/CD de pruebas automatizadas permite detectar regresiones de rendimiento incluso antes de que la compilación llegue a manos del equipo de QA, garantizando unos 60/120 FPS estables incluso en los escenarios de juego más exigentes.

En el desarrollo de juegos móviles de 2026, el rendimiento no solo se define por la tasa de fotogramas máxima en los primeros segundos de una prueba, sino por la estabilidad del framerate a lo largo de una sesión continua de 20 a 30 minutos. La alta densidad de transistores en los chipsets móviles modernos provoca un calentamiento rápido bajo cargas de trabajo pico. Si el juego asigna memoria de forma activa en el heap administrado (Managed Heap) y sobrecarga el chip con cálculos no optimizados, el sistema operativo reduce de forma forzada las frecuencias de la CPU y la GPU (Thermal Throttling). Esta caída de frecuencia puede oscilar entre el 30 % y el 50 %, transformando unos fluidos 60 FPS en un renderizado a tirones. Combatir el throttling en Unity 6 requiere un enfoque integral: la eliminación total de la recolección de basura (GC) en el ciclo de ejecución (runtime) y la implementación de una gestión dinámica del consumo energético.

Arquitectura Zero-Allocation (GC-Free) en código administrado y no invasivo

A pesar de la evolución del Incremental Garbage Collector en Unity 6, cualquier llamada al recolector de basura en dispositivos móviles genera microcongelamientos debido a la sincronización de hilos. La regla de oro al desarrollar proyectos 3D exigentes es mantener cero asignaciones de memoria en el heap administrado durante el gameplay (Zero-Allocation on Frame).

Para alcanzar un estado GC-Free en 2026, se aplican los siguientes patrones prácticos:

• Uso de Span<T> y ReadOnlySpan<T>: El runtime de C# integrado en Unity 6 permite segmentar fragmentos de arreglos y cadenas sin crear objetos intermedios en el Heap. Esto reemplaza por completo las asignaciones obsoletas de `substring` o arreglos temporales al procesar datos binarios y cadenas.
• Contenedores Unity.Collections en lugar de System.Collections.Generic: El uso de NativeArray, NativeParallelHashMap y UnsafeList elimina la carga sobre el C# Garbage Collector. La memoria se asigna en áreas no administradas (unmanaged) y se controla manualmente mediante tipos de asignadores (Allocator.Temp, Allocator.TempJob, Allocator.Persistent).
• Eliminación del boxing implícito: Pasar estructuras a través de interfaces o llamar a enum.ToString() provoca el empaquetado (boxing) de tipos de valor en un objeto administrado. El uso de restricciones genéricas como where T : struct, IComponentData permite que el compilador Burst genere código de máquina altamente optimizado sin boxing.
• Búferes de cadenas FixedString: Reemplazar las string estándar de C# con tipos de tamaño fijo de `Unity.Collections` (como FixedString32Bytes o FixedString64Bytes) garantiza que el trabajo con etiquetas de texto, nombres de entidades y elementos de la interfaz de usuario se realice exclusivamente en el stack o en memoria nativa.

Impacto de la localidad de caché de DOTS en la reducción del calor

Un factor poco conocido pero crítico en la reducción térmica de frecuencias es el consumo energético del bus de memoria (RAM Bus Energy). Los fallos de caché frecuentes (Cache Misses) obligan a la CPU a acceder de forma continua a la memoria LPDDR. Cada transacción a través del bus genera calor. Los datos organizados según el Diseño Orientado a Datos (DOD) en DOTS residen en la memoria en bloques continuos (Chunks). Al procesarlos, el controlador del sistema lee los datos en la caché L1/L2/L3 con la máxima eficiencia. Reducir la frecuencia de acceso a la memoria RAM externa disminuye directamente el calentamiento del SoC móvil, postergando el límite del throttling.

Control térmico adaptativo mediante Adaptive Performance SDK

Incluso con un código GC-Free impecable, el juego puede calentar el dispositivo debido a la densidad gráfica. En Unity 6, la optimización del consumo de energía se articula en torno a la integración del Adaptive Performance SDK, el cual interactúa con las API de bajo nivel del sistema operativo (Android Adaptive Performance Framework / AAPF y Apple Thermal State API).

En lugar de funcionar con configuraciones máximas fijas, el motor recibe del sistema operativo метрикаs del estado actual del dispositivo (`ThermalStatus`) y la tendencia de temperatura (`Thermal Trend`). A partir de estos datos, se aplica una reducción gradual de la carga antes de que el sistema fuerce un throttling por hardware agresivo:

• Gestión de targetFrameRate y Pacing: Si el indicador del sistema señala la transición al estado `Throttling.Warning`, el juego limita dinámicamente la tasa de fotogramas (por ejemplo, de 120/60 FPS a unos estables 45 o 30 FPS). Esto permite que el chip se enfríe sin generar tirones ni cortes visuales.
• Escalado dinámico de resolución (Dynamic Resolution & Upscaling): En conjunto con URP, el regulador de escala de renderizado reduce la resolución interna del fotograma entre un 10 % y un 25 %, aplicando posteriormente un escalado espacial (Spatial Upscaling como FSR/STP), lo que alivia la carga de la GPU móvil.
• Desactivación en cascada de efectos gráficos: Reducción automática de la distancia de renderizado de sombras, desactivación de partículas secundarias en Visual Effect Graph y disminución de la calidad de Bloom/SSAO en función del calentamiento del chasis.

En 2026, la arquitectura de gestión de memoria y temperatura va mucho más allá de ejecutar `System.GC.Collect()` en las pantallas de carga: es un pipeline totalmente controlado. Mover los datos a la memoria nativa (Native), minimizar los fallos de caché mediante DOTS y contar con la retroalimentación del hardware a través de Adaptive Performance permite mantener una tasa de fotogramas estable en juegos 3D móviles, incluso durante sesiones de juego prolongadas.

El alto rendimiento de un juego 3D en Unity 6, logrado gracias a GPU Resident Drawer o DOTS, no garantiza el éxito comercial si el proyecto no cumple con las estrictas reglas actuales de las plataformas móviles. En 2026, tanto Google Play como Apple App Store imponen requisitos de tolerancia cero en cuanto a optimización técnica, arquitectura de archivos binarios y monitoreo en tiempo real del estado del dispositivo. El incumplimiento de estas normativas resulta en el rechazo automático del build durante la revisión automatizada, o bien en una penalización en el featuring y la visibilidad orgánica por parte de los algoritmos de las tiendas debido a métricas como Android Vitals y Apple Energy Impact.

Para publicar aplicaciones en Google Play en 2026, el estándar clave es la transición obligatoria a Target API Level 35 (Android 15), con miras a una compilación orientada a Target SDK 36. En Unity 6, los Player Settings exigen a los ingenieros descartar cualquier librería residual de 32 bits. El soporte para `armeabi-v7a` se considera definitivamente obsoleto para los gráficos 3D móviles modernos. Las builds se compilan estrictamente para la arquitectura de 64 bits (`arm64-v8a`) utilizando el backend IL2CPP y una optimización completa para el conjunto de instrucciones ARMv8.4-A y superior. Esto permite a los procesadores móviles distribuir los recursos de manera más eficiente entre los núcleos de alto rendimiento (P-cores) y los de eficiencia energética (E-cores), ganando hasta un 12% de tiempo de frame a nivel de llamadas al sistema.

La herramienta principal para integrar el perfilado adaptativo en el ecosistema Android es el módulo Android Performance Tuner (APT), incluido en el paquete actual Google AGDK (Android Game Development Kit) 2026 y totalmente integrado con Unity Adaptive Performance 5.0+. La integración de APT permite a los desarrolladores segmentar a su audiencia objetivo no por modelos de teléfono abstractos, sino por perfiles gráficos reales (Quality Tiers). Las firmas de frametime se envían a Google Play Console, donde generan analíticas detalladas:

• Frame Time Disruption Rate: Porcentaje de fotogramas que exceden el presupuesto objetivo (33.3 ms para 30 FPS o 16.6 ms para 60 FPS).
• GPU/CPU Boundness ratios: Proporción de cuellos de botella de rendimiento según las tecnologías de URP activas (por ejemplo, carga generada por un alto número de Draw Calls frente a shaders pesados).
• Thermal Throttling Events: Registro de los momentos en que el sistema operativo reduce la frecuencia del chip para evitar el sobrecalentamiento.

La combinación del paquete Adaptive Performance (Unity 6) con los controladores de Android e iOS abre la posibilidad de una optimización híbrida sobre la marcha. Cuando el sistema recibe una señal de que el dispositivo se aproxima a un umbral térmico (`ThermalStatus.Serious`), los scripts en tiempo de ejecución (runtime) pueden reducir la carga dinámicamente sin una caída visible en la calidad de imagen. En el pipeline de Unity 6, esto se implementa mediante la suscripción a eventos del contexto adaptativo:

// Ejemplo de adaptación dinámica a los requisitos de la plataforma en Unity 6
var thermalStatus = AdaptivePerformanceRenderScaler.ThermalStatus;
if (thermalStatus == ThermalStatus.Throttling) 
{
    // Reducción dinámica de la resolución de URP Render Scale
    UniversalRenderPipeline.asset.renderScale = 0.85f;
    // Limitación de la tasa máxima de fotogramas
    Application.targetFrameRate = 30;
    // Desactivación de post-efectos pesados (Motion Blur, Depth of Field)
    VolumeManager.instance.stack.GetComponent<DepthOfField>().active = false;
}

Por parte de Apple App Store, en 2026 es obligatorio el uso de iOS 19 SDK y la compilación de proyectos en Xcode 17+. Apple ha eliminado por completo la posibilidad de utilizar APIs gráficas obsoletas, convirtiendo a Metal 3 en el único interfaz de bajo nivel permitido. Unity 6 compila los shaders por defecto en Metal Shading Language (MSL) 3.1, lo que exige una configuración correcta de los layouts de buffers en los archivos de materiales de URP. Además, Apple presta especial atención al control del consumo de batería: las aplicaciones con un alto índice de Energy Impact pierden posiciones en las búsquedas. El uso de Adaptive Performance Apple Provider permite suavizar los picos de carga en los chips Apple A18/A19 y de la serie M mediante la distribución precisa de tareas entre los núcleos a través del API de sistema `ProcessInfo`.

Para gestionar el tamaño del instalador de juegos 3D de gran escala (que en 2026 alcanzan entre 3 y 10 GB debido a texturas 4K y mallas de alta densidad poligonal), es un requisito obligatorio la segmentación del build. En Google Play se utiliza la tecnología Play Asset Delivery (PAD) mediante el formato Android App Bundle (.aab), donde la geometría y las texturas de las subescenas de DOTS se empaquetan en conjuntos de recursos independientes (`install-time`, `fast-follow` y `on-demand`). En App Store, una función análoga la desempeñan los On-Demand Resources (ODR), que optimizan el tamaño de descarga inicial desde la tienda y descargan el contenido pesado a medida que se avanza en el juego.

En el desarrollo de videojuegos móviles de 2026-2027, un ajuste predeterminado de gráficos fijo ya no es viable: los chipsets de gama baja sufren estrangulamiento térmico de inmediato, mientras que los usuarios de dispositivos insignia basados en Snapdragon 8 Gen 4/Gen 5 y la línea Apple A18/A19 exigen 120 FPS reales. Para garantizar un rendimiento predecible en Unity 6, se requiere una matriz de escalabilidad (Scalability Matrix) flexible que combine las capacidades de las API gráficas (Vulkan 1.3, Metal 3) y la arquitectura de Universal Render Pipeline (URP).

A continuación, se presenta una matriz práctica de configuración del stack gráfico de Unity 6 para las tres categorías principales de dispositivos móviles:

• Low-End Tier (Gama baja / Legacy ARM Mali & Qualcomm Adreno):
  • Tasa de fotogramas objetivo: 30–60 FPS (con énfasis en la estabilidad del tiempo de fotograma).
  • Resolución y escalado: Dynamic Resolution 0.7x–0.8x con reescalado Spatial-Temporal Post-processing (STP) en modo Performance.
  • GPU Resident Drawer: Desactivado o limitado al agrupamiento (batching) del entorno estático únicamente (fallback automático a SRP Batcher si no hay soporte de hardware para Multi-Draw Indirect).
  • Iluminación y sombras: URP Forward+, 1 cascada de luz direccional (1024x1024), sombras puntuales desactivadas, Hard Shadows.
  • Texturas y memoria: Compresión ASTC 6x6 / 8x8, filtrado anisotrópico desactivado, límite de Texture Streaming de hasta 512 MB.
• Mid-Range Tier (Gama media / 60 FPS Standard):
  • Tasa de fotogramas objetivo: 60 FPS nativos sin caídas ni sobrecalentamiento.
  • Resolución y escalado: Nativa 1.0x (o adaptativa 0.85x–1.0x + modo STP Quality).
  • GPU Resident Drawer: Habilitado por completo, utilizando GPU Occlusion Culling basado en Compute Shaders.
  • Iluminación y sombras: URP Forward+ / Tile-Based Deferred, 2 cascadas de sombras (2048x2048), Medium Soft Shadows, hasta 4 fuentes de luz locales con sombras.
  • Texturas y memoria: Compresión ASTC 4x4 / 6x6, filtrado anisotrópico 2x–4x, límite de Texture Streaming de 1024 MB.
• Flagship / High-Refresh Tier (Gama alta / 120 FPS Gaming):
  • Tasa de fotogramas objetivo: 120 FPS / alta tasa de refresco (High Refresh Rate) nativa.
  • Resolución y escalado: Nativa 1.0x / Supersampling (STP Ultra Quality o FSR Mobile).
  • GPU Resident Drawer: Uso máximo junto con Entities Graphics e instanciación de transformaciones.
  • Iluminación и sombras: 4 cascadas de sombras (4096x4096), High Quality Soft Shadows, oclusión ambiental en espacio de pantalla (SSAO) de forma nativa mediante Render Graph, hasta 8 fuentes locales con sombras dinámicas.
  • Texturas y memoria: Compresión ASTC 4x4, filtrado anisotrópico 8x–16x, límite de Texture Streaming de 2048+ MB.

Lista de verificación final para la optimización de un proyecto 3D móvil en Unity 6:

• C# y DOTS: ¿Se migró la lógica masiva (IA, física de partículas, cálculo de trayectorias) a C# Job System y Entities? ¿Se verificó la ausencia de asignaciones de memoria en el bucle principal (Update()), es decir, 0 Bytes/frame en el Profiler? ¿Se desactivaron las Safety Checks para Burst Compiler en las compilaciones Release?
• GPU y Render Graph: ¿Se migraron todos los pases de renderizado personalizados a Render Graph API sin llamadas a CommandBuffer.Blit ni RT intermedios innecesarios que provocan el vaciado del caché en arquitecturas TBR/TBDR?
• Geometría y Geometry Streaming: ¿Está activado GPU Resident Drawer para todos los Mesh Renderer y materiales instanciados compatibles? ¿Se configuraron correctamente las distancias de cambio para los LOD Groups?
• Shaders: ¿Se realizó la depuración de palabras clave (Shader Keyword Stripping)? ¿Se reemplazó la matemática de alta precisión de float a half en Shader Graph para todas las plataformas móviles objetivo?
• Fotograma y pantalla: ¿Se configuró la gestión híbrida de la tasa de refresco a través de Application.targetFrameRate y Frame Pacing API para Android 15/16 e iOS 18+, evitando la desincronización de fotogramas a 120 Hz?