UDN
Search public documentation:

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

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 > Particles & Effects > Particles Systems > VFX Optimization in UE3 > VFX Optimization: Core Concepts
UE3 Home > FX Artists > VFX Optimization in UE3 > VFX Optimization: Core Concepts

VFX Optimization: Core Concepts


Identifying GPU, Render Thread, and Game Thread issues


There are several features of UE3 in place which allow effects artists to trouble shoot performance issues. First off identifying where your effects are creating bottlenecks will go a long way towards optimizing the correct issue, thereby retaining visual integrity/quality.

One way to monitor for issues while playing through levels is to pull up the STAT UNIT debug overlay.

  1. launch the game on your console
  2. hit tab and enter 'stat unit'
    statunit.jpg

The stat unit command displays the time spent for the current frame on the Game Thread, the time spent for the Render thread, and the time spent for the GPU. It is possible to monitor the different times updated by stat unit to see areas of the level with performance issues.

Keep an eye on the different thread times, if your target framerate is 30fps, all threads should remain below 33.3ms.

If any thread goes over the 33ms and your particles are a suspected culprit, you can use the STAT PARTICLES command to gauge particle times on the different threads.

statparticles.jpg

STAT PARTICLES lists out multiple statistics relative to Game Thread and Render Thread. Pay attention to Draw Calls (Render Thread) and Tick Time (Game Thread).

Targeting Game Thread related issues


Once you have determined you have a Game Thread issue, use the STAT PARTICLES command to verify your findings.

This stat gives quite a bit of information so read over the descriptions on the linked page to help you determine where your costs are highest. Keep an eye on Particle Tick Time and your Particle Counts.

ALERT! Note: It is important to remember that a particle system is the sum of the components (emitters/modules) which make up the effect. The more unique emitters and modules in your system, and the more of those systems in your scene, the higher the Game Thread cost.

If your tick time is high use the ParticleTickStats command to identify which systems are your main offenders.

The ParticleTickStats command has 3 arguments:

  • Single - This argument will capture a single frame and write out a file
  • Start - This argument will begin capturing stats
  • Stop - This argument will end stats so you can see tick time for a duration

The ParticleTickStats report is then written out to this directory:

[UE3 Directory]\[YourGame]\Profiling\PSTick-[sys time].csv

The spreadsheet is broken into columns and rows outlining the cost of your effects

particletickstats.jpg

Total Tick ms
Total time spent ticking all instances that Particle System
Avg Tick ms
Avg. time for ticking that Particle System (Total Tick/Ticks)
Max Tick ms
The HIGHEST tick time for an instance of that Particle System
Ticks
Number of INSTANCES of that Particle System
Avg Active/Tick
Avg # of particles active during the Tick of that Particle System (Total Particles/Ticks)
Max Active/Tick
Max # of particles active during the Tick of that particle (in a single instance)

Depending on your platform you will need to browse to the directory through the appropriate means. This file is comma delineated and can be opened in Excel etc. etc.

Once you have identified Game Thread systems which are offenders there are several paths to take.

  1. Reduce particle emission counts on the systems being used.
  2. Reduce the number of particle systems in the scene.
  3. Reduce lifetime (the amount of time particle evaluation is calculated) for some of your emitters.
  4. Check expensive calculations such as collision etc. to ensure the settings you are using are optimal, reduce collisions or the amount of particles/meshes colliding.
  5. Remove expensive calculations such as collision, dynamic parameters, etc. if necessary.
  6. Replace Game Thread calculated particle effects with static mesh effects if possible.
  7. Set Fixed Bounds on your particle system so you do not calculate them each frame.
  8. Increase LodDistanceCheckTime so you are checking LODs less often (for looping effects with LODMethod set to automatic.)

Using Unreal Front End to launch the build on console

Unreal FrontEnd can be found in your projects binaries folder

[UE3 Directory]\Binaries\UnrealFrontend.exe

Unreal Front End is a GUI which allows any discipline to quickly cook and deploy a build or a level to see the results of local data on a target platform. Unreal Front End also can be used as a launching point for your project, with links to the editor and many other tools. See UnrealFrontend for more information on using this tool.

In relation to effects performance we are going to be focusing on using two parameters when launching the game to get a relatively accurate gauge of how well the game is running. In the Launch Options box the commands -novsync, -noverifygc, and -noailogging.

-novsync disables vertical sync (locking fps @ 30) so we can see how much overhead there is in the scene, -noverifygc disables periodic garbage collection which produces a visible hitch every so often, and -noailogging disables ai logging which slows the game considerably, aiLogging and garbabge collection run in the background and slow performance when enabled. Disabling these will give a closer reproduction of actual frame rate in a final release build, minus disc load time.

frontend.jpg

When doing any of this testing in a debug build, it is important to remember there is a cost to running the game in debug which will not be visible in a final release build. Using tools like the stat overlays have a cost and will cause your results to be skewed slightly.

Troubleshooting batches of FX


Several Commandlets exist for the purpose of checking batches of effects for common problems, and outputting spreadsheets which list the offenders.

For an overview of commandlets and explanations of several of the built-in commandlets, see Commandlet Home.

These Commandlets include:

ParticleSystemAudit

This commandlet will perform an audit on all particle systems that are contained in the database resulting from MineCookedPackages.

NOTE: This will be changed to use the 'On DVD' tag, as well as simply checking all existing particle systems.

It will generate csv files containing the following to assist in optimizing/fixing content:

All particle systems w/ NO LOD levels
No LOD levels means the particle system is 'empty'.
All particle systems w/ a single LOD level
These systems should be reviewed to ensure they are not environmental (level placed) effects. In those cases, you typically want to utilize LODs to turn off emitters in the distance.
All particle systems w/out fixed bounds set
All particle systems that can should leverage the fixed relative bounds.
All particle systems w/ LOD Method of Automatic & a check time of 0.0
This indicates a scenario where the particle system will perform its LOD check every frame.
All particle systems w/ bOrientZAxisTowardCamera enabled
These systems will cause problems if your game will support split-screen.
All particle systems w/ missing materials
These systems will render with the default material.
All particle systems w/ no emitters
These systems are 'empty' - should they be deleted?
All particle systems w/ collision on in at least one emitter
Current collision methods are a VERY high cost operation for particles.

FindOnDvDPsysDynamicParameter

This Commandlet finds any effects using the dynamic parameter module, referencing a material without a functioning dynamic parameter material expression. The process is not entirely fool proof, it is good practice to verify the result through the material editor prior to removal of a dynamic parameter module.

Back to VFX Optimization