In this presentation we make a summary of important optimization techniques that were adopted when porting Catan Universe to mobile. Most of them can also be universally applied in other Unity projects; let us know if they helped you.

1. 1
Unity Forum
27.04.2017

2. 2
Content
Day Time slot Topic Presenter
27.04.2017
15:00 - 15:10 Picks round All
15:10 - 15:45 Mobile performance improvement techniques adopted in Catan Rubén Torres Bonet
25.05.2017
Draft
15:00 - 15:15 Picks round
15:15 - 15:45 Who wants more spaghetti code?
Unity Dependency Injection with Zenject
Rubén Torres Bonet
Open topic Assignee Open topic Assignee
Plugin management in Unity The rendering pipeline
UniRx Navmeshes
Karma for Unity

3. 33
Performance
techniques in Catan
Rubén Torres Bonet

4. 4
Contents
1. Objectives
2. Starting point
3. Tooling: analyzing the gap
4. Memory management
5. Materials
6. Textures
7. Shaders
8. Audio
9. Camera imposter system
10. Power consumption
11. Conclusions

5. 5
1. Objectives
1. Reduce startup time: < 30 s
2. Reduce loading times: scenes, instantiating
3. Smooth framerate: > 30 fps
4. No framerate spikes
5. Reduce power consumption
Reference devices:
- iOS: iPhone 5/5s
- Android: Samsung S4

6. 6
2. Starting point
- On-going development version of Catan running on PC and WebGL
- Gather hardware/software specs about devices:
- CPU: brand, features, cores, frequency, cache size
- GPU: frequency, cache levels, stream processors, fill-rate, OpenGL ES version (>= 3.0)
- RAM: texture, audio, mesh sizes
- Minimum OS version: native plugins
- OpenGL ES Hardware DB
- Unity Mobile Hardware Stats
- GSMArena
- Wikipedia Adreno specs
- Catan scenes:
- Launch time: 45s
- Main menu: 1 FPS
- In-game: 12 FPS

7. 7
3. Analysis
Tools sorted by my personal taste:
1. Unity Stats window: “FPS”, draw calls, triangles, batches
2. RenderDoc: GPU profiling/debugging
3. Unity Profiler: CPU profiling; also good for memory analysis
4. Frame Debugger
5. Snapdragon profiler, Adreno profiler: low-level metrics
6. Hdg Remote Debug: A/B performance analysis
7. Debug.Log
8. XCode profiler

8. 8
3. RenderDoc
Awesome:
- Draw calls cost
- Draw call debugger
- Rendering pipeline examiner
- Texture crawler (aka. stealer)
- Mesh examination
- Fragment debugging
- Shader debugging
- ...
Check my (old) presentation about it

9. 9
3. Snapdragon prof.
For Snapdragon chipsets

10. 10
3. Hdg remote debug
- Unity plugin
- Real-time examining and modifying of the Unity hierarchy
- Target: an app running in a device (iOS, Android…)
- Simple A/B testing for analysing performance issues:
- Import plugin
- Insert prefab
- Open the remote hierarchy window
- Introduce IP of the target device running your app
- Examine hierarchy manually using binary search
- Turn on/off individual GameObjects and components to check performance impact
- Quick way of isolating bottlenecks
- Use other tools to find the issue within the chosen GameObject/MonoBehaviour
https://www.assetstore.unity3d.com/en/#!/content/61863

11. 11
4. Memory management
- Workflow:
- You allocate some memory blocks too often
- Unity triggers the (in)famous garbage collector, which it is itself garbage
- All threads are blocked for a long period of time (between 50ms and 1s in mobile?)
- Users are angry, dev gets fired
- Main problem: most allocations are implicit and evil. There’s no new
keyword involved, the dev doesn’t know about it till it’s too late
- Typical issues:
- Boxing: myNonGenericArrayList.Add(5);
- LINQ, foreach
- Dynamic instantiation of objects: use object pooling
- Coroutines: starting & creation of yield operations (please cache them and use return null
instead of 0 or boxing occurs)
- When not caching lists but rather recreating them
- Use the stack when possible instead of the heap

12. 12
5. Materials
- Unity offers no per-platform material system
- Materials can be pretty expensive because of the shaders and textures
- Solution? No solution, just workarounds
- I created a build step that replaces material references in compile-time to their
_desktop.mat and _mobile.mat counterparts
- Don’t use standard shaders in mobile
- Workflow:
- After the builds are completed, please check what was included in it using BuildReport
- An item (material, shaders, textures, audio...) you don’t like was included? Check its references with FindReferences2
- Use A+ Asset Explorer to quickly tweak texture settings (size, compression..:) and many other issues
- Create platform-specific shaders when expensive

13. 13
6. Textures
- Texture compression: of uttermost importance on mobile:
- Each texture fetch in fragment shaders will ask texture samplers for texels
- The texture block cache access is likely to miss if you have lots of big textures, therefore producing a stall
- It reduces startup and loading times, since textures are stored compressed both in permanent storage and RAM
- It will also reduce the distributed package size (APK/IPA..)
- If the format is not supported in the current architecture, it’ll be CPU-recompressed by Unity (longer loading times)
- It can, however, produce artifacts and you have to consider the platform capabilities
- Tweak texture size to your needs (screen size of the projected textures)
- Advanced texture filtering (>= trilinear) is still expensive in mobile
- Disable mipmapping when not needed (e.g. screen space UI)
- Check that expensive textures maps are not included in the mobile build: heightmaps,
detail maps, etc.

