A Thousand Cuts Down to 5
How to Keep Unity’s Drawcalls and Other Bottlenecks in Check
A tale of lessons learned developing for a platform that literally caught fire
by
Cratesmith
(aka Kieran Lord)
Disclaimer
As usual I may swear and rant.
This was really hard to make into a cohesive talk.
The name of the talk was going to have this really cool point in 5 steps...
However in re-writing this talk I found a better way to do it.
So lets fix up the title
Optimization Takes a whole team
How to Actually keep performance in check.
by
Cratesmith
(aka Kieran Lord who sucks at naming talks)
About me
I make games!
- PS2/XB: Destroy All Humans 2
- 360/PS3: The Dark Knight (Unreleased)
- Wii: Next big thing (Unreleased)
- Web: Alternator
- PC/PS3: Vessel
- iOS/Droid: Sim Cell
- iOS/Droid: Codebreakers
- PC/Mac: Kinect & VR support for Tail Drift
- GearVR: Small (unreleased)
- Cardboard: RACQ Bike VR
- GearVR: Zombie Nom Nom
Plus a bunch of middleware, consulting, professional education and R&D.
A deep dive into how to optimize for a particular kind of hardware or game.
Hard limits or rules on "don't use this feature" or "don't use more than X drawcalls"
What this talk isn't
A case study of a project that was a right nightmare to optimize all throughout development
The focus is going to be on looking at processes and guidelines that we used to finish it.
You're in a processes and workflow talk.
What this talk is
Overall philosophy
"Always shippable"
Everything put into a game should be in a state & quality where it could go into the final game.
Basic performance is a big part of that quality.
If performance is bad, work will need to be redone, crunched or cut.
(Obviously excluding prototyping & first passes)
Fig1. Solution not shippable
"Baseline optimization'
You need baseline performance in order to make the game.
That means the game must run at target frame rate during development.
"Early optimization is the root of all evil"
- I don't like this phrase, because people take it as gospel.
- Deep optimization IS a rabbit hole that can stall development.
- ...But if the game is running under target frame rate, it's a bug!
- Worse, trying to regain acceptable performance late in development can be impossible!
Fig2. How poor performance affects designers & artists.
"Everyone is independent"
Performance is the entire team's responsibility.
Everyone in the team needs the tool & knowledge to manage performance for anything they're making independently of others.
You need to make tools and teach other members of the team how to use them.
If performance problems, common errors and or busywork can be automated DO IT.
Fig3. A tool that saved hundreds of hours and took 5 minutes to make.
Case Study
GAme & PLATFORM
Programming guidelines
REndering Pipeline
Modelling/Texturing pipeline
Level design/Environment art pipeline
Build Pipeline
GAme: Zombie nom nom
First person walking game, always moving forward.
You're a zombie and you run into people to eat their brains.
The round ends if you go too long without eating any brains.
You look really dumb while playing it.
Small but visually complex environments (for GearVR)
Platform: The GEAR VR
Very rough S6 guidelines
- 75k static polys
- 8k dynamic polys
- 25 draw calls per eye
- Required 60fps
- No Instancing
- Not all support single pass stereo rendering
- Note7 model can explode
Weak GPU but much more easily CPU bound (mostly rendering)
Case Study
GAme & PLATFORM
Programming guidelines
REndering Pipeline
Modelling/Texturing pipeline
Level design/Environment art pipeline
Build Pipeline
Goals
The goal was to write code that was quick to make/edit and had a good baseline performance.
Always profile before/after each change.
Refactor or optimize areas that are running slow.
Focus on shortcuts that avoid major issues.
THe Profiler
Everyone on the project should be able to use the profiler.
But as a programmer, it should be used to test everything before it's put in the game.
It also shows when/where heap allocations are occuring in the callstack.
Never just rely on your gut feel that "it's faster". Always compare before/after in the profiler.
Tools and automation
Other roles need the tools to make content for the project as efficiently as possible.
If someone in a non-technical is spending time every iteration doing technical work... at least consider that for automation.
Don't just use the unity default features, turn it into an editor built around your team & game.
The most powerful feature unity has is how flexible it's editor scripting is.
Benchmarking & Limits
Everyone on the team needs to know at least rough limits of what they're working on (how many characters / sounds / fx / polys etc).
Finding those out/keeping them up to date is just as important as writing features.
Always ensure there's a small amount of breathing room in these numbers so that people can break them a little if needed.
Programming: problem areas
- GC/Heap
- Physics
- Update()
GC/HEAP #1
Heap allocations can be VERY slow.
A programmer specific performance problem.
PCs aren't nearly as badly effected by this as as consoles & mobile.
If unchecked this can make porting a nightmare.
GC/HEAP #2
Garbage collection happens when you allocate something and the heap is full/fragemented, too much time has passed or if you call GC.Collect()
There's significant CPU spike as the garbage collector cleans up deleted objects on the heap.
You can manage the severity of the next GC spike by calling GC.Collect when CPU usage is low.
List<Objective> m_tempObjectives
= new List<Objective>();
public override void OnUpdate()
{
base.OnUpdate();
m_tempObjectives.AddRange(m_objectives);
foreach (var objective in m_tempObjectives)
{
if (objective != null)
{
objective.Update();
}
}
m_tempObjectives.Clear();
}GC/HEAP #3
Go read the official Unity tutorial "Optimizing garbage collection in Unity Games" ... it's detailed! VERY detailed!
In Brief:
- Avoid using functions that return new objects (such as arrays).
- Understand the rules around boxing.
- Avoid Linq (unless you're checking IL it's generating)
- Pool & reuse allocations where possible.
Physics complexity
The cost of physics in CPU is heavily affected by on complexity and number of colliders near one another.
This can be cut down a lot.
Use layermasks extensively, especially for triggers & raycasts.
Also try to keep your physics environment "clean"
- Use primitive colliders instead of meshes
- Avoid mesh colliders for non-static objects
- Use convex mesh colliders when possible
Update()
If you don't need to update something every frame... don't!
Break expensive logic out from required updates, in the update make it animate correctly and blend any changes.
Use coroutines, jobs, timers or managers to update that independently of the framerate/physics timestep.
Lessons Learned
Profiling everything before/after each change revealed that our "gut feel" couldn't be trusted at all.
Getting everyone on board with GC alloc rules was a great time investment.
Regularly updated benchmarks & tools made for other team saved both their time and programmer time (less support needed!)
Case Study
Programming guidelines
REndering Pipeline
Modelling/Texturing pipeline
Level design/Environment art pipeline
Build Pipeline
GAme & PLATFORM
This section
Before explaining the process we need to briefly discuss the rendering pipeline.
To just make the core gameplay we were pushing the GearVR's rendering limits.
The requirements of the render pipeline dictated the art style, asset pipelines and the team's workflows.
Batching / Draw Calls
A drawcall is basically a SetPass call followed by one or more vertex buffers sent to the GPU.
SetPass is called between batches of objects to set textures & render parameters.
SetPass can be very slow on CPU
If the Render thread gets behind, the GPU can be left idle.
Batching is where unity tries to group objects together to minimize the number of SetPass calls.
Consoles, Standalone VR and mobile are much more affected by drawcalls than PC.
Batching vs Render API
Which render APIs your platform supports has a big impact on how expensive drawcalls are.
Unity is faster at submitting draw calls with the new APIs such as vulkan/metal/DX12 .
Additionally on some platforms they allow drawcall submission to be multithreaded heavily.
If you are only releasing for platforms that support this you'll generally be able to run many more drawcalls without becoming CPU bound.
Hardware support for these isn't universal however... and vulkan is presently unsupported on GearVR
Batching: STATIC
The first kind of batching unity supports is "Static Batching".
Works as "baked" batching for static geometry (though can be done at runtime).
Has significant memory overhead.
Reliably saves CPU time.
It performs significantly better with large "chunks" of geometry rather than hundreds of small objects.
Batching: Dynamic
Dynamic batching merges groups of meshes each frame CPU for rendering.
Limited to meshes of ~300 verts or less, depending on your shader.
Only saves CPU on platforms where SetPass is very slow.
Test with/without dynamic batching.
Most games run faster with dynamic batching disabled!
Batching: Instancing
Draws a single mesh multiple times with different render parameters.
Very good performance compared to other batching methods.
This feature would have been perfect for Zombie...
...but it wasn't supported for GearVR at the time
Batching: For zombie
Zombie was unfortunately the worst case scenario.
- Crowds of characters
- Lots of dynamic objects
- High drawcall CPU cost
- Instancing not supported
So everything had to be static / dynamic batched.
All assets needed to be authored, processed compiled to make maximum use of both batching types
We were constantly alternating between being CPU and GPU bound
Draw Calls: PROFILER
The profiler was the easiest way to track if we were CPU or GPU bound and what was the cause.
Gfx.WaitForCommands will indicate when the render thread is waiting for the GPU.
Long processing in Camera.Render usually suggested being bound by drawcalls.
Profiler does affect performance significantly on device. So we had a "framerate info" overlay built into dev builds.
Frame Debugger
If we were CPU bound, we'd start by opening up the frame debugger to see what drawcalls could be cut or batched together.
It made tracking down when batching wasn't working a lot easier.
Additionally it helped us with ordering our rendering to minimize overdraw (the main way we were GPU bound)
Unfortunately the FD had issues with VR devices at the time, so we'd mostly use it in editor as a guide.
Lessons Learned
Static batching was always a saving for CPU.
We had to prevent certain objects static batching to avoid overdraw.
We were in the unfortunate position where needed dynamic batching to make the game work.
A lot of the problems we faced on this project could have been avoided if the platform supported instancing or newer APIs
Case Study
Programming guidelines
REndering Pipeline
Modelling/Texturing pipeline
Level design/Environment art pipeline
Build Pipeline
GAme & PLATFORM
Goals
The artists should be able to build models, put them into the game & test them.
Any technical busywork should be automated and have a fast iteration time.
The more of the time artists are focused on making content for the game (within constraints) the better the game gets.
Profiler again!
Teach artists how to use the profiler to check their work using the profiler!
Just the parts of the profiler relevant to their work.
How to check polygon budgets, drawcall restrictions etc.
Getting content in game
Everything had a specific, simple asset type.
Eg. All NPCs have a CharacterType asset as a central point for other assets that define how they look/sound/behave.
Testing characters, objects, effects etc in both empty scenes or levels in the game was supported and easy.
Atlasing
Drawcalls can only contain objects with the same material & params.
So if you need to reduce drawcalls, merging textures and materials is the first thing to do.
My preference is to generate altas textures, meshes & materials automatically in editor.
Unity does provide methods to combine textures for this, but getting a good automatic workflow takes a bit of editor scripting.
There's some tools on the Asset Store that do variations on this if you don't want to roll your own
Atlasing: Problems
The difficulty with atlases is keeping them up to date.
Editor scripts checked if any inputs to the atlas had changed. The atlas only auto-rebuilds if this has happened.
This kept iteration time down as reimporting atlases was quite slow.
Lessons learned
Auto-generating atlases was an easy win, and less work than expected.
Teaching artists to use the profiler was really valuable.
In future I'm going to make it so artists can export groups of models (eg, all characters) in a single fbx and import scripts break them up & fix transforms.
Case Study
Programming guidelines
REndering Pipeline
Modelling/Texturing pipeline
Level design/Environment art pipeline
Build Pipeline
GAme & PLATFORM
Goals
Everyone on the team had a hand in working on the levels.
Despite the restrictions, the tools and limitations had to be fully understood by everyone.
We also wanted to use probuilder (an in-unity level/mesh editor) in the pipeline as the team was already familiar with it.
Environments: Building
Each level is built in grey box using probuilder.
Visual meshes are arranged to cover the probuilder geometry.
Design focused geometry makes fast & clean collision and navigation meshes and is easier to tweak.
Environments: Saving
Editor scripts whenever the scene is saved
Navmeshes are built from probuilder geometry flagged as "colliders"
Occlusion is built for visual meshes (and probuilder objects flagged as "occluders")
Warnings are thrown for common mistakes.
Environments: Chunks
Static visual meshes are grouped into chunks by hand.
Chunks are parent objects that atlas & merge all visual meshes under them on play/build.
Selecting which meshes were in each chunk was a tradeoff between drawcalls (better static batching) and polycount
Environments: LIMITS
From benchmarking we knew rough "safe limits" for drawcalls and polycount. (75k static, 8k dynamic, 25 drawcalls/eye)
Everyone was shown how to use the profiler to track drawcalls & polycount.
If anyone could reorganize chunks/occlusion to fit more polys, they could add more detail.
Quality skyrocketed.
Environments: Markup
Everyone wanted to minimize polys to fit more stuff but we had "wasted polys" on objects that were never seen.
So we added "Backface Cull Volumes" to the scenes to strip polygons during the chunking process.
Any face inside the volume that matches the direction of the volume gets discarded.
We generally saved 20% of polys per level using these.
The trimmed polys still wasted space in the lightmap, a tradeoff for it being a simple workflow.
Environments: Culling
Chunks are parented to culling sectors. A parent with a bounding volume
A culling sector has a list of the other sectors that are visible when the camera is inside it.
Some sectors didn't have their own geometry, they were just "triggers" for visibility sets around doorways.
This is separate from unity's occlusion culling which is also used.
Lessons learned
We accidentally made a game out of fitting more detail into levels... and we got pretty good at it.
Automatic processes with simple markup volumes are really easy to explain and use.
Custom occlusion culling could have been easier to use but fit the needs of the project.
Having benchmarked limits that people can work against is essential (even if they're rough)
Case Study
Programming guidelines
REndering Pipeline
Modelling/Texturing pipeline
Level design/Environment art pipeline
Build Pipeline
GAme & PLATFORM
Goals
Wanted to make sure that everyone was testing on final hardware as much as possible
Or at the least checking everything in desktop VR.
People tend to avoid this as it's slower, espeically with GearVR build times.
Iteration time is key!
PRESS PLAY TO TEST
Every scene needs to work when you push play. No exceptions.
If any systems needed by the scene controller or any actor are auto-constructed.
BUILD & RUN ANY SCenE
Testing on device is slow enough as is. Being forced to make a full build is too much.
We usually just want to test one level, so we needed a way to one click build & run a single scene.
I'd maintained a fork of UBS (an opensource unity build manager) on previous projects which was expanded for this.
SKU types
We didn't have enough headsets go around. So we needed to support non-vr builds.
Expanded the build system to have a concept of plaforms (Skus)
Each SkuType was an editor script that configured the project & plugins to build or run in this mode.
Each SkuType also injects a prefab into each built scene based on the platform (eg, to handle different VR camera setups)
public class SkuTypeZombieGameNonVR
: SkuTypeZombieGame
{
#if UNITY_EDITOR
public override void EnablePlatform()
{
base.EnablePlatform();
UnityEditor.PlayerSettings
.virtualRealitySupported = false;
}
#endif
public override bool vrSupported
{
get { return false; }
}
}
Lessons learned
Unity generally has good iteration time during prototyping.
Keeping that iteration time up during development is up to you.
In our case level specific builds/non-vr versions helped a lot but each project is different!
QUESTIONS?
Example: Pooled temporary Lists
foreach(var mr in gameObject.GetComponentsInChildren<MeshRenderer>())
{
// do stuff!
}using(var mrList = gameObject.GetComponentsInChildrenTempList<MeshRenderer>())
foreach(var mr in mrList)
{
// do stuff!
}Fig1. Creates a new array on the heap
Fig2. Example using a pooled temporary list instead
GC/HEAP: Advice
Example: Pooled temporary Lists
public class TempList<T> : IDisposable, IList<T>
{
private static readonly Queue<TempList<T>> s_lists = new Queue<TempList<T>>();
public readonly List<T> list = new List<T>();
private TempList() {}
// acquire a temporary list
public static TempList<T> Get()
{
lock(s_lists) return s_lists.Count > 0
? s_lists.Dequeue()
: new TempList<T>();
}
// return a list back to the pool
public void Dispose()
{
list.Clear();
lock(s_lists) s_lists.Enqueue(this);
}
public static implicit operator List<T>(TempList<T> from)
{
return from != null ? from.list : null;
}
// ILIST IMPELMENTATION (call appropriate method on this.list)
}Fig3. TempList implementation
GC/HEAP: Advice
Example: Pooled temporary Lists
public static TempList<T> GetComponentsInChildrenTempList<T>(this Component @this,
bool includeInactive=false)
{
var tempList = TempList<T>.Get();
if(@this!=null)
{
@this.GetComponentsInChildren<T>(includeInactive, tempList.list);
}
return tempList;
}
public static TempList<T> GetComponentsInChildrenTempList<T>(this GameObject @this,
bool includeInactive=false)
{
var tempList = TempList<T>.Get();
if(@this!=null)
{
@this.GetComponentsInChildren<T>(includeInactive, tempList.list);
}
return tempList;
}
Fig4. TempList extension methods
GC/HEAP: Advice
Atlasing: output Data
AtlasData stores info on how to map textures to
MeshGroups store all the meshes created for atlased models.
Prefabs are created for each of the atlased models.
AtlasMesh files created for each atlased model. Dummy assets that are lookup keys for the real models.
Atlasing: Versioning
In order to auto-rebuild atlases if they're needed we need to be able to track if contents have changed.
Building the atlas creates a hash asset which stores Unity's hash for each asset.
If the list of GUIDs/hashes for the AtlasGroup's inputs don't match the hash asset, the atlas is out of date
This worked really well! It's a reliable & general purpose solution for auto-generating assets.
Atlasing: AtlasGroup
Defines what's going to be built into an atlas and how.
Takes Model/Material list assets as inputs.
Used as a handle for the atlas by the rest of the game.
When built it creates a child folder for all the output assets.
Atlasing: Input LISTS
Recursive list assets for models & materials as inputs for atlases.
List of assets and a list of child lists.
Easy to maintain lists of objects/characters by hand, but tracking what levels use wasn't.
Saving a level creates/updates a material list for all static meshes in that level.
Batching LIGHT PROBES
Problem: We used lightprobes instead of dynamic lighting + dynamic batching.
Light probes calculate SH values from the light probes for MeshRenderer's anchor transform.
Different SH values = different batches for dynamic batching.
Batching Light Probes
Characters drawcalls:
No anchor
1 character = up to 50 drawcalls
Waist bone as anchor
1 character = 1 drawcall.
(Same as using skinned meshes)
Multiple characters with shared anchor
up to 5 characters = 1 drawcall
Atlasing: Problems #2
We also had the problem that applying the atlas UVs to meshes at runtime was too slow on the GearVR.
So "pre-atlased" versions of models for characters & objects needed to be built with the atlas texture.
Each atlas needed to have a lookup table for a prefab to use instead of the model.
Light Probe Sectors #1
Environments marked up with light sectors, bounding volumes.
Objects/Characters look up which light sector they're in and use it's transform as their light probe anchor.
Light sectors can overlap! Objects use the sector with the highest priority.
Have to be tweaked by hand to make it look right.
Light Probe Sectors #2
Pros:
Solved our batching problems!
Also simplified adding light probes to levels. The sectors automatically created light probes for each bounding volume.
Cons:
Placement of light sectors to look good became a level design/art problem. More on that soon!
Still paying for transforming/culling/occlusion on each mesh seperately.
GC/HEAP Boxing
Boxing occurs when a value type (struct, int, bool etc) is passed into a function that expects an interface or object.
The value type creates a temporary System.Object that contains the value so that the function can treat it like an object.
This is very easy to do without realising it.
If a function that shouldn't be allocating is showing up on the profiler with GC Alloc this is the likely culprit.
void SurpriseAlloc()
{
int cost = 5;
string displayString
= String.Format("Price: {0} gold", cost);
}
public interface IInterface {}
public struct MyStruct : IInterface {}
void ThisIsBadToo()
{
var val = new MyStruct();
InterfaceBoxingExample(val)
}
void InterfaceBoxingExample(IInterface val)
{
Debug.Log("dang");
}bool AnotherExample(object thing)
{
int val = 5;
return thing!=null && thing.Equals(val);
}
Raycasting: PRoBLEM
Raycasting is incredibly useful, however it's very expensive on CPU (and operates in the main thread!).
Caspule/Sweep casts are even worse!
It's very easy to cause spikes even on PC if too many raycasts occur in one frame.
