Ajuste de la tasa de fotogramas en escenas 3DGS en UE5

Paso uno: localizar el cuello de botella

Antes de cambiar cualquier parámetro, confirmar que la caída de la tasa de fotogramas la provoca el 3DGS. La iluminación, las sombras, el posprocesado, los modelos normales y la lógica de Blueprint de la escena pueden ser todos el verdadero cuello de botella, y en ese caso ningún ajuste de los parámetros de LCC ayuda.

Confirmar que el cuello de botella procede del 3DGS

Ocultar o eliminar todo lo que hay en la escena aparte del 3DGS y comparar la tasa de fotogramas:

1. Registrar la tasa de fotogramas actual como referencia (stat fps o stat unit).
2. Ocultar el LCC Actor, mantener el resto de la escena y registrar la tasa de fotogramas.
3. Hacer lo contrario: mantener solo el LCC Actor, ocultar o eliminar los demás modelos, luces, volúmenes de posprocesado y UI, y registrar la tasa de fotogramas.

Cuando la escena original tiene muchos elementos y ocultarlos uno por uno resulta impracticable, un enfoque más limpio consiste en crear un nivel vacío con un único LCC Actor que cargue los mismos datos y registrar después la tasa de fotogramas desde el mismo punto de vista. Eso elimina toda interferencia de la escena original y da la referencia de rendimiento del propio 3DGS.

Comparar los tres conjuntos de valores:

Descartar los elementos predeterminados de la escena del motor

Un nivel nuevo incluye un conjunto de Actors predeterminados, y varios de ellos no son baratos, así que se confunden fácilmente con el coste del 3DGS. El caso más típico es VolumetricCloud: realiza un ray marching volumétrico en cada fotograma y sigue consumiendo GPU aunque solo se vea un pequeño trozo de cielo.

Cuando el proyecto no necesita efectos de cielo, eliminar los siguientes Actors del nivel:

Los datos 3DGS normalmente ya contienen información de entorno, así que estos efectos son innecesarios en la mayoría de los casos. Medir de nuevo la tasa de fotogramas después de eliminarlos y valorar entonces si todavía hay que ajustar los parámetros de LCC.

Mantener fijas las condiciones de prueba, ya que de lo contrario los valores no se pueden comparar: el mismo mapa y el mismo punto de aparición, la misma posición o trayectoria de cámara, la misma resolución y el mismo Screen Percentage, y el mismo estado de activación de Lumen, los virtual shadow maps, el posprocesado y SceneCapture. Ejecutar una pasada de calentamiento antes de registrar los datos para que la primera compilación de shaders y la primera lectura de disco no se mezclen con la tasa de fotogramas estable. Cambiar una categoría de ajustes a la vez.

Comandos de observación habituales:

stat fps         // Tasa de fotogramas
stat unit        // Los cuatro tiempos de fotograma: Frame / Game / Draw / GPU
stat gpu         // Desglose de los Pass de GPU
stat rhi         // Draw calls, primitivas, memoria de vídeo
ProfileGPU       // Detalle por fotograma de los Pass de GPU

Usar las estadísticas de LCC una vez confirmado el 3DGS

Abrir el panel de estadísticas con Actions > Stats en el panel del Actor, o escribir stat xgrids en la consola.

Consultar las estadísticas de rendimiento en tiempo real de LCC con stat xgrids

Para los detalles de los parámetros, consultar Parámetros de rendimiento: estadísticas

Centrarse en Current Render Main Splats y Current Render Nodes: la causa directa de la mayoría de los problemas de rendimiento es un número excesivo de puntos renderizados en pantalla a la vez.

Activar a la vez la visualización del LOD

Mientras se leen las estadísticas, usar Actions > Debug Node Bound en el panel del Actor para visualizar los Levels de los nodos y confirmar directamente la distribución de LOD de la vista actual. Los colores más cálidos indican un Level más bajo y más detalle.

La idea de la optimización es reducir los puntos en pantalla tanto como el aspecto lo permita, con atención a hasta dónde llega el Level 0:

• ¿Hasta dónde llegan las zonas de colores cálidos de la imagen? ¿Se necesitan realmente los datos de máxima precisión a esa distancia?
• Si el cambio a Levels más gruesos se produce antes, ¿se percibe la pérdida de aspecto?

