Los mapas de sombras virtuales (VSM) son el nuevo método de mapeado de sombras utilizado para proporcionar sombras coherentes y de alta resolución que funcionen con recursos de calidad cinematográfica y grandes entornos abiertos iluminados dinámicamente utilizando estas funciones de Unreal Engine 5: Geometría virtualizada Nanite, Iluminación global y reflejos Lumen y World Partition.
Finalidad de los mapas de sombras virtuales
Los mapas de sombras virtuales se han desarrollado con los siguientes objetivos:
Aumentar significativamente la resolución de las sombras para igualarlas a la detallada geometría Nanite
Sombras suaves plausibles con costes de funcionamiento razonables y controlables
Proporcionar una solución sencilla que funcione por defecto con una cantidad limitada de ajustes necesarios
Sustituir las numerosas técnicas de sombreado de luz estacionaria por una única ruta unificada
Conceptualmente, los mapas de sombras virtuales son solo mapas de sombras de muy alta resolución. En su implementación actual, tienen una resolución virtual de 16k x 16k píxeles. Los clipmaps se utilizan para aumentar aún más la resolución de las luces direccionales. Para mantener un alto rendimiento con un coste de memoria razonable, los VSM dividen el mapa de sombras en mosaicos (o páginas) de 128x128 cada uno. Las páginas se asignan y renderizan solo cuando es necesario para sombrear los píxeles en pantalla, basándose en un análisis del búfer de profundidad. Las páginas se almacenan en caché entre fotogramas, a menos que sean invalidadas por objetos en movimiento o por la luz, lo que mejora aún más el rendimiento.
Nanite no admite muchas de las técnicas de sombreado de luz estacionaria, como las presombras y las sombras por objeto (o inserción). Aunque algunas de las partes más dinámicas del sombreado de luz estacionaria pueden funcionar (como los mapas de sombras en cascada cerca del visor de la cámara), no se admiten luces Nanite ni estacionarias con mapas de sombras convencionales. Si utilizas Nanite en tu proyecto, debes utilizar luces móviles o mapas de sombras virtuales.
Cómo habilitar mapas de sombras virtuales
En los ajustes del proyecto, en Engine > Renderizado, en la sección Sombras, puedes establecer qué método de mapa de sombras admite tu proyecto: Mapas de sombras virtuales o Mapas de sombras convencionales, que se han utilizado en anteriores versiones de Unreal Engine.
Los proyectos existentes tendrán que optar por utilizar los ajustes del proyecto o la variable de consola r.Shadow.Virtual.Enable. Los nuevos proyectos utilizan mapas de sombras virtuales de forma predeterminada.
¿Qué ocurre con los métodos sombras existentes cuando se activan los VSM?
Cuando los VSM están activados, sustituyen a diversos métodos de sombras existentes en Unreal Engine:
Sombras estacionarias precalculadas, incluidos "mapas de sombras" con campo de distancia 2D y factor de sombra
Presombras
Sombras por objeto/inserción
Mapas de sombras en cascada (CSM)
Sombras dinámicas móviles para luces locales
Las sombras totalmente incorporadas de las luces estáticas seguirán funcionando como antes (cuando no utilices Lumen). Sus contribuciones se representan íntegramente en los mapas de luz incorporados y no se evalúa en absoluto la iluminación en tiempo de ejecución. Las luces estacionarias utilizarán la contribución difusa indirecta de cualquier mapa de luz incorporado, pero su iluminación directa y sus sombras se evalúan dinámicamente (igual que las luces móviles) cuando se activan los VSM.
Las sombras de campo de distancia no se sustituyen, y pueden utilizarse junto con los mapas de sombras virtuales para luces direccionales. Las sombras de campo de distancia toman el control de la geometría que no es de Nanite más allá de la distancia de sombra dinámica de las luces móviles (establecida en una luz direccional mediante la propiedad de mapas de sombras en cascada Luz móvil de distancia de sombra dinámica). El uso de sombras de campo de distancia proporciona una herramienta útil para reducir los costes de tiempo de ejecución en escenas complejas, como las que tienen mucho follaje que no es de Nanite.
La geometría Nanite siempre se renderiza en el mapa de sombras virtual, independientemente de la distancia, ya que es la opción más eficaz y proporciona la máxima calidad. Es posible hacer que la geometría no Nanite se comporte igual que la Nanite mediante la variable de consola r.Shadow.Virtual.UseFarShadowCulling 0.
Las luces locales (puntual y de punto de luz) no se ven afectadas, y la selección de sombras de campo de distancia para estas sigue anulando el método de mapa de sombras activo.
Gracias a la alta resolución y precisión de los VSM, la función de sombra de contacto en el espacio de pantalla, controlada con la propiedad de longitud de la sombra de contacto, ya no es necesaria para conseguir sombras de contacto nítidas. Todavía puede tener valor cuando se utiliza para recoger sombras más simples de objetos configurados para no renderizarse en mapas de sombras, pero no se recomienda en ningún otro caso, ya que será menos preciso que las sombras que crearán los VSM.
Las sombras trazadas por rayos siguen teniendo prioridad sobre los VSM, ya que suelen ofrecer la solución de mayor calidad.
Sombras suaves con trazado de rayos de mapa de sombras
El trazado de rayos de mapa de sombras (SMRT) es un algoritmo de muestreo que se utiliza con mapas de sombras virtuales para producir sombras suaves y endurecimiento de contacto más verosímiles. Los objetos que proyectan sombras más lejanas tendrán sombras más suaves que los objetos que proyectan sombras más cercanas a una superficie receptora de sombras. Por ejemplo, la malla que se muestra a continuación es alta y proyecta su sombra a gran distancia. Las sombras cerca de la base son más nítidas que las más alejadas.
Los métodos anteriores basados en el filtrado con porcentaje cercano (PCF) difuminaban en exceso y reducían el impacto visual de la geometría de alta resolución y las sombras.
El algoritmo SMRT funciona disparando una serie de rayos hacia la fuente de luz, pero en lugar de evaluar las intersecciones con la geometría (como hace el trazado de rayos convencional), se proyecta una serie de muestras a lo largo del rayo y se comprueban con el mapa de sombras virtuales para conseguir un sombreado suave y un endurecimiento de contacto. Los rayos de sombra se distribuyen en función de la luz utilizando el radio de fuente en las luces locales o el ángulo de fuente en las luces direccionales.
 |  |