14. 14
7. Shaders
- Prefer lower precision variables in this order: fixed, half, float
- Avoid standard shaders; go instead for Lambert or Phong lighting models
- Do not have more than one light source. Mobile platforms support only forward
rendering so that every light creates a new rendering pass
- Do not use GrabPass (and therefore avoid post-effects), as they quickly stall the
rendering pipeline and will quickly reach your fill-rate and bandwidth capabilities
- Disable fog if not needed
- Avoid mega-shaders and big shaders; compile times will be annoying (e.g. 10 s)
- Fake lighting effects with unlit shaders with custom parameters
- Disable shadow support if possible
- Avoid alpha blending, as it breaks mobile GPU tiling optimizations and produces more
overdraw
- Consider introducing a z-prepass step in case of high overdraw and expensive
fragment operations

15. 15
8. Audio
Check Unity profiler for memory usage first
General recommendations:
- If they are taking too much memory (> 30mb), find AudioClips that are rarely played
and set them to streaming
- If they are increasing loading times:
- Set them to load in background (can get out of sync though)
- Disable preload, but you might get a framerate spike the first time they use it
- Set them to streaming, but that will cause CPU overhead
Play with compression methods

16. 16
9. Camera imposter system
- We want the desktop quality in mobile
- We know we can’t achieve it. But, can we fake it?
- Let’s take the background objects and make a static screenshot of them. We can put
that screenshot as a background picture in our scene
- Wait, that doesn’t work quite well:
- Depth information is lost
- Editing workflow is slow (taking screenshots, positioning them, deploying)
- Screenshots are resolution-dependent; we target heterogeneous devices and filtering would ruin its quality
- My approach:
- We render them in run-time with maximum quality at the beginning of the scene:
- A first time to grab the color buffer
- A second and last time to grab the depth buffer
- We disable the original objects
- We keep both textures in a RenderTexture
- We draw both textures at the beginning of each frame with special shaders that output color and writes to the zbuffer

17. 17
- It looks easy, doesn’t it? It is not
- There are many limitations imposed by Unity and OpenGL ES
- Still, I managed to render the whole background of the main menu scene of Catan with
all post-effects: sheep, terrain, environment, trees
- Advantages:
- Huge quality in mobile comparable to desktop
- High frame-rate
- Flexible and fast workflow
- Disadvantages:
- The objects can only be static (although you can re-render manually at any time)
- It is low-level and feels hacky. Unlikely, but it might break with future Unity releases and I’ll probably not be here to fix it
- It doesn’t work on older phones, since shader depth-writing requires OpenGL ES > 3.0
- It requires compiling the post-effect shaders and the original meshes and textures still (obviously)
9. Camera imposter system

18. 18
- Sources of power consumption:
- CPU:
- Intense calculations dissipate a lot of heat (power)
- Requiring data that was used a long time ago breaks temporal locality -> cache miss -> bandwidth requirement
- Asking for data that is distant from each other breaks spatial locality -> cache miss -> bandwidth requirement
- Induce device wakelock by performing background operations when the screen is off
- High frame-rate. Consider reducing it in some scenes (in highly static scenes 10FPS might be enough)
- GPU:
- Shader calculations eats most of it, especially if redundant (overdraw)
- Large amount of objects taking a big screen area excessively loads the rasterizer, produces overdraw if not well
sorted (e.g. transparency) and overloads shader processing units.
- GrabPass and post-effects eat bandwidth like a boss
- Screen:
- Darker colors usually consume less energy
- Other:
- GPS is power-hungry slow communication channel that prevents wakelock, avoid tracking users
- Making your game too addictive will also lead users to wasting lots of battery on it ;)
- Micro-optimization: set clear flag to pure black
10. Power consumption

19. 19
Conclusions
To “unoptimize” your mobile game:
- Don’t consider performance relevant from the beginning
- Put post-effects everywhere. If possible, in multiple full-screen cameras.
- Keep myriad of useless big textures in memory
- Use complex mega-shaders with multiple light sources
- Avoid static batching by forgetting to marking static flags
- Break dynamic batching by applying non-uniform negative scaling
- Reference unneeded materials because you can
- Do intense alpha blending to break GPU tiling optimizations and create more overdraw
- Do not cache coroutine yield instructions
- Ignore the Pareto Principle

20. 20
Conclusions
To “unoptimize” your mobile game:
- Use real-time reflection probes
- Use LINQ and start coroutines in a per-frame basis
- Using unsupported texture compression formats and disable mipmapping
- Don’t bother to make atlases, even though it only takes a few clicks to enable it
- Include uncompressed unoptimized audio even if you target deaf audience
- Use GameObject.FindObjectsOfType and GameObject.Find
- Use the hardware specs sheet as a beer/coffee coasters
- Leave imported mesh colliders there
- Use the new keyword on classes as often as your keyboards lets you type it
- Be lazy enough to skip checking the contents of the final build

21. 21
Conclusions
And lastly, to “unoptimize” your mobile game...
- Don’t communicate with colleagues when you are unsure about the performance
impact of your changes
We all are here to learn and improve (and some to gain money I’ve heard)

22. 22

23. 2323
Questions

24. 2424
Thanks!