En la mayoría de las escenas el Level 0 llega más lejos de lo que realmente se necesita, y hacer que cambie antes a Levels más gruesos baja el número de puntos de inmediato, lo que resulta lo más efectivo de todas las opciones. Una vez confirmado el margen, pasar al paso dos y ajustar Level Factor.

Paso dos: ajustar el LOD

Es el paso con el beneficio más evidente. En la mayoría de las escenas el Level 0 llega mucho más lejos de lo que realmente se necesita, y hacer que cambie antes a Levels más gruesos baja el número de puntos en pantalla de inmediato, normalmente sin ningún cambio perceptible en el aspecto. Realizar este paso primero y considerar después las opciones posteriores.

El LOD tiene tres controles independientes (Level Factor, Start Level, End Level)

Configurar Level Factor, Start Level y End Level

2.1 Determinar primero cómo funciona Level Factor

Los dos pipelines seleccionan los Levels mediante mecanismos distintos, así que Level Factor también funciona de forma distinta, pero el sentido es el mismo: cuanto mayor es el valor, antes cambian los nodos a Levels de menor detalle.

Pipeline LCC2: error en espacio de pantalla

LCC2 no usa RangeForLevel; en su lugar calcula un error en espacio de pantalla para cada nodo: cuántos píxeles cubre el error geométrico del propio nodo al proyectarse en la pantalla. Cuando el error supera el umbral, refina hacia nodos hijos más finos; en caso contrario se queda en el Level actual.

Este error se ve afectado a la vez por la distancia del nodo, el ángulo de visión y la resolución de pantalla, así que el mismo Level Factor no produce la misma distancia de cambio real a distintas resoluciones o FOV. Eso significa también que la distribución de LOD de LCC2 no se puede calcular por adelantado a partir de una tabla de distancias y solo se puede observar en la práctica con Debug Node Bound del apartado 2.5.

El ajuste funciona igual que en el pipeline LCC, así que se puede pasar directamente a la escala de pruebas del apartado 2.2.

Pipeline LCC: tabla de distancias

Level Factor divide el array global RangeForLevel por su valor. Cuanto mayor es el valor, más corta es la distancia efectiva de cada Level y antes entran los nodos en un Level de menor detalle.

Valores predeterminados de RangeForLevel (11 elementos, ProjectSettings > Plugins > LCC4Unreal > Level):

Level:  0    1    2    3    4    5    6    7    8    9    10
metros: 15   50   80  110  140  170  190  220  250  280   350

Distancias efectivas después de dividir por Level Factor (en metros, los valores no enteros se muestran redondeados):

Cómo leer esta tabla: con Level Factor = 2, el detalle máximo se aplicaba antes dentro de 15 metros y ahora se aplica solo dentro de 7,5 metros. Eso es mucho más preciso que decir «la mitad del detalle»: lo que cambia es la distancia efectiva de cada Level, no la proporción de puntos.

La forma exacta en que los Levels se comparan con las distancias (límite superior o inferior, intervalo abierto o cerrado) es un detalle interno de implementación. La tabla anterior sirve para estimar cuánto ajustar; confirmar la distribución real de Levels con Debug Node Bound del apartado 2.5. Esta tabla se aplica únicamente al pipeline LCC.

Más allá del último elemento de RangeForLevel, un nodo simplemente usa el Level más grueso del que dispone, así que nunca se da el caso de no encontrar ningún Level. Aumentar Max Distance por encima de 350 metros no requiere, por tanto, ajustar esta tabla.

Configurar el array de distancias Range For Level en la configuración del proyecto

2.2 Level Factor

Para el rango y el valor predeterminado, consultar Parámetros de rendimiento: Level Factor

Es el control de LOD preferente, porque es gradual y no elimina de golpe todo un Level de detalle.

Escala de pruebas:

1.0 → 1.25 → 1.5 → 2.0

Comprobar primero: contornos, líneas finas, objetos pequeños, detalle del suelo y zonas de transición entre Levels. Estos lugares son los primeros en delatar la falta de detalle y los saltos de LOD.

Cambios del LOD después de ajustar Level Factor

2.3 Start Level

Para el rango y el valor predeterminado, consultar Parámetros de rendimiento: Start Level