Radio de la fuente de la luz local | Ángulo de la fuente de la luz direccional |
Las luces locales no tienen radio de origen por defecto, en comparación con las luces direccionales, que empiezan con un ángulo de fuente bajo. Cuando cualquiera de los dos se ajusta con un valor adecuado, el algoritmo SMRT produce sombras suaves en tiempo real con endurecimiento de contacto, como en el ejemplo siguiente, utilizando una luz puntual con un radio de fuente de 10.
Control de la calidad de la sombra de penumbra
La suavidad y calidad de la sombra de penumbra se establece mediante variables de consola, tanto para las luces locales como para las luces direccionales. Incluyen sus propios ajustes de escalabilidad que suelen ser buenos para la mayoría de las escenas.
El ruido en la penumbra se ve influido por el número de rayos que se utilizan, y tanto las luces locales como las direccionales utilizan ocho rayos por defecto cuando la escalabilidad de Sombra se establece en Epic.
Utiliza las variables de la consola r.Shadow.Virtual.SMRT.RayCountLocal y r.Shadow.Virtual.SMRT.RayCountDirectional para ajustar el número de rayos. Menos rayos muestran ruido visible en la penumbra. Si se pone a 0 la variable de consola asociada, se desactiva SMRT y se vuelve a las sombras duras de una sola muestra.
Además, el número de muestras de sombra tomadas a lo largo de la trayectoria de cada rayo puede ajustarse tanto para las luces locales como para las luces direccionales con el fin de controlar la suavidad máxima. Menos muestras de mapa de sombras son más baratas de renderizar, pero limitan la cantidad de suavidad de penumbra que se puede conseguir con las sombras de la luz.
Para lograr un control más fino que los ajustes de escalabilidad de Sombra utiliza las variables de consola r.Shadow.Virtual.SMRT.SamplesPerRayLocal y r.Shadow.Virtual.SMRT.SamplesPerRayDirectional para ajustar el número de muestras utilizadas. Utilizar valores entre 4 y 8 muestras funciona bien.
Arrastrar el control deslizante muestra qué sucede cuando una luz direccional con un ángulo fuente de 5.0 utiliza 0.2 y 8 muestras de mapa de sombras (por defecto).
Limitaciones del trazado de rayos del mapa de sombras
La calidad de SMRT suele ser buena con la configuración predeterminada, pero existen limitaciones inherentes al uso de los datos de una única proyección de mapa de sombras en lugar de realizar pruebas con la geometría real.
Límites del tamaño de la penumbra
La penumbra de la sombra se fija para las luces locales y direccionales con el fin de evitar la divergencia de la muestra respecto al origen del rayo, que puede «doblarse» cada vez más en comparación con la prueba ideal a lo largo del propio rayo. Utilizar valores razonables para el radio de fuente en las luces locales y el ángulo de fuente en las luces direccionales evitará resultados demasiado extremos, limitando la medida en que el rayo puede divergir de diversas maneras. Los valores demasiado grandes pueden afectar al rendimiento y hacer que las penumbras de las sombras se deformen visualmente cuando la cámara se acerca a ellas.
Las luces locales y direccionales pueden utilizar las variables de consola r.Shadow.Virtual.SMRT.MaxRayAngleFromLight y r.Shadow.Virtual.SMRT.RayLengthScaleDirectional para relajar o restringir las extensiones fijadas.
Penumbra incoherente
Como el mapa de sombras virtuales solo almacena la primera capa de profundidad, en la que la iteración ingenua pasa por alto las intersecciones con cualquier oclusor situado detrás del primero, pueden producirse diversos artefactos de fuga de luz donde se solapan los oclusores. Estos tipos de fugas de luz se resuelven mediante una heurística de relleno de huecos que extrapola las profundidades detrás del primer oclusor basándose en las profundidades observadas antes del punto de oclusión.
Esto funciona bien para resolver las fugas de luz, pero hace que las penumbras de las superficies paralelas a la luz disminuyan de tamaño. Actualmente no hay ninguna forma directa de contrarrestar este efecto, aparte de mantener unos tamaños de penumbra razonables.
Artefactos de penumbra
Por defecto, los mapas de sombras virtuales solo garantizan la presencia de las muestras alrededor del origen del rayo (el píxel receptor). A medida que el algoritmo recorre el rayo, puede encontrarse con páginas no asignadas en las que no existan datos de sombras. Se utilizan varias técnicas para reducir su impacto, como dilatar ligeramente las asignaciones de las páginas y disponer de varias alternativas durante la iteración. Aun así, pueden producirse ocasionalmente artefactos debidos a la falta de páginas, sobre todo en los bordes de la pantalla al hacer zoom en penumbras suaves. Estos artefactos se manifestarán como fugas de luz ruidosas en las zonas de sombra. Al igual que otras limitaciones de los VSM, la mayoría de los problemas pueden evitarse manteniendo un tamaño razonable de la penumbra de las sombras y evitando acercar el zoom hasta el punto de que cubran grandes partes de la pantalla.
Clipmaps para luz direccional
Un único mapa de sombras virtuales no proporciona suficiente resolución para cubrir grandes áreas. Las luces direccionales utilizan una estructura de clipmap de rangos en expansión alrededor de la cámara, y cada nivel de clipmap tiene su propio VSM de 16K. Cada nivel del clipmap tiene la misma resolución, pero cubre el doble del radio del anterior.
 |  |
