Unity optimization techniques applied in Catan Universe
0 likes85 views
The document outlines performance improvement techniques for mobile game development, specifically focusing on the game Catan, presented by Rubén Torres Bonet. Key areas covered include memory management, texture and shader optimization, audio management, and power consumption strategies, with the objective to enhance startup times, loading speeds, and framerate stability. The summarized conclusions emphasize common pitfalls to avoid to ensure better mobile performance.
Unity optimization techniques applied in Catan Universe
- 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!