Aumentarlo descarta directamente los Levels de numeración más baja (los más finos):

0 → 1 → 2

Es mucho más agresivo que un pequeño cambio de Level Factor: descarta Levels completos en lugar de escalar distancias. Usarlo solo cuando se cumplan ambas condiciones: que stat xgrids muestre que Level0 Splats realmente es el coste principal, y que una calidad más gruesa de cerca sea aceptable. Volver a 0 cuando el campo cercano se vea visiblemente borroso.

Omitir los Levels de detalle alto después de aumentar Start Level

2.4 End Level (normalmente se deja como está)

Para el rango y el valor predeterminado, consultar Parámetros de rendimiento: End Level

Reducirlo limita el Level más grueso que se puede usar: los Levels más gruesos de los datos no se usan nunca, el contenido lejano solo puede quedarse en End Level, y se renderizan más puntos de los necesarios. No es un botón de aceleración, así que conviene mantener el valor predeterminado a menos que ya se conozca la estructura de Levels de los datos.

Debe cumplirse Start Level <= End Level; el setter no lo valida.

Limitar los Levels de detalle bajo después de ajustar End Level

2.5 Verificar con Debug Node Bound

Actions > Debug Node Bound en el panel del Actor visualiza los límites de los nodos y sus Levels. La secuencia de colores es rojo, naranja, amarillo, verde, azul y morado, donde el rojo es el Level más bajo (el detalle más alto) y el blanco representa el Level más alto (el detalle más bajo).

Usarlo para comprobar después de cambiar los parámetros de LOD: si el campo cercano sigue siendo rojo/naranja (detalle alto), si la lejanía pasa suavemente a colores fríos, y si alguna zona sigue alternando de Level a la misma distancia.

Comprobar la distribución de LOD con Debug Node Bound

Puntos de verificación del LOD

• Si el número de nodos y el número de splats bajan;
• Si el campo cercano se vuelve grueso demasiado pronto;
• Si aparecen saltos de LOD evidentes mientras se mueve la cámara;

Paso tres: distancia máxima de renderizado

Para el rango y el valor predeterminado, consultar Parámetros de rendimiento: Max Distance(m)

Establecer la distancia máxima de renderizado Max Distance

En qué se diferencia del LOD

Max Distance elimina directamente los datos más allá de la distancia y reduce el rango espacial renderizable; el LOD baja la precisión dentro del rango. Ambos son complementarios: usarlo para ajustar más el rango cuando siga habiendo presión después de ajustar el LOD.

Puede reducir los nodos candidatos junto con el trabajo de recorrido, carga, subida, ordenación y relleno que viene después, pero cuánto reduce depende de la implementación y de los datos, así que conviene verificarlo con estadísticas reales en lugar de suponer una proporción fija de ganancia.

Marcar primero la casilla en línea, o los cambios no hacen nada

Todos los parámetros de la categoría Performance tienen una casilla a su izquierda. Mientras la casilla está desmarcada, el valor del campo de texto no tiene efecto, y en tiempo de ejecución se usa el valor predeterminado interno del plugin. Comprobar esto primero cuando un ajuste no hace nada.

Pasos para ajustar la distancia

1. Situarse en la posición de la escena donde los datos del modelo deben verse a mayor distancia, y medir la distancia realmente necesaria.
2. Marcar la casilla situada a la izquierda del parámetro.
3. Establecerlo en «la distancia máxima visible real + el margen necesario».
4. Ajustarlo paso a paso; no bajar de golpe a un valor muy bajo:

300 m (predeterminado) → 225 m → 150 m → ajuste fino a la distancia real del proyecto

Lo anterior es una escala de pruebas, no un valor recomendado. Los valores razonables difieren mucho entre interiores, manzanas urbanas, escenas grandes y vistas aéreas, así que hay que medirlos en cada proyecto.

Cambios del rango de renderizado después de ajustar Max Distance

Puntos de verificación de la distancia

• Si Current Render Nodes y Current Render Splats bajan;
• Si bajan los ms de GPU o Traversal Time;
• Si el contenido desaparece de forma brusca al caminar hasta el límite de distancia;
• Si las zonas sin cargar se vuelven más fáciles de ver mientras se avanza rápido;

Paso cuatro: establecer un límite estricto de puntos

