UDN
Search public documentation:

PerfDebug_DynamicLightEnvironments
日本語訳
中国翻译
한국어

Interested in the Unreal Engine?
Visit the Unreal Technology site.

Looking for jobs and company info?
Check out the Epic games site.

Questions about support via UDN?
Contact the UDN Staff

UE3 Home > Technical & Programming Home > Performance and Memory > Peformance Debugging: Dynamic Light Environments

Peformance Debugging: Dynamic Light Environments

Click here to return to the Performance Debugging page.

Dynamic Light Environments

Problem:

Dynamic light environment updates are showing up as expensive.

Solutions:

All InterpActors (aka Movers) and KActors have a dynamic light environment by default. When a DLE updates however, it does line checks to light sources, which can add quite a lot of CPU cost. However, there are various options you can set that reduce the cost of lighting on dynamic objects.

Here are the light environment settings from most expensive to least (on the game thread) and when they should be used:

1) bEnabled=True, bDynamic=True (the default)

These should only be used where needed, they will update based on InvisibleUpdateTime and MinTimeBetweenFullUpdates. There probably shouldn't be more than 50 of these active at any given time. They do extra visibility checks when visible, close to a player or when they are moving.

2) bEnabled=True, bDynamic=False, bForceNonCompositeDynamicLights=True

These should be very cheap, the environment is updated on the first tick and never again. bForceNonCompositeDynamicLights is necessary to allow dynamic lights to affect them, which doesn't have any significant game thread overhead. There can be hundreds of these, the only cost (after the first tick) will be line checks to dynamic lights (and only when the owner is visible). These look better than using precomputed shadows because they can rotate and the lighting will still be correct. They are used by fractured meshes, GDO's, and some other things. If you guys see significant cost with these then it can probably be optimized quite a bit on the code side.

3) bEnabled=False, bUsePrecomputedShadows=True (on the primitive component). Also, you'll have to take it out of the dynamic channel and put it in the static lighting channel.

These will be lightmapped, very cheap to render and should have virtually no game thread overhead (except that the UDynamicLightEnvironmentComponent::Tick function is still called). They will look wrong when moved.

There is a console command that can be used to see how many light environments are active. Type SHOWLIGHTENVS at the console and you will get a list of all environments that got ticked that frame. The output should look like:

Log: LE: SP_MyMap_01_S.TheWorld:PersistentLevel.InterpActor_12.DynamicLightEnvironmentComponent_231 1
Log: LE: SP_MyMap_01_S.TheWorld:PersistentLevel.InterpActor_55.DynamicLightEnvironmentComponent_232 0
Log: LE: SP_MyMap_01_S.TheWorld:PersistentLevel.InterpActor_14.DynamicLightEnvironmentComponent_432 1 ...

A '1' at the end of the line means bDynamic is set to TRUE. This should be used to guide level designers to change their map to reduce update overhead.

Feedback

Do you have questions or comments about performance and memory in the engine? Post your question right here!

Click here to return to the Performance Debugging page.