Visualización del clipmap de luz direccional | Visualización de páginas del mapa de sombras virtuales |
Por defecto, a los niveles de clipmap del 6 al 22 se les asignan tablas de páginas de mapas de sombras virtuales. Esto significa que, con los ajustes predeterminados, el clipmap más detallado cubre 64 cm (2^6 cm) desde la posición de la cámara, y el más amplio cubre unos 40 kilómetros (2^22 cm). El coste de los niveles de clipmap virtuales es insignificante si no hay nada en ellos, por lo que estos valores predeterminados funcionan bien para cubrir escenas muy grandes con una resolución bastante alta cerca de la cámara.
El primer y el último nivel pueden ajustarse mediante las variables de consola `r.Shadow.Virtual.Clipmap.FirstLevel` y r.Shadow.Virtual.Clipmap.LastLevel.
La resolución asignada a un píxel determinado es función de la distancia al origen del clipmap: la cámara. Esto lo establece la escalabilidad de la sombra con la variable de consola r.Shadow.Virtual.ResolutionLodBiasDirectional. Un valor de 0 obtiene la resolución necesaria según la proyección en perspectiva de la cámara.
El aliasing proyectivo (cuando se proyecta una sombra sobre una superficie casi paralela a la dirección de la luz) sigue siendo posible, incluso a altas resoluciones, pero puede reducirse en parte sesgando la resolución. Al igual que el sesgo mip en las texturas, reducir el valor en -1 duplica la resolución de las sombras, con las compensaciones de rendimiento asociadas. El valor predeterminado de -1,5 en la escalabilidad Epic de las sombras proporciona un equilibrio razonable para muchas escenas.
Luces locales
Los puntos de luz utilizan un único VSM de 16K con una cadena mip en lugar de clipmaps para manejar el nivel de detalle de las sombras. Del mismo modo, las luces puntuales utilizan un mapa cúbico de 16 000 VSM, uno por cada cara.
Las luces locales proporcionan un aumento significativo de la resolución en comparación con los mapas de sombras tradicionales. Es posible quedarse sin resolución virtual con luces locales muy grandes, y en estos casos hay que procurar utilizar luces direccionales siempre que sea posible.
Los niveles mip adecuados se eligen proyectando el tamaño de los píxeles de la pantalla en el espacio del mapa de sombras. Al igual que las luces direccionales, es posible sesgar la resolución con los ajustes de escalabilidad de las sombras o utilizando la variable de consola r.Shadow.Virtual.ResolutionLodBiasLocal.
Los controles de resolución por luz no están disponibles, pero podrían añadirse en una futura versión.
Luces móviles
Las luces estacionarias se almacenan en gran medida en la memoria caché y, por lo tanto, pueden utilizar una resolución mucho mayor que las luces móviles. Para tener en cuenta esta diferencia entre luces estacionarias y móviles, las luces móviles deben tener una compensación del nivel de detalle diferente al de las luces estacionarias. Cuando una luz deja de moverse, realiza una transición gradual hacia la compensación original. Puedes controlar la compensación del nivel de detalle para luces móviles con las siguientes variables de escalabilidad de la consola:
r.Shadow.Virtual.ResolutionLodBiasLocalMovingr.Shadow.Virtual.ResolutionLodBiasDirectionalMoving
Superficies translúcidas
Los mapas de sombras virtuales admiten un filtrado de sombras de alta calidad para superficies translúcidas con Substrate y rutas heredadas. Esta es una función global opcional que puedes habilitar con la variable de consola r.Shadow.Virtual.TranslucentQuality. Esta variable de consola controla la calidad de las sombras para superficies iluminadas y translúcidas. Se aplica sobre todas las superficies translúcidas y tiene un gran impacto visual. Configuración de r.Shadow.Virtual.TranslucentQuality:
Cualquier valor superior a 1: sombras de alta calidad para superficies translúcidas iluminadas.
0 (predeterminado): sombras de calidad normal para superficies translúcidas iluminadas.
Páginas detalladas
El análisis del búfer de profundidad se utiliza como método principal para marcar las páginas que hay que renderizar. Sin embargo, hay algunos sistemas que necesitan muestrear las sombras en lugares más arbitrarios, como la niebla volumétrica y la translucidez directa. La mayoría de los sistemas solo necesitan datos de sombra de baja resolución que se filtran y difuminan a través de otras estructuras de datos.
Para tener en cuenta las sombras en estas situaciones, se debe marcar la opción Páginas detalladas para garantizar que al menos se disponga de datos de sombras de baja resolución en todo el dominio para el muestreo. Las luces locales se limitan a marcar la página mip raíz, mientras que las luces direccionales pueden marcar una serie de páginas con distintos niveles de detalle bajos para formar algunos clipmaps detallados. Según la escena, las páginas detalladas pueden crear problemas de rendimiento. Esto es especialmente cierto en el caso de la geometría dinámica que no es Nanite, ya que, en realidad, están renderizando sombras de baja resolución en grandes regiones del espacio, lo que puede provocar cuellos de botella en las llamadas de dibujo.
Se recomienda experimentar con la desactivación del renderizado de objetos no Nanite en las páginas detalladas utilizando la variable de consola r.Shadow.Virtual.NonNanite.IncludeInCoarsePages 0.
Muchas escenas (sobre todo las formadas principalmente por geometría Nanite) no necesitan objetos no Nanite que proyecten sombras sobre la niebla volumétrica y cosas similares. Desactivar esto puede mejorar significativamente el rendimiento.
Las páginas detalladas de luz local se pueden desactivar con r.Shadow.Virtual.MarkCoarsePagesLocal, si no se necesitan.
Las páginas detalladas de luz direccional se pueden desactivar con r.Shadow.Virtual.MarkCoarsePagesDirectional. El rango de niveles del clipmap en el que se marcan las páginas detalladas se puede modificar con r.Shadow.Virtual.FirstCoarseLevel y r.Shadow.Virtual.LastCoarseLevel.
En una futura versión, una solución más elegante sería que algunos de estos efectos pudieran marcarse para las páginas localizadas directamente por adelantado, en lugar de utilizar las páginas detalladas actuales (demasiado conservadoras).
Visualización
Se puede acceder a las opciones de visualización de los mapas de sombras virtuales desde el visor del nivel: menú desplegable Modos de visualización > Mapa de sombras virtuales.
Las opciones de visualización son:
| Nombre de la visualización | Descripción |
|---|---|
Máscara de sombra | La máscara de sombra final que utiliza el sombreado. |
Nivel de clipmap/mip | El nivel de clipmap (para luces direccionales) o mip (para luces locales) elegido. |
Página virtual | Visualización de la dirección de la página virtual. |
Página en caché | Las páginas almacenadas en caché aparecen en verde, las no almacenadas aparecen en rojo. Las páginas en las que solo se almacena en caché la página estática (no la dinámica) son azules. |
Por defecto, las visualizaciones del mapa de sombras virtuales muestran los resultados de la luz direccional. Si seleccionas una luz en el esquematizador, puedes ver visualizaciones de esa luz.
También puedes activar la visualización mediante la consola (excepto en las compilaciones de envío), lo que resulta útil para perfilar y depurar un juego en vivo. Si alguna de ellas se establece en el editor, anula cualquier selección de modo realizada a través de la interfaz de usuario del editor.
| Nombre de la visualización | Descripción |
|---|---|
| Cuando la visualización del modo de vista se establece en mapa de sombras virtuales a través del visor del nivel o comandos de consola, este comando especifica cuál de los canales debe mostrarse. Utiliza los nombres que aparecen a continuación en lugar de «[modo]» para activar esa visualización. Cache y vpage son dos de los más utilizados para la visualización y none desactiva la visualización de VSM.
|
| Activa la visualización del mapa de sombras virtuales cuando se especifica un modo de visualización. |
| Elige un diseño para la visualización del mapa de sombras virtuales.
|
| Muestra en la consola una lista de las luces actuales con mapas de sombras virtuales. En algunas configuraciones de compilación/ejecución, los nombres de las luces pueden ser diferentes de sus nombres en el editor. |
| Especifica una luz por su nombre; se aceptan coincidencias parciales o totales. Para impedir que se seleccione una luz mediante esta variable de consola, especifica un nombre de luz que no coincida con ningún otro. Utilizar dos comillas (") es una forma aceptable de restablecerla a una luz no especificada. |
Activar los modos de visualización tiene un efecto pequeño pero medible en el rendimiento de los mapas de sombras virtuales. Asegúrate de desactivar la visualización antes de crear el perfil de rendimiento.
Caché
Reutilizar páginas de mapas de sombras de fotogramas anteriores es clave para mantener un alto rendimiento con los mapas de sombras virtuales, especialmente en escenas complejas. El almacenamiento en caché está activado por defecto, pero puede desactivarse con fines de depuración mediante la variable de consola r.Shadow.Virtual.Cache 0. Los mapas de sombras virtuales respetan la distancia de supresión de Nanite cuando el almacenamiento en caché está habilitado.
Como las páginas solo se renderizan para los píxeles en pantalla, el cambio de visibilidad de la cámara debido al movimiento de la desoclusión puede revelar nuevas páginas que deban renderizarse. En general, mientras el movimiento de la cámara sea relativamente suave, no es una fuente importante de páginas nuevas. Por otro lado, debes tener cuidado con los movimientos muy rápidos cerca de los objetos, las grandes desoclusiones y los cortes de cámara.
En la mayoría de las escenas, la mayor carga de trabajo proviene de las páginas del mapa de sombras que hay que volver a dibujar debido a cambios en la geometría de la escena. Entre las causas habituales de invalidaciones de páginas de caché están:
Cualquier movimiento o rotación de la luz invalidará todas las páginas almacenadas en caché para esa luz.
La geometría que proyecta sombras al moverse, o al añadirse o eliminarse de la escena, invalidará las páginas que se solapen con su cuadro delimitador desde la perspectiva de la luz.
Esto puede incluir objetos como blueprints que establecen propiedades en componentes primitivos que activan la invalidación del estado de renderizado aunque en realidad no se mueva.
Geometría que utilice materiales que puedan modificar la posición de la malla, como el desfase de la posición en el mundo (WPO) o el desfase de profundidad de píxeles (PDO)
En los casos en que tengas una luz que se mueve lentamente, o una luz direccional que cambia la hora del día, las páginas de VSM no se almacenarán en caché en absoluto. En situaciones como los cambios de hora del día, se recomienda cuantificar los cambios en alguna pequeña cantidad para permitir que las páginas almacenadas en caché existan durante algún número de fotogramas, ya que las diminutas diferencias de dirección no serán perceptibles.
En una futura versión, se mejorará el almacenamiento en caché añadiendo un sistema de prioridades y presupuestos de actualización por fotograma para permitir un control más preciso del coste de renderizado de las sombras. Por ejemplo, permitir que la resolución de las sombras baje temporalmente en los casos en que haya que actualizar demasiadas páginas.
Gestión de las invalidaciones de la caché
La mejor forma de reducir las invalidaciones de la caché es visualizar primero las invalidaciones y luego encontrar y reducir lo que las causa. La visualización de página en caché es un buen punto de partida.
En esta visualización, las páginas que están totalmente almacenadas en caché están sombreadas en verde. Las páginas nuevas o invalidadas están sombreadas en rojo. Cuando muevas la cámara, verás pequeños anillos rojos cerca de los bordes de la pantalla, los límites del clipmap y la geometría desocluida. Con una cámara estática, la mayoría de las páginas nuevas procederán de las invalidaciones de la caché.
Si está activada la caché estática separada (ver más abajo), las páginas que están parcialmente en caché (en las que solo es válida la parte estática) aparecerán en azul.
Una vez encontradas las áreas problemáticas, suele ser útil además activar una visualización de los límites del objeto que están provocando las invalidaciones mediante la variable de consola r.Shadow.Virtual.Cache.DrawInvalidatingBounds 1. Inspecciona estos objetos y sus límites para asegurarte de que efectivamente son objetos que se espera que invaliden las sombras, y de que sus límites son lo más ajustados posible. Dado que deben invalidarse todas las páginas que un objeto invalidante podría llegar a solapar dentro de sus límites, incluso unos límites moderadamente inflados, combinados con ángulos de luz bajos, pueden provocar muchas invalidaciones innecesarias.
Las invalidaciones que están totalmente a la sombra de objetos Nanite pueden omitirse, pero esto no ocurre con los objetos que no son Nanite. Por esta razón, es especialmente importante asegurarse de que los grandes objetos que proyectan sombras (como los edificios) utilicen Nanite.
Puedes activar la invalidación del mapa de sombras virtuales en los cambios de transmisión del LOD de Nanite con la variable de consola r.Nanite.VSMInvalidateOnLODDelta. Los clústeres que no se transmiten a LOD que coincidan con la estimación de LOD de Nanite calculada activan la invalidación de VSM, de modo que se vuelven a renderizar cuando se completa la transmisión. Esta funcionalidad es experimental. No recomendamos enviar proyectos con funciones experimentales, ya que estas funciones están sujetas a cambios.
En escenas complejas, a veces puede ser difícil determinar con precisión qué está causando las invalidaciones, incluso con estas visualizaciones. Otra herramienta que puede ayudar es el modo de visualización Dibujar solo la geometría que provoca la invalidación del VSM, que se encuentra en el visor del nivel, en Mostrar > Visualizar.
Cuando esta opción está activada, se oculta cualquier geometría que no esté provocando invalidaciones de la caché.
Debido a detalles de implementación, el modo Dibujar solo la geometría que provoca la invalidación del VSM muestra ocasionalmente objetos no relacionados con las sombras (como partículas y efectos visuales) que pasan por un pase de renderizado separado y se dibujan encima.
Las estadísticas no son fiables cuando se utiliza esta visualización, porque renderizar la escena principal de forma diferente afecta a las páginas que se asignan e invalidan. Es mejor empezar con otros modos de visualización y utilizar este para una segunda comprobación.
Existe un problema conocido con los componentes de captura de escenas que puede provocar la invalidación de toda la caché.
Puedes anular el comportamiento predeterminado del motor para las invalidaciones de sombras con la clase de enumeración por formas primitivas Comportamiento de invalidación de caché de sombras. Esto es útil para evitar invalidaciones por desfase estático de la posición en el mundo (WPO). Las opciones son:
Automático (predeterminado): invalida en función del material de desfase de la posición en el mundo y los cambios de transformación
Siempre: invalida siempre las sombras. Se puede usar para marcar una forma primitiva que utiliza algún tipo de animación desconocido por el sistema.
Rígido: suprime las invalidaciones que, de otro modo, generaría, por ejemplo, el desfase de la posición en el mundo (WPO).
Estático: además del comportamiento Rígido, suprime también las invalidaciones debidas a cambios de transformación. Añadir/Eliminar sigue provocando invalidaciones. Si la forma primitiva es realmente movida o animada de alguna manera el resultado visual es indefinido.
Deformación y follaje no Nanite
La geometría que se puede deformar utilizando la animación esquelética, o los materiales con el desfase de la posición en el mundo o el desfase de profundidad de píxeles, siempre invalida las páginas almacenadas en caché de cada fotograma. Por definición, estos casos también deben ser no Nanite (mayor coste) y, por tanto, es sumamente importante asegurarse de que estas características se utilizan con cuidado y los límites se mantienen bajo control.
En algunos casos, como la hierba y a veces el follaje, usar solo sombras de contacto es un sustituto suficiente de los mapas de sombras de alta resolución. En los casos en que sean necesarias sombras de gran detalle en primer plano, ten en cuenta lo siguiente para ayudar a mitigar el coste de rendimiento:
Los objetos no Nanite siguen respetando los ajustes habituales de eliminación de CPU, como
r.Shadow.RadiusThreshold. Utilízalos para ayudar a controlar el coste de renderizado de estos objetos en los mapas de sombras virtuales.En escenas con mucho follaje, es muy recomendable desactivar los objetos no Nanite en páginas detalladas con
r.Shadow.Virtual.NonNanite.IncludeInCoarsePages 0. O incluso desactivar por completo las páginas detalladas si no se necesitan.Utiliza LOD de malla para cambiar a materiales que no utilicen WPO/PDO a distancias en las que el efecto ya no sea obvio. En algunos casos, puede ser posible desactivar la proyección de sombras dinámicas para estos objetos en la distancia y confiar totalmente en las sombras de contacto del espacio en pantalla.
Para las luces direccionales, hay más opciones disponibles:
Las sombras de campo de distancia toman el control de la geometría no Nanite más allá de la distancia de Luz móvil de distancia de sombra dinámica establecida por la sección de mapas de sombras en cascada de la luz. Cambiar a sombras de campo de distancia no Nanite en la distancia puede suponer una gran mejora del rendimiento, ya que esta geometría no tiene el escalado LOD de grano fino que proporciona Nanite.
Almacenamiento en caché estático separado
Esta función se considera experimental.
Muchas escenas constan de una gran cantidad de geometría estática que nunca se mueve, junto con cantidades significativamente menores de geometría dinámica (o móvil). Por defecto, esto significa que la geometría dinámica, relativamente barata, invalida páginas que luego hacen que se vuelva a renderizar la costosa geometría estática, solo para actualizar la parte dinámica.
Para optimizar mejor en estos casos, se puede activar un modo opcional de caché estática separada utilizando r.Shadow.Virtual.Cache.StaticSeparate 1. Este modo duplica el tamaño del conjunto de páginas físicas para que la geometría estática de una página determinada pueda almacenarse en caché separadamente de la geometría dinámica. Incluso cuando la geometría dinámica se mueve, no es necesario volver a dibujar la geometría estática. En su lugar, la página estática almacenada en caché puede componerse encima a bajo coste. En casos como el del proyecto de muestra Valley of the Ancients, puede suponer una importante optimización del rendimiento, ya que el terreno estático es muy costoso, mientras que los elementos dinámicos tienen relativamente menos coste.
Al utilizar este modo, es importante ajustar con precisión la movilidad de los actores en la escena. En concreto, si un actor configurado con movilidad estática se mueve (o incluso utiliza un material con desfase de la posición en el mundo o materiales similares no admitidos), invalida tanto las páginas en caché dinámicas como las estáticas, lo que se traduce en pura sobrecarga sin ninguna ganancia. Por el contrario, si gran parte de la geometría costosa se establece con movilidad móvil, puede resultar poco beneficioso almacenarla en caché por separado.
Las estadísticas del mapa de sombras virtuales son una buena forma de obtener una visión general de alto nivel de lo bien que está funcionando la caché estática. En concreto, el número de páginas estáticas «invalidadas» debería ser cercano a 0. Encontrar instancias que estén invalidando la caché estática con frecuencia y cambiarlas a móviles es una forma importante de garantizar que la caché estática siga siendo válida.
Nanite incluye un modo de visualización avanzado para ayudar a determinar la movilidad de los objetos en el entorno, que también es útil para los mapas de sombras virtuales.
Este modo de visualización puede activarse de dos formas:
Activa las opciones avanzadas de visualización de Nanite con
r.Nanite.Visualize.Advanced 1y luego utiliza el visor del nivel para seleccionar Modo de visualización > Visualización Nanite y elige Mapa de sombras virtuales - Estático en la lista de opciones de visualización.Haz clic en la imagen para verla a tamaño completo. Alternativamente, puedes activar la visualización estática del mapa de sombras virtuales con el comando
r.Nanite.Visualize vsmstatic.
Creación de perfiles y optimización de la GPU
Unreal Engine proporciona herramientas que te ayudan a comprobar el rendimiento de tus proyectos, y el creador de perfiles de GPU (o una herramienta específica de la plataforma) es un buen punto de partida para solucionar y depurar los problemas de rendimiento.
Hay dos categorías principales de rendimiento en las que aparecerán los costes del VSM: Profundidades de sombra y Proyección de sombra (bajo Luces). Las compensaciones en cada una de sus categorías son relativamente independientes entre sí.
Ten en cuenta que los comandos utilizados para listar estadísticas, como stat gpu y los contadores asociados, pueden proporcionar tiempos poco fiables, especialmente si el rendimiento de tu proyecto está ligado a la CPU.
Profundidades de sombra
La categoría Profundidades de sombra se refiere al coste de renderizar la geometría en mapas de sombras.
RenderVirtualShadowMaps(Nanite) contiene toda la renderización de la geometría Nanite en VSM. Todas las luces direccionales se renderizan en un solo pase de Nanite y todas las luces locales se hacen en un segundo pase.
RenderVirtualShadowMaps(Non-Nanite) se encarga de renderizar la geometría no Nanite. Cada luz visible tiene un pase independiente con llamadas de dibujo individuales para varios objetos e instancias, igual que el renderizado convencional de mapas de sombras.
Atlas y Cubemap, junto con otros pases similares, después de las pases del VSM renderizan mapas de sombras convencionales. Todavía hay un pequeño número de tipos de geometría que no se admiten en la ruta de mapas de sombras virtuales, y esos siguen la ruta antigua. Si no hay geometría no compatible proyectando sombras, estos pases no se ejecutarán ni asignarán almacenamiento al mapa de sombras. Estas pasadas y la sobrecarga asociada pueden deshabilitarse completamente con la variable de consola
r.Shadow.Virtual.ForceOnlyVirtualShadowMaps 1, en cuyo caso cualquier tipo de geometría no soportada simplemente no proyectará sombras.
El coste del pase de profundidades de sombra con los VSM está directamente relacionado con cuántas páginas de sombra hay que renderizar y cuánta geometría hay que renderizar en ellas. Cuesta mucho más renderizar geometría no Nanite en los VSM que geometría Nanite. Por esta razón, se recomienda activar Nanite en toda la geometría compatible, incluidas las mallas de bajo poligonaje. La única excepción son las características que aún no son compatibles con la geometría virtualizada Nanite.
Cómo comprender el número de páginas que se dibujan
Las estadísticas en pantalla de las páginas de VSM usadas pueden dar una idea de cuántas páginas se están utilizando y dónde buscar para resolver posibles problemas.
Utiliza sucesivamente las siguientes variables de consola para activar las estadísticas:
r.ShaderPrintEnable 1r.Shadow.Virtual.ShowStats 1(o 2 para mostrar solo las estadísticas de la página)
| Nombre de la estadística | Descripción |
|---|---|
Páginas físicas | El número máximo de páginas físicas que pueden utilizar los mapas de sombras. |
Asignadas | El número total de páginas del mapa de sombras solicitadas por la vista actual. Siempre debe ser inferior al número máximo de páginas, de lo contrario puede producirse corrupción. (Consulta la sección Problemas y limitaciones más abajo.) |
Borradas | El número de páginas nuevas que se borraron en el fotograma actual. |
En caché | El número de páginas que ya están en la caché de páginas del mapa de sombras virtuales y que no necesitan ser renderizadas en el fotograma actual. Las páginas almacenadas en caché tienen un coste muy bajo y apenas repercuten en el rendimiento. Cuando se activa la caché estática separada, esta se divide a su vez en páginas estáticas en caché y páginas dinámicas en caché. |
Invalidadas | El número de páginas almacenadas en caché que fueron invalidadas por geometría dinámica en el fotograma anterior. Hay que volver a renderizar estas páginas porque se ha movido algo que las cubre. Cuando se utiliza la caché estática separada, lo ideal es que el número de invalidaciones de páginas estáticas sea cero o casi cero. Si se está invalidando un gran número de páginas estáticas, el actor o los actores causantes de las invalidaciones deberían pasar a Móvil. |
Fusionadas | Cuando está activada la caché estática separada, es el número de páginas en las que se fusionaron las páginas dinámicas y estáticas (debido a que una u otra no se almacenaron en caché). |
Los recuentos totales de páginas son una función del número medio de luces que afectan a cada píxel de la pantalla. Pueden reducirse disminuyendo la resolución de la pantalla, la resolución de las sombras (con variables de consola para la compensación del nivel de detalle de resolución), la extensión de las luces o el número de luces que proyectan sombras.
El bajo rendimiento en las profundidades de sombra se asocia normalmente a que se utiliza un elevado número de páginas y a que se producen muchas invalidaciones dinámicas, lo que provoca un mal almacenamiento en caché de los VSM. Consulta la sección Almacenamiento en caché para ver más detalles sobre cómo diagnosticar y reducir las invalidaciones de la caché.
Cómo mejorar el rendimiento no Nanite
Además de mejorar el almacenamiento en caché, hay varias formas de mejorar el rendimiento del renderizado de sombras que no sean Nanite.
Considera lo siguiente para mejorar el rendimiento de los objetos no Nanite:
Activa Nanite en toda la geometría posible para tu proyecto.
La geometría Nanite se renderiza de forma mucho más eficiente en mapas de sombras virtuales y debería preferirse en todos los casos aplicables, independientemente del recuento de polígonos.
La geometría Nanite puede ocluir la geometría no Nanite y evitar invalidaciones espurias de la caché. Por tanto, los únicos objetos no Nanite deben ser los que no admite el propio Nanite, como los objetos deformables (mallas con apariencia) o los materiales que utilizan desfase de la posición en el mundo (WPO) y desfase de profundidad de píxeles (PDO).
Los objetos no Nanite deben tener configuradas todas las jerarquías de LOD de malla.
Es importante que las mallas no Nanite tengan configurados los LOD; de lo contrario, resultarán extremadamente costosas de renderizar en páginas pequeñas.
Siempre que sea posible, es aconsejable pasar a mallas no deformantes (sin materiales WPO/PDO) más allá de una distancia en la que el efecto sea evidente.
Las variables de consola de eliminación de CPU siguen siendo útiles para las mallas no Nanite que se renderizan en mapas de sombras virtuales.
Ajusta los valores de eliminación de CPU en objetos no Nanite renderizados en mapas de sombras virtuales con la variable de consola
r.Shadow.RadiusThreshold. Puede ayudar a controlar el coste de los objetos pequeños en la distancia.
Uso de sombras de campo de distancia para la sombra lejana de objetos no Nanite.
Para las luces direccionales, a menudo es necesario cambiar a sombras de campo de distancia más allá de cierto rango, igual que los mapas de sombras en cascada. Con los mapas de sombras virtuales, solo la geometría no Nanite pasará a utilizar sombras del campo de distancia, mientras que la geometría Nanite seguirá teniendo sombras con todo detalle.
Desactivar la geometría no Nanite en las páginas detalladas puede aumentar el rendimiento.
Desactivar la geometría no Nanite en las páginas detalladas a menudo puede suponer una gran ganancia de rendimiento, ya que la geometría no Nanite suele ser ineficiente para renderizar en páginas grandes.
Las estadísticas de los mapas de sombras virtuales pueden dar una idea de los recuentos de instancias que no son Nanite:
| Nombre de la estadística | Descripción |
|---|---|
Total | Número total de instancias no Nanite introducidas en la eliminación de GPU. Las instancias se seleccionan por separado para cada nivel mip/clipmap de mapa de sombras virtuales. Por ejemplo, una sola instancia de malla estática puede dar lugar a 48 instancias (8 niveles mip * 6 caras de cubemap) por cada luz puntual que intersecte, 17 instancias por cada luz direccional (en la configuración por defecto hay 17 niveles de clipmap), etc. |
Dibujadas | Número de instancias realmente dibujadas en todos los mapas de sombras virtuales después de la eliminación. |
HZB - Eliminadas | Número de instancias eliminadas por estar ocluidas (por geometría Nanite) desde la perspectiva de la luz. |
Máscara página - Eliminadas | Número de instancias eliminadas por no solapar ninguna página requerida. Esto, por ejemplo, representa mallas estáticas que se descartan al dibujar en zonas ya almacenadas en caché. |
Rect vacía - Eliminadas | Número de instancias eliminadas por no solapar ninguna página requerida. Esto, por ejemplo, representa mallas estáticas que se descartan al dibujar en zonas ya almacenadas en caché. |
Campo de visión - Eliminadas | Número de instancias que estaban fuera del marco de visión. |
Proyección de sombras
La categoría Proyección de sombras es el coste del muestreo de mapas de sombras mediante el trazado de rayos del mapa de sombras. Estos pases se encuentran en Luces | Iluminación directa | Luces sin combinar y normalmente habrá un pase de proyección VSM por cada luz asociada. El pase más costoso suele ser el bucle principal del SMRT en Proyección de mapas de sombras virtuales. El resto debería tener un coste relativamente bajo.
Si el pase de proyección se etiqueta como RayCount:Static en lugar de RayCount:Adaptive, se está tomando un camino lento.
El pase de proyección VSM descrito en esta sección es diferente de la proyección experimental de una pasada descrita en la sección siguiente.
La proyección de sombras es puramente una función del número total de muestras del mapa de sombras que se toman a través de la pantalla, y el rendimiento no depende del número de páginas ni del almacenamiento en caché.
Cuando se utiliza SMRT, se reduce a:
Promedio de luces por píxel
Cuantas más luces toquen grandes partes de la pantalla, más costoso será el renderizado. Las luces que cubren un número reducido de píxeles en pantalla son menos costosas, aunque sigue habiendo algunos costes fijos por luz.
Hay que tener cuidado para evitar que la mayoría de los píxeles de la pantalla estén ocupados por varias luces grandes.
Rayos por píxel
La suavidad visible de las sombras afecta al rendimiento debido al número de rayos adaptable. Prueba a reducir el radio de origen de las luces locales o el ángulo de origen de las luces direccionales antes de reducir cualquiera de los recuentos de rayos y muestras.
Muestras por rayo
Estos ajustes se establecen mediante el ajuste de escalabilidad Sombra, pero pueden ajustarse más si es necesario. Consulta la sección Trazado de rayos del mapa de sombras de esta página para obtener más detalles.
En general, los costes de proyección de sombras son mucho más fáciles de controlar (compromiso con la calidad y el ruido) que los costes de profundidad de sombras.
Proyección de un pase
Esta función se considera experimental. Es probable que los nombres de las variables de consola de esta sección cambien.
Aunque las luces más pequeñas tienen un coste menor, siguen teniendo algunos gastos fijos de pase. Esto se aborda desarrollando una solución de proyección de sombras de un solo pase, en la que la mayoría de las luces locales de una escena pueden evaluar eficazmente sus sombras en jun solo pase. La contribución sombreada de estas luces puede aplicarse entonces toda a la vez utilizando el sombreado agrupado.
Esta ruta se activa mediante las variables de consola r.UseClusteredDeferredShading 1 y r.Shadow.Virtual.OnePassProjection 1. Para escenas con muchas luces locales pequeñas, esto puede suponer mejoras significativas en el rendimiento.
El uso de ciertas características de la luz impedirá que una luz se procese por lotes aunque esté activada la proyección de un pase:
Perfiles de textura
Funciones de la luz
Canales de iluminación
Luces rectas
Luces direccionales (no hay ninguna ventaja en que estén agrupadas, ya que cubren toda la pantalla)
En las capturas de abajo, la izquierda muestra un pase de proyección de sombras por luz, en comparación con la proyección de un pase de la derecha.
Haz clic en la imagen para verla a tamaño completo.
En la trayectoria por defecto de la izquierda, cada luz local se acumula una a una con varios pases por luz. Esto es ineficaz para luces pequeñas que cubren una superficie de pantalla reducida.
En el nuevo trazado de la derecha, todas las luces locales sombreadas se agrupan en un solo pase de sombreado agrupado (Luces por lotes). La luz direccional se sigue haciendo en un pase aparte; cubre toda la pantalla y, por tanto, no es una ventaja procesarla por lotes.
Cada luz local sigue inyectándose en el volumen de translucidez por separado. Esto es menos problemático para el rendimiento que la proyección, pero es probable que también se agrupen en el futuro.
Cuando está activada la proyección de un pase, es posible limitar el número de luces en sombra que se filtran completamente por píxel ajustando r.Shadow.Virtual.OnePassProjection.MaxLightsPerPixel desde el valor predeterminado de 16. Esto es útil tanto para controlar el rendimiento como para ahorrar una pequeña cantidad de memoria gráfica transitoria.
Si hay más luces sombreadas que el máximo en un píxel determinado (o, en la práctica, en un mosaico de sombreado diferido agrupado), las luces adicionales se sombrearán utilizando una búsqueda de sombra dura única y económica. Esto puede provocar discontinuidades visuales si el valor se establece de forma demasiado agresiva, pero suele ser más indulgente que desactivar por completo las sombras de las luces que superan el recuento.
Este pase aún está en desarrollo y no está activado por defecto. La principal advertencia es que, en los casos en que una luz local tenga tanto un mapa de sombras virtuales como un mapa de sombras clásico (debido a algún tipo de geometría no admitida en la escena), la ruta de proyecciones de un pase ignora este último, haciendo que desaparezcan esas sombras.
Si ya estás usando r.Shadow.Virtual.ForceOnlyVirtualShadowMaps, debería ser seguro activar también la proyección de un pase. Una vez que se hayan solucionado las limitaciones actuales, probablemente se convertirá en la ruta utilizada por defecto.
Plataformas compatibles
Actualmente, los mapas de sombras virtuales son compatibles con PlayStation 5, Xbox Series S|X y PC con tarjetas gráficas que cumplan estas especificaciones, utilizando los controladores más recientes con DirectX 12:
NVIDIA: tarjeta de la generación Maxwell o posteriores.
AMD: tarjeta de la generación GCN o posteriores.
Se admiten todas las versiones más recientes de Windows 10 (anteriores a la versión 1909.1350) y Windows 11 compatibles con SDK DirectX 12 Agility.
Windows 10, versión 1909: el número de revisión debe ser igual o superior a 1350.
Windows 10, versión 2004 y 20H2. El número de revisión debe ser superior o igual a .789.
DirectX 12 (con atómicos de Shader Model 6.6) o Vulkan (VK_KHR_shader_atomic_int64).
Chip de Apple M2 o modelos posteriores.
Linux con NVIDIA GeForce 2080 o modelos posteriores.
Controladores gráficos más recientes
Para obtener más información sobre las especificaciones de hardware y software recomendadas por Epic Games, consulta la sección Especificaciones de hardware y software.
Problemas y limitaciones
Los mapas de sombras virtuales siguen desarrollándose activamente. Actualmente existen una serie de problemas y limitaciones conocidos para su uso (de momento afectan a ordenadores de sobremesa de gama alta y consolas de nueva generación).
Rendimiento de varias luces
Todavía se está trabajando en el rendimiento en escenas con muchas luces locales pequeñas. De momento, la mejor estrategia es activar la proyección de un solo pase y tener mucho cuidado con las invalidaciones para mantener en caché el mayor número posible de páginas. Las luces locales múltiples funcionarán mucho mejor con la geometría Nanite que con la geometría no Nanite, por lo que eliminar o desactivar agresivamente la proyección de sombras en la geometría no Nanite en la distancia puede ayudar mucho. En algunos casos puede ser conveniente desactivar por completo la proyección de sombras dinámicas en las luces distantes y basarse únicamente en las sombras de contacto del espacio en pantalla.
En el futuro, se dispondrá de mejores controles para hacer concesiones algorítmicas y de calidad, así como para provocar actualizaciones en estas situaciones.
Geometría de baja poligonización
La geometría de baja poligonización con mucha curvatura y normales suaves puede presentar artefactos. Esto se conoce como el «problema del terminador de sombras». También ocurre en el trazado de rayos y en otras consultas de visibilidad de gran precisión. El problema se debe al desajuste entre la geometría real de baja poligonización y las normales de sombreado «suaves»: en la zona cercana al terminador, algunas de estas caras están geométricamente en sombra, pero las normales de sombreado no geométricas están ligeramente orientadas hacia la luz. Es habitual solucionar este problema con un sesgo basado en la normalidad para la búsqueda de sombras. Este artefacto concreto puede ser más perceptible con los mapas de sombras virtuales porque, de manera predeterminada, están configurados para proporcionar sombras muy detalladas de la geometría Nanite.
La mejor forma de solucionar esto es aumentar el número de polígonos en estos objetos/regiones. Limitar la divergencia entre las normales geométricas y de sombreado reduce o elimina estos artefactos sin afectar negativamente a la calidad de las sombras en otros puntos. Con Nanite, añadir más polígonos es sencillo y, en general, poco costoso. Si los objetos infractores no pueden utilizar Nanite, a menudo también funciona bien añadir un mayor nivel de detalle (LOD), ya que estos artefactos son visibles sobre todo cuando los objetos están cerca de la cámara.
Si no es posible añadir más geometría, se puede aumentar el sesgo normal del mapa de sombras virtuales utilizando r.Shadow.Virtual.NormalBias (valor predeterminado: 0.5). Ten en cuenta que esto solo debe considerarse cuando no sea posible realizar ajustes de contenido, ya que afectará negativamente a la calidad de las sombras en toda la escena, pero especialmente en las zonas de detalles finos.
En los ejemplos siguientes, los artefactos son visibles en una esfera con baja poligonización cerca de la cámara, con geometría de gran detalle en el fondo. Añadir polígonos a la esfera mejora los artefactos sin afectar negativamente al detallado paisaje del fondo.
Ajustar el sesgo también mejora los artefactos, pero se pierden visiblemente los detalles finos en la geometría del fondo.
Realidad virtual
La realidad virtual aún no es totalmente compatible con los mapas de sombras virtuales. Es probable que haya artefactos en las luces direccionales en el ojo derecho.
Pantalla dividida
La pantalla dividida ha sido sometida a pruebas mínimas y puede tener un rendimiento deficiente.
Desbordamiento del grupo de páginas físicas
Con los mapas de sombras virtuales, todos los datos de sombras de la escena para todas las luces se almacenan en un único gran grupo de texturas. El tamaño predeterminado del grupo se ve afectado por el ajuste de escalabilidad Sombras, pero puede ser necesario ajustarlo en escenas con muchas luces que utilicen sombras de alta resolución.
También puede ser necesario ajustarlo en hardware de gama baja para ahorrar memoria de vídeo.
El tamaño del grupo de páginas puede ajustarse mediante r.Shadow.Virtual.MaxPhysicalPages. Activar las estadísticas del mapa de sombras virtuales con r.ShaderPrintEnable 1 y r.Shadow.Virtual.ShowStats 2, sucesivamente, mostrará estadísticas sobre el uso actual del grupo de páginas.
Si el número de páginas supera el máximo de páginas se producirá corrupción, que a veces se manifiesta visualmente como un patrón en damero, o sombras dañadas o ausentes. Si se desborda el grupo de páginas de sombras, se muestra una advertencia en pantalla y en el registro.
Si esto ocurre, aumenta el tamaño del conjunto de páginas o disminuye la resolución de la sombra o el número de luces de proyección del mapa de sombras virtual.
Captura de escena
En algunos casos, los componentes de captura de escena pueden hacer que se invalide toda la caché del mapa de sombras virtuales. Los síntomas de esto suelen manifestarse como que las invalidaciones son bajas en las estadísticas del mapa de sombras virtual, pero las páginas en caché también son bajas (o a veces incluso cero) y la visualización de la página en caché es uniformemente roja.
Si esto ocurre, intenta ocultar/eliminar cualquier actor de captura de escena en la escena para verificar si están causando el problema.
Actualmente no hay otra solución que desactivar la captura de escena cuando esto ocurre.
Materiales
Solo admite materiales subsuperficiales sencillos. El perfil subsuperficial y la transmisión aún no están implementados. Si un material los utiliza, ese material se sombreará como si fuera opaco.
Resolución de sombras
Los mapas de sombras virtuales proporcionan una resolución significativamente mayor que los mapas de sombras convencionales, pero los ángulos de luz poco profundos (o aliasing proyectivo) y las luces locales muy grandes pueden agotar la resolución virtual disponible. Esto puede presentarse como sombras en forma de caja y problemas de sesgo en función de la superficie de la geometría.
Los clipmaps de luz direccional son mucho menos susceptibles de quedarse sin resolución, pero los campos de visión de cámara muy estrechos también pueden acabar agotándolos.
No hay una solución sencilla para resolver el aliasing proyectivo con mapas de sombras. Incluso con los mapas de sombras virtuales, hay que tener cierto cuidado para evitar los peores casos y equilibrar la resolución con el rendimiento.
Advertencias de comprobación de mapas
Los mapas de sombras virtuales hacen que se produzcan algunos avisos de comprobación de mapas inexactos:
El mensaje Es preciso reconstruir la iluminación no aparece cuando están activados los mapas de sombras virtuales, aunque de hecho haya que reconstruir la iluminación cuando no se utilizan las funciones de iluminación global y reflejos Lumen. Mientras que la iluminación directa estacionaria es dinámica con los mapas de sombras virtuales activados, la iluminación indirecta estacionaria sigue siendo incorporada.
Las advertencias relativas a las presombras pueden ignorarse, ya que no son relevantes cuando se utilizan mapas de sombras virtuales.