Para el rango y el valor predeterminado, consultar Parámetros de rendimiento: Max Splat Num

Max Distance controla el rango espacial, pero la densidad de los datos dentro del mismo rango puede variar enormemente. Max Splat Num proporciona un techo de carga de trabajo por fotograma que evita que el número de puntos se dispare al entrar en una zona de densidad alta. Complementa al LOD y a la distancia, y no puede sustituir a ninguno de los dos.

Tener en cuenta que los valores demasiado grandes se recortan automáticamente a la cantidad que la GPU puede renderizar en un fotograma; llevar el valor del panel hasta el límite no supera la capacidad del hardware y solo hace que el techo resulte inoperante. Para que funcione de verdad, establecerlo por debajo del número real de puntos de la vista actual.

Establecer el límite de puntos por fotograma Max Splat Num

Pasos para ajustar el límite de puntos

1. Marcar la casilla situada a la izquierda del parámetro.
2. Reducirlo proporcionalmente desde el valor predeterminado, en unidades de 10.000:

3000 → 2250 → 1500 → 1000

3. Después de cada reducción, observar en una zona de densidad alta, no solo en zonas abiertas.

Cambios del número de puntos y de la imagen después de ajustar Max Splat Num

Puntos de verificación del límite de puntos

• Si los ms de GPU y Current Render Splats bajan junto con el límite;
• Si aparecen adelgazamientos locales, parpadeos o estructuras transparentes rotas.

Si después de bajar el límite no cambian ni el número de puntos ni los ms de GPU, la vista actual nunca alcanza ese límite y no es el cuello de botella actual, así que hay que volver al paso uno y localizarlo de nuevo.

Paso cinco: reducir el coste de relleno de píxeles

5.1 SplatScale

Para los detalles del parámetro, consultar Ajustes visuales: SplatScale

Reducirlo baja el área de pantalla que cubre un solo splat y con ello reduce el solapamiento de transparencias.

Método: bajarlo en pequeños pasos desde el valor de calidad actual, y comprobarlo a alta resolución, en el campo cercano y a lo largo de los contornos de los objetos. Bajarlo demasiado hace que las superficies muestren huecos o parezcan notablemente delgadas.

Ajustar SplatScale para reducir el área de pantalla que cubren los puntos gaussianos

5.2 Small Splat Threshold (px) (solo pipeline LCC2)

Para el rango y el valor predeterminado, consultar Parámetros de rendimiento: Small Splat Threshold (px)

Probarlo en vivo con una CVar, sin necesidad de reiniciar:

r.LCC2.SmallSplatThreshold 0
r.LCC2.SmallSplatThreshold 0.5
r.LCC2.SmallSplatThreshold 1

Cuanto mayor es el valor, mayor es la ganancia potencial y más evidente el grano a lo lejos. Aumentarlo más solo cuando la GPU o el cálculo de SH realmente sean el cuello de botella; cuando los propios datos no tienen SH, la ganancia de omitir los SH es limitada.

Establecer el umbral en píxeles Small Splat Threshold

5.3 Quad Extent Threshold (solo pipeline LCC2)

Para el rango y el valor predeterminado, consultar Parámetros de rendimiento: Quad Extent Threshold

Aumentar este valor produce quads más ajustados y reduce el overdraw, pero puede cortar los bordes semitransparentes.

r.LCC2.QuadExtentThreshold 0.006 → 0.008 → 0.01

Revertirlo cuando los contornos se endurezcan, falten bordes o las formas de los splats parezcan incorrectas.

Establecer Quad Extent Threshold para controlar la extensión del quad del splat

5.4 Frustum Cull Margin (solo pipeline LCC2)

Para el rango y el valor predeterminado, consultar Parámetros de rendimiento: Frustum Cull Margin

Controla el margen del descarte, no el límite de puntos.

Probar a bajarlo hacia 1.0 en pequeños pasos solo mientras no aparezcan apariciones bruscas en el borde de la pantalla:

r.LCC2.FrustumMargin 1.2 → 1.1 → 1.0

Que el contenido parpadee en el borde al girar la cámara rápidamente significa que se ha bajado demasiado.

Establecer el margen de descarte por frustum Frustum Cull Margin

5.5 Anti-aliasing

