Resolución de problemas y Rendimiento de Luces

Las luces pueden ser renderizadas mediante uno de los dos métodos siguientes:

• Vertex lighting calcula la iluminación únicamente en los vértices e interpola los valores en dichos vértices sobre el resto de la superficie. Algunos efectos de iluminación no están soportados por vertex lighting pero es el método más económico en términos de procesamiento. También, puede ser el único método disponible para tarjetas gráficas antiguas.

• Pixel lighting se calculada de manera separada por cada pixel en la pantalla. Pese a ser un método más lento para renderizar, pixel lighting permite algunos efectos que no son posible con vertex lighting. Normal-mapping, light cookies y realtime shadows son efectos renderizados únicamente con pixel lights. Además, las formas de foco y el punto de luz se ven mucho mejor cuando se renderizan con dicho modo.

Las luces tienen un gran impacto en la velocidad de procesamiento, por lo que la calidad de la iluminación se tiene que equilibrar con la velocidad de los fotogramas (framerate). Desde que las pixel lights tienen un coste mayor procesamiento que verte lights. Unity únicamente renderizará las luces más brillantes en modo mixel y el resto las tratará como vertex lights. El número máximo de pixel lights se puede establecer en Quality Settings para webplayer y desarrollos standalone.

Puede configurar una luz para que sea renderizada como pixel light utilizando la propiedad Render Mode. Una luz con el modo establecido a Important tendrá mayor prioridad a la hora de decidir si es tratada como una pixel light. Con el modo configurado a Auto (por defecto), Inuty la clasificará automáticamente en base a cómo se ve afectado un objeto por la luz. Las luces que están renderizadas como pixel lights se determinan sobre una base de objeto-por-objeto.

Vea la página sobre Optimizing Graphics Performance para más información.

Rendimiento de las Sombras

Las sombras en tiempo real tienen un alto coste a la hora de ser renderizadas, por lo que deben ser usadas con moderación. Cualquier objeto que pueda emitir sombras primero debe ser renderizado en el mapa de sombras y luego este mapa se utilizará para renderizar los objetos que pueden recibir sombras. Habilitando las sombras tiene un impacto mayor en el rendimiento que la disyuntiva pixel/vertex mencionada anteriormente.

Las sombras suaves tienen un mayor coste de procesamiento que las sombras duras pero esto solo afecta a la GPU y no genera tanto trabajo extra para la CPU.

Los Quality Settings (Ajustes de Calidad) incluyen un valor de Shadow Distance (distancia de sombra).Los objetos que están más allá de esta distancia de la cámara serán renderizados sin sombras. Puesto que las sombras de objetos distantes no suelen ser observadas, puede ser una buena optimización reducir el número de sombras que deben ser renderizadas.

Un tema particular con las luces direccionales es que una sola luz puede iluminar toda la escena. Esto significa que el mapa de sombras cubrirá a menudo una gran parte de la escena a la vez y esto puede generar en las sombras un problema conocido como “perspective aliasing”. Esto significa que los pñixeles del mapa de sombras cercanos a la cámara se ven ampliados y “gruesos” en comparación con los más alejados. Aunque puede aumentar la resolución del mapa de sombras para reducir este efecto, el resultado que los recursos de renderizado se desperdician para áreas distante cuyo mapa de sombras se veían bien con resoluciones bajas.

Una buena solución al problema es usar mapas de sombra separados que disminuyan en resolución a medida que la distancia con respecto a la cámara aumenta. Estos mapas separados son conocidos como cascades (cascadas). Desde Quality Settings, puede elegir cero, dos o cuatro cascadas; Unity calculará el posicionamiento de las cascadas dentro del cono de visualización de la cámara. Tenga en cuenta que las cascadas sólo se habilitan para luces direccionales. Consulte la página directional light shadows para más detalles.

How the Size of a Shadow Map is Calculated

The first step in calculating the size of the map is to determine the area of the screen view that the light can illuminate. For directional lights, the whole screen can be illuminated but for spot lights and point lights, the area is the onscreen projection of the shape of the light’s extent (a sphere for point lights or a cone for spot lights). The projected shape has a certain width and height in pixels on the screen; the larger of those two values is then taken as the light’s “pixel size”.