El coste en GPU del anti-aliasing no es bajo, y con TSR resulta especialmente notable. Cuando la escena contiene solo 3DGS y ninguna malla normal ni UI, establecer la opción correspondiente en None suele perder muy poca calidad de imagen mientras la ganancia de tasa de fotogramas es considerable.

Para el método predeterminado de cada pipeline y las contrapartidas, consultar Parámetros de rendimiento: Anti-aliasing Methods.

Configurar el método de anti-aliasing de cada pipeline de LCC

Paso seis: desactivar las funciones que no se necesitan

Las ganancias de este paso son claras, pero cada una tiene un coste funcional, así que conviene confirmar elemento por elemento que el proyecto realmente no la necesita en lugar de desactivarlo todo.

Para las descripciones detalladas de cada función, consultar Ajustes visuales y Parámetros de rendimiento.

Paso siete: ordenación y memoria de vídeo

La ordenación de translucidez y la gestión de la memoria de vídeo se tratan por pipeline: Sort Factor y la precarga adicional existen solo en LCC1, y el presupuesto de memoria de vídeo de GPU existe solo en LCC2.

7.1 Sort Factor (solo pipeline LCC)

Para el rango y el valor predeterminado, consultar Parámetros de rendimiento: Sort Factor

Se aplica a la tabla global SortFrequencyForLevel y controla con qué frecuencia se vuelven a ordenar los nodos de cada Level. Cuanto mayor es el valor, menos ordenaciones y mejor rendimiento, pero el orden de transparencia se actualiza más despacio después de que cambien la cámara o los nodos, lo que puede provocar errores breves de interpenetración.

Establecer Sort Factor para ajustar la frecuencia de ordenación del LCCActor

Configurar la Sort Frequency de cada Level de LOD

7.2 Extra Preload Nodes (solo pipeline LCC)

Para el rango y el valor predeterminado, consultar Parámetros de rendimiento: Add Extra Preload Nodes

Su finalidad es mitigar los huecos en el borde de la pantalla durante los giros rápidos, a cambio de más trabajo de nodos.

Esta opción tiene dos capas de estado y es fácil equivocarse:

• Mientras la casilla de la izquierda está desmarcada, recurre al valor predeterminado interno, así que el resultado efectivo sigue siendo activado;
• Para desactivarla de verdad, marcar primero la casilla y establecer después el valor en desactivado.

Desactivarla solo cuando las estadísticas muestren que el número de nodos y la precarga son realmente una carga clara y el proyecto pueda aceptar huecos en el borde durante los giros rápidos. Restaurarla en cuanto aparezcan huecos; no conviene tapar unos datos que no están listos añadiendo hilos.

Configurar los nodos de precarga adicionales para mitigar los huecos durante los giros rápidos

7.3 LCC2 GPU Memory Budget (solo pipeline LCC2)

Para el rango y el valor predeterminado, consultar Parámetros de rendimiento: LCC2 GPU Memory Budget (MB)

Establecer el presupuesto de memoria de vídeo LCC2 GPU Memory Budget

Cuenta únicamente los datos de posición, color y armónicos esféricos de un solo modelo LCC2. Aumentar el presupuesto puede ayudar solo en estos casos:

• La GPU todavía tiene suficiente memoria de vídeo libre;
• Los tirones se producen sobre todo al entrar en una zona nueva o al trabajar con varios viewports.

No reduce el número de splats, el trabajo de ordenación ni la cobertura de píxeles. Sin problemas de expulsión ni de fragmentación, aumentar el presupuesto solo incrementa la memoria de vídeo residente sin mejorar la tasa de fotogramas.

Pasos de ajuste:

1. Registrar primero el pico de memoria de vídeo de toda la máquina, no solo el presupuesto de LCC.
2. Empezar desde el valor predeterminado y aumentar en pasos de 1024 MB.
3. Reiniciar el motor después de cada cambio.
4. Volver a probar los puntos de vista más exigentes, todas las vistas de SceneCapture / nDisplay y las ejecuciones largas.
5. Dejar memoria de vídeo para las texturas de escena de UE, los Render Targets, Nanite, Lumen, VSM, los buffer de ordenación y el sistema operativo.

No establecerlo en 8192 MB sin una monitorización completa de la memoria de vídeo.

El log también imprime un desglose del uso de memoria de vídeo, que se puede usar para comprobar si el presupuesto es razonable:

GPU footprint: %u slots (%s), %.2f MB total - gaussian %.2f, SH %.2f, sort %.2f (1 view), other %.2f MB

El elemento sort es el buffer de ordenación. El log se calcula para 1 vista, así que hay que escalarlo por el número de vistas cuando hay varios viewports.

Paso ocho: carga, hilos, memoria

8.1 No añadir hilos en primer lugar (solo pipeline LCC)

Para el rango y el valor predeterminado, consultar Parámetros de rendimiento: Thread Pool Settings

Añadir hilos puede aumentar la concurrencia de CPU, y también puede aumentar la contención entre hilos, los cambios de contexto, la presión momentánea sobre el disco y los picos de subida. Los hilos de exportación no tienen relación directa con el renderizado en tiempo de ejecución, así que ajustarlos no mejora la tasa de fotogramas.

Criterio: solo cuando las estadísticas muestren que la cola correspondiente se acumula mientras la CPU todavía tiene núcleos libres, añadir de 2 a 4 hilos cada vez y volver a probar. Cuando la CPU ya está saturada, reducir la carga de trabajo en lugar de añadir más hilos.

Si el elemento Create Thread sigue mostrando coste de tiempo, el grupo de hilos se está expandiendo repetidamente, así que hay que ajustar el número de hilos precreados en lugar del límite superior.

8.2 Splat Number For Discard Per Node (solo pipeline LCC)

Para el rango y el valor predeterminado, consultar Parámetros de rendimiento: Splat Number For Discard Per Node

Establecer el umbral de descarte de splats dispersos por nodo

Su intención es ignorar los nodos extremadamente dispersos: algunos conjuntos de datos contienen muchos nodos que solo tienen uno o dos splats, y gestionar esos nodos cuesta más de lo que aportan a la imagen.

Aumentarlo puede reducir el coste de gestión de los nodos de baja densidad, y también puede eliminar detalle aislado. Comprobarlo en líneas finas, ramas de árbol, barandillas y objetos pequeños lejanos en lugar de mirar solo la tasa de fotogramas general. Recargar los datos después de cambiarlo, o el resultado en pantalla seguirá siendo el anterior.

8.3 Umbrales de liberación de memoria y de memoria de vídeo

Configurar los umbrales de uso y liberación de memoria de CPU y GPU

Para el rango y el valor predeterminado de los cuatro umbrales, consultar Parámetros de rendimiento: categoría Usage

Es una política de liberación bajo presión de memoria, no un control habitual de la tasa de fotogramas:

• Un umbral demasiado bajo o un porcentaje de liberación demasiado grande → puede provocar una oscilación de «liberar, recargar, liberar de nuevo»;
• Un umbral demasiado alto → puede retrasar la liberación y aumentar la presión sobre la memoria del sistema y la memoria de vídeo;
• Ajustarlo solo después de que las pruebas de larga duración confirmen presión de memoria o expulsiones repetidas.

Valorarlo por la relación entre CPU Occupy Percentage / GPU Occupy Percentage y los umbrales correspondientes, y por si Released CPU Node Num / Released GPU Node Num sigue creciendo. En la captura, un uso de memoria de vídeo del 86 % ya supera el umbral del 80 % y el recuento de liberaciones de memoria de vídeo llegó a 1943, lo que es una señal típica de presión de memoria de vídeo.

Paso nueve: varios viewports, colisión, agua

9.1 Varias cámaras y SceneCapture

Cada vista adicional que participa realmente en el renderizado puede añadir trabajo de recorrido, renderizado u ordenación; LCC2 añade además un buffer de ordenación por vista.

Comprobar elemento por elemento:

1. Si algún SceneCapture está sin usar pero sigue actualizándose en cada fotograma;
2. Si la resolución del Render Target es demasiado alta;
3. Si la frecuencia de actualización tiene que ser realmente cada fotograma;
4. Si ShowOnlyActors contiene solo el contenido necesario;
5. Si el minimapa puede cambiar a PointCloud o a una resolución más baja;
6. Si nDisplay, la pantalla partida o MRQ crearon vistas adicionales a la vez.