When the shadow map resolution is set to High (from the Quality Settings) the shadow map’s size is calculated as follows:

• Directional lights: NextPowerOfTwo(pixelSize * 1.9), up to a maximum of 2048.
• Spot lights: NextPowerOfTwo(pixelSize), up to a maximum of 1024.
• Point lights: NextPowerOfTwo(pixelSize * 0.5), up to a maximum of 512.

If the graphics card has 512MB or more video memory, the upper shadow map limits are increased to 4096 for directional lights, 2048 for spot lights and 1024 for point lights.

At Medium shadow resolution, the shadow map size is half the value for High resolution and for Low, it is a quarter of the size.

Point lights have a lower limit on size than the other types is because they use cubemaps for shadows. That means that six cubemap faces at this resolution must be kept in video memory at once. They are also quite expensive to render, as potential shadow casters might need to be rendered into all six cubemap faces.

Limited Memory Conditions

If your game is running very low on video memory then it will automatically reduce the resolution of shadow maps below the usual value.

Generally, the screen data (backbuffer, frontbuffer, depth buffer) and data for render textures must be held in video memory. The memory needed to store the screen and render texture data will be subtracted from the total available; one third of the remaining video memory will then be reserved for use by shadow maps. The resolution of any given shadow map will be reduced as far as necessary to fit into this space (ie, the calculations given above are still applied but with the reduced resolution).

Assuming all regular textures, vertex data and other graphics objects could be swapped in and out of video memory, the theoretical maximum amount of VRAM that could be used by a shadow map would be given by the formula (TotalVideoMemory - ScreenMemory - RenderTextureMemory). However, the amounts of memory taken by screen and render textures can never be determined exactly. Furthermore, some objects should not be swapped; performance would suffer badly if all textures were constantly swapped in and out, for example. To allow for this, Unity does not allow a shadow map to exceed one third of “generally available” video memory, and this compromise is found to work quite well in practice.

Troubleshooting Shadows

If you find that one or more objects are not casting shadows then you should check the following points:

• Old graphics hardware may not support shadows. See below for a list of minimal hardware specs that can handle shadows.

• Shadows can be disabled in the Quality Settings. Make sure that you have the correct quality level enabled and that shadows are switched on for that setting.

• All Mesh Renderers in the scene must be set up with their Receive Shadows and Cast Shadows correctly set. Both are enabled by default but check that they haven’t been disabled unintentionally.

• Only opaque objects cast and receive shadows so objects using the built-in Transparent or Particle shaders will neither cast nor receive. Generally, you can use the Transparent Cutout shaders instead for objects with “gaps” such as fences, vegetation, etc. Custom Shaders must be pixel-lit and use the Geometry render queue.

• Objects using VertexLit shaders can’t receive shadows but they can cast them.

• With the Forward rendering path, some shaders allow only the brightest directional light to cast shadows (in particular, this happens with Unity’s legacy built-in shaders from 4.x versions). If you want to have more than one shadow-casting light then you should use the Deferred Shading rendering path instead. You can enabled your own shaders to support “full shadows” by using the fullforwardshadows surface shader directive.

Hardware Support for Shadows

Built-in shadows work on almost all devices supported by Unity. The following cards are supported on each platform:

Windows

• AMD Radeon: all GPUs.
• NVIDIA GeForce: all GPUs except GeForce FX (around year 2003) series.
• Intel: all GPUs except 915/945/GMA950 (around year 2004).

Mac OS X

• All GPUs supported by OS X can render shadows.

iOS, Android y Windows Phone

• iOS: GL_EXT_shadow_samplers support. Most notable, iPhone 4 does not support shadows (iPhone 4S does support them already).
• Android: Android 4.0 or later, and GL_OES_depth_texture support. Most notably, some Android Tegra 2/3-based Android devices do not have this, so they don’t support shadows.
• Windows Phone: support varies by OS and model; typically Adreno 225 and 305 GPUs don’t support shadows.

Consolas

• Todas las consolas soportan sombras.