Usar Camera Num(Render) de stat xgrids para confirmar que el número de vistas que realmente se renderizan coincide con lo esperado; Camera Num es el número de cámaras que participan en las actualizaciones, y ambos pueden diferir. Un valor mayor de lo esperado significa que algunas vistas se están renderizando sin saberlo.

SceneCaptureComponent Support se puede desactivar cuando no se usa SceneCapture en absoluto; consultar Parámetros de rendimiento.

Configurar SceneCaptureComponent Support para varios viewports

9.2 Modo de recorrido

Para el rango y el valor predeterminado, consultar Parámetros de rendimiento: Default Traversal Type

Seleccionar el modo de recorrido predeterminado Frustum o Circle

Circle se adapta a las pantallas curvas, a nDisplay y a las panorámicas de 360 grados que necesitan datos en todas las direcciones del entorno; Frustum es la referencia predeterminada para un solo viewport.

No conviene cambiar un proyecto normal de una sola cámara a Circle solo para «evitar que falten trozos en alguna dirección»: eso incorpora al recorrido todo el rango circular alrededor de la cámara, mientras que el modo de frustum procesa únicamente la parte visible. Si el flujo de trabajo requiere Circle, ajustar en consecuencia Max Distance, el límite de puntos y la resolución de los varios viewports.

El pipeline LCC2 no necesita ajustar esta opción; mantener Frustum.

9.3 Colisión y navegación

Para la descripción de la función, consultar Colisión y Compatibilidad con Navigation System. Este apartado cubre solo las contrapartidas de rendimiento.

Con la colisión desactivada no hay distancia de colisión que ajustar. Una vez activada, las lecturas de colisión, el baking físico asíncrono y las actualizaciones del NavMesh pueden añadir coste de CPU, memoria y tirones. Tener en cuenta que ese coste no necesariamente aparece en los FPS y requiere inspeccionar por separado las estadísticas relacionadas con la colisión.

Para el rango y el valor predeterminado de la distancia de colisión, consultar Parámetros de rendimiento: Max Load Collision Distance(m)

1. Desactivar la colisión por completo en los proyectos que solo son de presentación.
2. Cuando se necesita colisión, marcar la casilla situada a la izquierda del parámetro y establecer Max Load Collision Distance(m) en el rango de interacción real.

Establecer la distancia de carga de colisión Max Load Collision Distance

Cambios dinámicos del rango de colisión después de ajustar la distancia de carga de colisión

3. No conviene establecer mecánicamente la distancia de renderizado y la distancia de colisión en el mismo valor. Que algo se vea a lo lejos no significa que allí se necesite colisión física.
4. Reducir la distancia de colisión limita directamente el rango disponible para la interacción del jugador y la IA, así que hay que ejecutar una regresión funcional después de cambiarla en lugar de mirar solo la tasa de fotogramas.

La estrategia es la contraria cuando se usa la navegación: la distancia de colisión debe cubrir la mayor parte posible de la zona accesible al jugador para que la colisión de esas zonas se cargue en una sola pasada. La colisión se carga dinámicamente por bloques, e intercambiar un bloque de colisión nuevo en tiempo de ejecución provoca una reconstrucción de los datos de navegación, lo que causa tirones notables.

Puntos complementarios:

• Hacer que NavMeshBoundsVolume cubra el rango de actividad del jugador, y confirmar que la colisión dentro de ese rango está cargada por completo
• Preferir el horneado Static y evitar el horneado Dynamic, ya que este último se reconstruye continuamente cada vez que cambia la colisión

9.4 Single Layer Water (solo pipeline LCC2)

Para la descripción de la función y la configuración completa, consultar Compatibilidad con single layer water. Este apartado cubre solo las contrapartidas de rendimiento.

SingleLayerWater Support es una opción global de la configuración del proyecto, pero su implementación depende de la profundidad media de LCC2, así que no surte efecto en los Actors del pipeline LCC.

• Mantenerla desactivada cuando no se usa single layer water;
• Se requiere reiniciar después de activarla;
• El coste es que los píxeles del agua pierden la calidad de sombra de los virtual shadow maps, lo que es una contrapartida funcional más que puramente de rendimiento;
• Activarla solo cuando el 3DGS queda ocluido incorrectamente por un material de single layer water.