41,99 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Master a series of performance-enhancing coding techniques and methods that help them improve the performance of their Unity3D applications
About This Book
- Discover features and techniques to optimize Unity Engine's CPU cycles, memory usage, and the GPU throughput of any application
- Explore multiple techniques to solve performance issues with your VR projects
- Learn the best practices for project organization to save time through an improved workflow
Who This Book Is For
This book is intended for intermediate and advanced Unity developers who have experience with most of Unity's feature-set, and who want to maximize the performance of their game. Familiarity with the C# language will be needed.
What You Will Learn
- Use the Unity Profiler to find bottlenecks anywhere in your application, and discover how to resolve them
- Implement best practices for C# scripting to avoid common pitfalls
- Develop a solid understanding of the rendering pipeline, and maximize its performance by reducing draw calls and avoiding fill rate bottlenecks
- Enhance shaders in a way that is accessible to most developers, optimizing them through subtle yet effective performance tweaks
- Keep your scenes as dynamic as possible by making the most of the Physics engine
- Organize, filter, and compress your art assets to maximize performance while maintaining high quality
- Discover different kinds of performance problems that are critical for VR projects and how to tackle them
- Use the Mono Framework and C# to implement low-level enhancements that maximize memory usage and avoid garbage collection
- Get to know the best practices for project organization to save time through an improved workflow
In Detail
Unity is an awesome game development engine. Through its massive feature-set and ease-of-use, Unity helps put some of the best processing and rendering technology in the hands of hobbyists and professionals alike.
This book shows you how to make your games fly with the recent version of Unity 2017, and demonstrates that high performance does not need to be limited to games with the biggest teams and budgets.
Since nothing turns gamers away from a game faster than a poor user-experience, the book starts by explaining how to use the Unity Profiler to detect problems. You will learn how to use stopwatches, timers and logging methods to diagnose the problem. You will then explore techniques to improve performance through better programming practices.
Moving on, you will then learn about Unity's built-in batching processes; when they can be used to improve performance, and their limitations. Next, you will import your art assets using minimal space, CPU and memory at runtime, and discover some underused features and approaches for managing asset data. You will also improve graphics, particle system and shader performance with a series of tips and tricks to make the most of GPU parallel processing.
You will then delve into the fundamental layers of the Unity3D engine to discuss some issues that may be difficult to understand without a strong knowledge of its inner-workings. The book also introduces you to the critical performance problems for VR projects and how to tackle them.
By the end of the book, you will have learned to improve the development workflow by properly organizing assets and ways to instantiate assets as quickly and waste-free as possible via object pooling.
Style and approach
This practical book will help readers understand the essentials of the Unity3D engine and how to build games while improving the performance of their applications.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 584
Veröffentlichungsjahr: 2017
Ähnliche
Second Edition
BIRMINGHAM - MUMBAI
Unity 2017 Game Optimization
Second Edition
Copyright © 2017 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: November 2015
Second edition: November 2017
Production reference: 1161117
ISBN 978-1-78839-236-5
www.packtpub.com
Credits
Author
Chris Dickinson
Copy Editor
Dhanya Baburaj
Reviewers
Luiz Henrique Bueno
Sebastian Koenig
Project Coordinator
Ritika Manoj
Commissioning Editor
Kunal Chaudhari
Proofreader
Safis Editing
Acquisition Editor
Shweta Pant
Indexer
Tejal Daruwale Soni
ContentDevelopmentEditor
Aditi Gour
Graphics
Jason Monteiro
Technical Editor
Shweta Jadhav
Production Coordinator
Shantanu Zagade
About the Author
Chris Dickinson grew up in a quiet little corner of England with a strong passion for mathematics, science and, in particular, video games. He loved playing them, dissecting their gameplay, and trying to figure out how they worked. Watching his dad hack the hex code of a PC game to get around the early days of copy protection completely blew his mind! His passion for science won the battle at the time; however, after completing a master's degree in physics with electronics, he flew out to California to work in the field of scientific research in the heart of Silicon Valley. Shortly afterward, he had to admit to himself that research work was an unsuitable career path for his temperament. After firing resumes in all directions, he landed a job that finally set him on the correct course in the field of software engineering (this is not uncommon for physics grads, I hear).
His time working as an automated tools developer for IPBX phone systems fit his temperament much better. Now he was figuring out complex chains of devices, helping its developers fix and improve them, and building tools of his own. Chris learned a lot about how to work with big, complex, real-time, event-based, user-input driven state machines (sounds familiar?). Being mostly self-taught at this point, Chris's passion for video games was flaring up again, pushing him to really figure out how video games were built. Once he felt confident enough, he returned to school for a bachelor's degree in game and simulation programming. By the time he was done, he was already hacking together his own (albeit rudimentary) game engines in C++ and regularly making use of those skills during his day job. However, if you want to build games, you should just build games, and not game engines. So, Chris picked his favorite publically available game engine at the time--an excellent little tool called Unity 3D--and started hammering out some games.
After a brief stint of indie game development, Chris regretfully decided that the demands of that particular career path weren't for him, but the amount of knowledge he had accumulated in just a few short years was impressive by most standards, and he loved to make use of it in ways that enabled other developers with their creations. Since then, Chris has authored a tutorial book on game physics (Learning Game Physics with Bullet Physics and OpenGL, Packt Publishing) and two editions of a Unity performance optimization book (which you are currently reading). He has married the love of his life, Jamie, and works with some of the coolest modern technology as a software development engineer in Test (SDET) at Jaunt Inc. in San Mateo, CA, a Virtual Reality/Augmented Reality startup that focuses on delivering VR and AR experiences, such as 360 videos (and more!).
Outside of work, Chris continues to fight an addiction to board games (particularly Battlestar: Galactica and Blood Rage), an obsession with Blizzard's Overwatch and Starcraft II, cater to the ever-growing list of demands from a pair of grumpy yet adorable cats, and gazing forlornly at the latest versions of Unity with a bunch of game ideas floating around on paper. Someday soon, when the time is right (and when he stops slacking off), his plans may come to fruition.
About the Reviewers
Luiz Henrique Bueno is a certified ScrumMaster® (CSM) and Unity Certified Developer with over 29 years of experience in software development. He has experimented with the evolution of languages, editors, databases, and frameworks.
In 2002, he wrote the book Web Applications with Visual Studio .NET, ASP.NET, and C#, at the launch of Visual Studio .NET. He also participated in the development of a Brazilian magazine called Casa Conectada, about Home Automation.
Based on this magazine's project, he started the development of projects focused on the same subject. He has used technologies such as Crestron, Control4, Marantz, Windows Mobile, and Symbian OS, always implementing touchscreen applications.
Since 2010, he has been developing apps and video games for mobile devices, including VR/AR applications. He has already developed many projects for iPhone, iPad, Apple Watch, Apple TV, and Android using Unity, C#, Xcode, Cocoa Touch, Core Data, SpriteKit, SceneKit, Objective-C, Swift, Git, Photoshop, and Maya.
His motto is "Do not write code for QA, write code for Production." You can reach Luiz Henrique Bueno on his personal website.
Dr. Sebastian Thomas Koenig received his Ph.D. in human interface technology from the University of Canterbury, New Zealand, developing a framework for personalized virtual reality cognitive rehabilitation. He obtained his diploma in psychology from the University of Regensburg, Germany, in the areas of experimental psychology, clinical neuropsychology, and virtual reality rehabilitation.
Dr. Koenig is the founder and CEO of Katana Simulations, where he oversees the design, development, and evaluation of cognitive assessment and training simulations. His professional experience spans over 10 years of clinical work in cognitive rehabilitation and virtual reality research, development, and human computer interaction. He has been awarded over $2 million in research funding in the USA, Germany, and Australia as principal investigator and industry partner. He has extensive experience as a speaker at international conferences and as a reviewer of scientific publications in the areas of rehabilitation, cognitive psychology, neuropsychology, software engineering, game development, games user research, and virtual reality.
Dr. Koenig has developed numerous software applications for cognitive assessment and training. For his work on virtual memory tasks, he was awarded the prestigious Laval Virtual Award in 2011 in the Medicine and Health category. Other applications include the Wonderworks Virtual Reality Attention Training in collaboration with the Kessler Foundation, NJ, USA, and the patent-pending Microsoft Kinect-based motor and cognitive training JewelMine/Mystic Isle at the USC Institute for Creative Technologies, CA, USA. Dr. Koenig was awarded the Early Career Investigator Award (2nd place) by the International Society for Virtual Rehabilitation in 2016.
www.PacktPub.com
For support files and downloads related to your book, please visit www.PacktPub.com. Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www.packtpub.com/mapt
Get the most in-demand software skills with Mapt. Mapt gives you full access to all Packt books and video courses, as well as industry-leading tools to help you plan your personal development and advance your career.
Why subscribe?
Fully searchable across every book published by Packt
Copy and paste, print, and bookmark content
On demand and accessible via a web browser
Customer Feedback
Thanks for purchasing this Packt book. At Packt, quality is at the heart of our editorial process. To help us improve, please leave us an honest review on this book's Amazon page at www.amazon.in/dp/1788392361.
If you'd like to join our team of regular reviewers, you can email us at [email protected]. We award our regular reviewers with free eBooks and videos in exchange for their valuable feedback. Help us be relentless in improving our products!
Software and Hardware List
Software Specifications:
The following are the steps to install the softwares:
Download it
Install it
Unpack the code files/pull them from git
Launch Unity and point it to the folder containing the code files (the folder containing the /Assets folder)
Table of Contents
Preface
What this book covers
What you need for this book
Who this book is for
Conventions
Reader feedback
Customer support
Downloading the example code
Downloading the color images of this book
Errata
Piracy
Questions
Pursuing Performance Problems
The Unity Profiler
Launching the Profiler
Editor or standalone instances
Connecting to a WebGL instance
Remote connection to an iOS device
Remote connection to an Android device
Editor profiling
The Profiler window
Profiler controls
Add Profiler
Record
Deep Profile
Profile Editor
Connected Player
Clear
Load
Save
Frame Selection
Timeline View
Breakdown View Controls
Breakdown View
The CPU Usage Area
The GPU Usage Area
The Rendering Area
The Memory Area
The Audio Area
The Physics 3D and Physics 2D Areas
The Network Messages and Network Operations Areas
The Video Area
The UI and UI Details Areas
The Global Illumination Area
Best approaches to performance analysis
Verifying script presence
Verifying script count
Verifying the order of events
Minimizing ongoing code changes
Minimizing internal distractions
Minimizing external distractions
Targeted profiling of code segments
Profiler script control
Custom CPU Profiling
Final thoughts on Profiling and Analysis
Understanding the Profiler
Reducing noise
Focusing on the issue
Summary
Scripting Strategies
Obtain Components using the fastest method
Remove empty callback definitions
Cache Component references
Share calculation output
Update, Coroutines, and InvokeRepeating
Faster GameObject null reference checks
Avoid retrieving string properties from GameObjects
Use appropriate data structures
Avoid re-parenting Transforms at runtime
Consider caching Transform changes
Avoid Find() and SendMessage() at runtime
Assigning references to pre-existing objects
Static Classes
Singleton Components
A global Messaging System
A globally accessible object
Registration
Message processing
Implementing the Messaging System
Message queuing and processing
Implementing custom messages
Message sending
Message registration
Message cleanup
Wrapping up the Messaging System
Disable unused scripts and objects
Disabling objects by visibility
Disabling objects by distance
Consider using distance-squared over distance
Minimize Deserialization behavior
Reduce serialized object size
Load serialized objects asynchronously
Keep previously loaded serialized objects in memory
Move common data into ScriptableObjects
Load scenes additively and asynchronously
Create a custom Update() layer
Summary
The Benefits of Batching
Draw Calls
Materials and Shaders
The Frame Debugger
Dynamic Batching
Vertex attributes
Mesh scaling
Dynamic Batching summary
Static Batching
The Static flag
Memory requirements
Material references
Static Batching caveats
Edit Mode debugging of Static Batching
Instantiating static meshes at runtime
Static Batching summary
Summary
Kickstart Your Art
Audio
Importing audio files
Loading audio files
Encoding formats and quality levels
Audio performance enhancements
Minimize active Audio Source count
Enable Force to Mono for 3D sounds
Resample to lower frequencies
Consider all compression formats
Beware of streaming
Apply Filter Effects through Mixer Groups to reduce duplication
Use remote content streaming responsibly
Consider Audio Module files for background music
Texture files
Texture compression formats
Texture performance enhancements
Reduce texture file size
Use Mip Maps wisely
Manage resolution downscaling externally
Adjust Anisotropic Filtering levels
Consider Atlasing
Adjust compression rates for non-square textures
Sparse Textures
Procedural Materials
Asynchronous Texture Uploading
Mesh and animation files
Reduce polygon count
Tweak Mesh Compression
Use Read-Write Enabled appropriately
Consider baked animations
Combine meshes
Asset Bundles and Resources
Summary
Faster Physics
Physics Engine internals
Physics and time
Maximum Allowed Timestep
Physics updates and runtime changes
Static Colliders and Dynamic Colliders
Collision detection
Collider types
The Collision Matrix
Rigidbody active and sleeping states
Ray and object casting
Debugging Physics
Physics performance optimizations
Scene setup
Scaling
Positioning
Mass
Use Static Colliders appropriately
Use Trigger Volumes responsibly
Optimize the Collision Matrix
Prefer Discrete collision detection
Modify the Fixed Update frequency
Adjust the Maximum Allowed Timestep
Minimize Raycasting and bounding-volume checks
Avoid complex Mesh Colliders
Use simpler primitives
Use simpler Mesh Colliders
Avoid complex physics Components
Let physics objects sleep
Modify the Solver Iteration Count
Optimize Ragdolls
Reduce Joints and Colliders
Avoid inter-Ragdoll collisions
Replace, deactivate or remove inactive Ragdolls
Know when to use physics
Summary
Dynamic Graphics
The Rendering Pipeline
The GPU Front End
The GPU Back End
Fill Rate
Overdraw
Memory Bandwidth
Lighting and Shadowing
Forward Rendering
Deferred Rendering
Vertex Lit Shading (legacy)
Global Illumination
Multithreaded Rendering
Low-level rendering APIs
Detecting performance issues
Profiling rendering issues
Brute-force testing
Rendering performance enhancements
Enable/Disable GPU Skinning
Reduce geometric complexity
Reduce Tessellation
Employ GPU Instancing
Use mesh-based Level Of Detail (LOD)
Culling Groups
Make use of Occlusion Culling
Optimizing Particle Systems
Make use of Particle System Culling
Avoid recursive Particle System calls
Optimizing Unity UI
Use more Canvases
Separate objects between static and dynamic canvases
Disable Raycast Target for noninteractive elements
Hide UI elements by disabling the parent Canvas Component
Avoid Animator Components
Explicitly define the Event Camera for World Space Canvases
Don't use alpha to hide UI elements
Optimizing ScrollRects
Make sure to use a RectMask2D
Disable Pixel Perfect for ScrollRects
Manually stop ScrollRect motion
Use empty UIText elements for full-screen interaction
Check the Unity UI source code
Check the documentation
Shader optimization
Consider using Shaders intended for mobile platforms
Use small data types
Avoid changing precision while swizzling
Use GPU-optimized helper functions
Disable unnecessary features
Remove unnecessary input data
Expose only necessary variables
Reduce mathematical complexity
Reduce texture sampling
Avoid conditional statements
Reduce data dependencies
Surface Shaders
Use Shader-based LOD
Use less texture data
Test different GPU Texture Compression formats
Minimize texture swapping
VRAM limits
Preload textures with hidden GameObjects
Avoid texture thrashing
Lighting optimization
Use real-time Shadows responsibly
Use Culling Masks
Use baked Lightmaps
Optimizing rendering performance for mobile devices
Avoid Alpha Testing
Minimize Draw Calls
Minimize Material count
Minimize texture size
Make textures square and power-of-two
Use the lowest possible precision formats in Shaders
Summary
Virtual Velocity and Augmented Acceleration
XR Development
Emulation
User comfort
Performance enhancements
The kitchen sink
Single-Pass versus Multi-Pass Stereo Rendering
Apply anti-aliasing
Prefer Forward Rendering
Image effects in VR
Backface culling
Spatialized audio
Avoid camera physics collisions
Avoid Euler angles
Exercise restraint
Keep up to date with the latest developments
Summary
Masterful Memory Management
The Mono platform
Memory Domains
Garbage collection
Memory Fragmentation
Garbage collection at runtime
Threaded garbage collection
Code compilation
IL2CPP
Profiling memory
Profiling memory consumption
Profiling memory efficiency
Memory management performance enhancements
Garbage collection tactics
Manual JIT compilation
Value types and Reference types
Pass by value and by reference
Structs are Value types
Arrays are Reference types
Strings are immutable Reference types
String concatenation
StringBuilder
String formatting
Boxing
The importance of data layout
Arrays from the Unity API
Using InstanceIDs for dictionary keys
foreach loops
Coroutines
Closures
The .NET library functions
Temporary work buffers
Object Pooling
Prefab Pooling
Poolable Components
The Prefab Pooling System
Prefab pools
Object spawning
Instance prespawning
Object despawning
Prefab pool testing
Prefab Pooling and Scene loading
Prefab Pooling summary
IL2CPP optimizations
WebGL optimizations
The future of Unity, Mono, and IL2CPP
The upcoming C# Job System
Summary
Tactical Tips and Tricks
Editor hotkey tips
GameObjects
Scene window
Arrays
Interface
In-editor documentation
Editor UI tips
Script Execution Order
Editor files
The Inspector window
The Project window
The Hierarchy window
The Scene and Game windows
Play Mode
Scripting tips
General
Attributes
Variable attributes
Class attributes
Logging
Useful links
Custom Editor scripts and menu tips
External tips
Other tips
Summary
Preface
User experience is a critical component of any game, and this includes not only our game's story and its Gameplay, but also how smoothly the graphics run, how reliably it connects to multiplayer servers, how responsive it is to user input, and even how large the final application file size is due to the prevalence of mobile devices and cloud downloads. The barrier of entry into game development has been lowered considerably thanks to tools such as Unity that offers an enormous array of useful development features while still being accessible to individual developers. However, due to the amount of competition in the gaming industry, the quality level of the final product that our players expect us to provide is increasing with every passing day. We should expect that every facet of our game can and will be scrutinized by players and critics alike.
The goals of performance optimization are deeply entwined with user experience. Poorly optimized games can result in low frame rates, freezes, crashes, input lag, long loading times, inconsistent and jittery runtime behavior, Physics Engine breakdowns, and even excessively high battery power consumption (an often-neglected metric for mobile devices). Having just one of these issues can be a game developer's worst nightmare as reviews will tend to focus on the one thing that we did badly, in spite of all the things that we did well.
One goal of performance optimization is to make the best use of the available resources, which includes CPU resources such as the number of cycles consumed, how much main memory space we're using (known as RAM) as well as Graphics Processing Unit (GPU) resources, which includes its own memory space (known as VRAM), Fill Rate, Memory Bandwidth, and so on. However, the most important goal of performance optimization is to ensure that no single resource causes a bottleneck at an inappropriate time, and that the highest priority tasks get taken care of first. Even small, intermittent hiccups and sluggishness in performance can pull the player out of the experience, breaking immersion and limiting our potential to create the experience we intended. Another consideration is that the more resources we can save, the more activity we can afford to implement in our games, allowing us to generate more interesting and dynamic gameplay.
It is also important to decide when to take a step back and stop making performance enhancements. In a world with infinite time and resources, there will always be another way to make it better, faster, and more efficient. There must be a point during development where we decide that the product has reached an acceptable level of quality. If not, we risk dooming ourselves to repeatedly implementing changes that result in little or no tangible benefit, while each change also risks the chance that we introduce more bugs.
The best way to decide whether a performance issue is worth fixing is to answer the question "will the user notice it?". If the answer to this questions is "no," then performance optimization will be a wasted effort. There is an old saying in software development:
Premature optimization is the cardinal sin of reworking and refactoring code to enhance performance without any proof that it is necessary. This can mean either making changes without showing that a performance problem even exists, or making changes because we only believe a performance issue might stem from a particular area before it has been proven to be true.
Of course, the original version of this common saying by Donald Knuth goes on to say that we should still write our code to avoid the more straightforward and obvious performance problems. However, the real performance optimization work toward the end of a project can take a lot of time, and we should both plan the time to polish the product properly, while avoiding the desire to implement the more costly and time-consuming changes without verifiable proof. These kinds of mistake have cost software developers, as a collective whole, a depressing number of work hours for nothing.
This book intends to give you the tools, knowledge, and skills you need to both detect and fix performance issues in a Unity application, no matter where they stem from. These bottlenecks can appear within hardware components such as the CPU, GPU, and RAM, or within software subsystems such as Physics, Rendering, and the Unity Engine itself.
Optimizing the performance of our games will give them a much better chance of succeeding and standing out from the crowd in a marketplace that is inundated with new, high-quality games every single day.
What this book covers
Chapter 1, Pursuing Performance Problems, provides an exploration of the Unity Profiler and a series of methods to profile our application, detect performance bottlenecks, and perform root cause analysis.
Chapter 2, Scripting Strategies, deals with the best practices for our Unity C# Script code, minimizing MonoBehaviour callback overhead, improving inter-object communication, and more.
Chapter 3, The Benefits of Batching, explores Unity's Dynamic Batching and Static Batching systems, and how they can be utilized to ease the burden on the Rendering Pipeline.
Chapter 4, Kickstart Your Art, helps you understand the underlying technology behind art assets and learn how to avoid common pitfalls with importing, compression, and encoding.
Chapter 5, Faster Physics, is about investigating the nuances of Unity's internal Physics Engines for both 3D and 2D games, and how to properly organize our physics objects for improved performance.
Chapter 6, Dynamic Graphics, provides an in-depth exploration of the Rendering Pipeline, and how to improve applications that suffer rendering bottlenecks in the GPU, or CPU, how to optimize graphical effects such as lighting, shadows, and Particle Effects, ways in which to optimize Shader code, and some specific techniques for mobile devices.
Chapter 7, Virtual Velocity and Augmented Acceleration, focuses on the new entertainment mediums of Virtual Reality (VR) and Augmented Reality (AR), and includes several techniques for optimizing performance that are unique to apps built for these platforms.
Chapter 8, Masterful Memory Management, examines the inner workings of the Unity Engine, the Mono Framework, and how memory is managed within these components to protect our application from excessive heap allocations and runtime garbage collection.
Chapter 9, Tactical Tips and Tricks, closes the book with a multitude of useful techniques used by Unity professionals to improve project workflow and scene management.
What you need for this book
The majority of this book will focus on features and enhancements that apply to Unity 2017. Many of the techniques explored within this book can be applied to Unity 5.x projects and older, but feature lists may appear different. These differences will be highlighted where applicable.
Who this book is for
This book is intended for intermediate and advanced Unity developers who have experience with most of Unity's feature set, and those who want to maximize the performance of their game or solve particular bottlenecks. Whether the bottleneck is caused by continuous CPU overload, runtime CPU spiking, slow memory access, memory fragmentation, garbage collection, poor GPU Fill Rate, or Memory Bandwidth, this book will teach you the techniques you need to identify the source of the problem and help explore multiple ways of reducing their impact on your application.
Familiarity with the C# language will be needed for sections involving scripting and memory usage, and a basic understanding of Cg will be needed for areas involving Shader optimization.
Conventions
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "Finally, we will need to implement the GameLogic class."
A block of code is set as follows:
void Start() { GameLogic.Instance.RegisterUpdateableObject(this); Initialize();}protected virtual void Initialize() { // derived classes should override this method for initialization code, and NOT reimplement Start()}
New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "Select System info from the Administration panel."
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book-what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.
To send us general feedback, simply e-mail [email protected], and mention the book's title in the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors .
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files emailed directly to you.
You can download the code files by following these steps:
Log in or register to our website using your email address and password.
Hover the mouse pointer on the
SUPPORT
tab at the top.
Click on
Code Downloads & Errata
.
Enter the name of the book in the
Search
box.
Select the book for which you're looking to download the code files.
Choose from the drop-down menu where you purchased this book from.
Click on
Code Download
.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
WinRAR / 7-Zip for Windows
Zipeg / iZip / UnRarX for Mac
7-Zip / PeaZip for Linux
The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Unity-2017-Game-Optimization-Second-Edition. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
Downloading the color images of this book
We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from https://www.packtpub.com/sites/default/files/downloads/Unity2017GameOptimizationSecondEdition_ColorImages.pdf.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books-maybe a mistake in the text or the code-we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at [email protected] with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at [email protected], and we will do our best to address the problem.
Pursuing Performance Problems
Performance evaluation for most software products is a very scientific process. First, we determine the maximum/minimum supported performance metrics, such as the allowed memory usage, acceptable CPU consumption, the number of concurrent users, and so on. Next, we perform load testing against the application in scenarios with a version of the application built for the target platform, and test it while gathering instrumentation data. Once this data is collected, we analyze and search it for performance bottlenecks. If problems are discovered, we complete a root-cause analysis, make changes in the configuration or application code to fix the issue and repeat it.
Although game development is a very artistic process, it is still exceptionally technical, so there is a good reason to treat it in similarly objective ways. Our game should have a target audience in mind, which can tell us what hardware limitations our game might be operating under and, perhaps, tell us exactly what performance targets we need to meet (particularly in the case of console and mobile games). We can perform runtime testing on our application, gather performance data from multiple subsystems (CPU, GPU, memory, the Physics Engine, the Rendering Pipeline, and so on), and compare them against what we consider to be acceptable. We can use this data to identify bottlenecks in our application, perform additional instrumentation, and determine the root cause of the issue. Finally, depending on the type of problem, we should be capable of applying a number of fixes to improve our application's performance to bring it more in line with the intended behavior.
However, before we spend even a single moment making performance fixes, we will need to prove that a performance problem exists to begin with. It is unwise to spend time rewriting and refactoring code until there is good reason to do so, since pre-optimization is rarely worth the hassle. Once we have proof of a performance issue, the next task is figuring out exactly where the bottleneck is located. It is important to ensure that we understand why the performance issue is happening, otherwise we could waste even more time applying fixes that are little more than educated guesses. Doing so often means that we only fix a symptom of the issue, not its root cause, and so we risk the chance that it manifests itself in other ways in the future, or in ways we haven't yet detected.
In this chapter, we will explore the following:
How to gather profiling data using the Unity Profiler
How to analyze Profiler data for performance bottlenecks
Techniques to isolate a performance problem and determine its root cause
With a thorough understanding of a given problem, you will then be ready for information presented in the remaining chapters, where you will learn what solutions are available for the issue we've detected.
The Unity Profiler
The Unity Profiler is built into the Unity Editor itself and provides an expedient way of narrowing down our search for performance bottlenecks by generating usage and statistics reports on a multitude of Unity3D subsystems during runtime. The different subsystems it can gather data for are listed as follows:
CPU consumption (per-major subsystem)
Basic and detailed rendering and GPU information
Runtime memory allocations and overall consumption
Audio source/data usage
Physics Engine (2D and 3D) usage
Network messaging and operation usage
Video playback usage
Basic and detailed user interface performance (new in Unity 2017)
Global Illumination statistics (new in Unity 2017)
There are generally two approaches to make use of a profiling tool: instrumentation and benchmarking (although, admittedly, the two terms are often used interchangeably).
Instrumentation typically means taking a close look into the inner workings of the application by observing the behavior of targeted function calls, where/how much memory is being allocated, and, generally getting an accurate picture of what is happening with the hope of finding the root cause of a problem. However, this is normally not an efficient way of starting to find performance problems because profiling of any application comes with a performance cost of its own.
When a Unity application is compiled in Development Mode (determined by the Development Build flag in the Build Settings menu), additional compiler flags are enabled causing the application to generate special events at runtime, which get logged and stored by the Profiler. Naturally, this will cause additional CPU and memory overhead at runtime due to all of the extra workload the application takes on. Even worse, if the application is being profiled through the Unity Editor, then even more CPU and memory will be spent, ensuring that the Editor updates its interface, renders additional windows (such as the Scene window), and handles background tasks. This profiling cost is not always negligible. In excessively large projects, it can sometimes cause wildly inconsistent behavior when the Profiler is enabled. In some cases, the inconsistency is significant enough to cause completely unexpected behavior due to changes in event timings and potential race conditions in asynchronous behavior. This is a necessary price we pay for a deep analysis of our code's behavior at runtime, and we should always be aware of its presence.
Before we get ahead of ourselves and start analyzing every line of code in our application, it would be wiser to perform a surface-level measurement of the application. We should gather some rudimentary data and perform test scenarios during a runtime session of our game while it runs on the target hardware; the test case could simply be a few seconds of Gameplay, playback of a cut scene, a partial play through of a level, and so on. The idea of this activity is to get a general feel for what the user might experience and keep watching for moments when performance becomes noticeably worse. Such problems may be severe enough to warrant further analysis.
This activity is commonly known as benchmarking, and the important metrics we're interested in are often the number of frames per-second (FPS) being rendered, overall memory consumption, how CPU activity behaves (looking for large spikes in activity), and sometimes CPU/GPU temperature. These are all relatively simple metrics to collect and can be used as a best first approach to performance analysis for one important reason; it will save us an enormous amount of time in the long run, since it ensures that we only spend our time investigating problems that users would notice.
We should dig deeper into instrumentation only after a benchmarking test indicates that further analysis is required. It is also very important to benchmark by simulating actual platform behavior as much as possible if we want a realistic data sample. As such, we should never accept benchmarking data that was generated through Editor Mode as representative of real gameplay, since Editor Mode comes with some additional overhead costs that might mislead us, or hide potential race conditions in a real application. Instead, we should hook the profiling tool into the application while it is running in a standalone format on the target hardware.
Let's cover how to access the Unity Profiler and connect it to the target device so that we can start to make accurate benchmarking tests.
Launching the Profiler
We will begin with a brief tutorial on how to connect our game to the Unity Profiler within a variety of contexts:
Local instances of the application, either through the Editor or a standalone instance
Local instances of a WebGL application running in a browser
Remote instances of the application on an iOS device (for example, iPhone or iPad)
Remote instances of the application on an Android device (
for example,
an Android tablet or phone)
Profiling the Editor itself
We will briefly cover the requirements for setting up the Profiler in each of these contexts.
Editor or standalone instances
The only way to access the Profiler is to launch it through the Unity Editor and connect it to a running instance of our application. This is the case whether we're executing our game in Play Mode within the Editor, running a standalone application on the local or remote device, or we wish to profile the Editor itself.
To open the Profiler, navigate to Window | Profiler within the Editor:
To profile standalone projects, ensure that the Development Build and Autoconnect Profiler flags are enabled when the application is built.
Choosing whether to profile an Editor-based instance (through the Editor's Play Mode) or a standalone instance (built and running separately from the Editor) can be achieved through the Connected Player option in the Profiler window:
Note that switching back to the Unity Editor while profiling a separate standalone project will halt all data collection since the application will not be updated while it is in the background.
Connecting to a WebGL instance
The Profiler can also be connected to an instance of the Unity WebGL Player. This can be achieved by ensuring that the Development Build and Autoconnect Profiler flags are enabled when the WebGL application is built and run from the Editor. The application will then be launched through the Operating System's default browser. This enables us to profile our web-based application in a more real-world scenario through the target browser and test multiple browser types for inconsistencies in behavior (although this requires us to keep changing the default browser).
Unfortunately, the Profiler connection can only be established when the application is first launched from the Editor. It currently (at least in early builds of Unity 2017) cannot be connected to a standalone WebGL instance already running in a browser. This limits the accuracy of benchmarking WebGL applications since there will be some Editor-based overhead, but it’s the only option we have available for the moment.
Remote connection to an iOS device
The Profiler can also be connected to an active instance of the application running remotely on an iOS device, such as an iPad or iPhone. This can be achieved through a shared Wi-Fi connection.
Follow the given steps to connect the Profiler to an iOS device:
Ensure that the
Development Build
and
Autoconnect Profiler
flags are enabled when the application is built.
Connect both the iOS device and Mac device to a local Wi-Fi network, or to an ad hoc Wi-Fi network.
Attach the iOS device to the Mac via the USB or Lightning cable.
Begin building the application with the
Build & Run
option as usual.
Open the Profiler window in the Unity Editor and select the device under
Connected Player
.
You should now see the iOS device's profiling data gathering in the Profiler window.
For troubleshooting problems with building iOS applications and connecting the Profiler to them, consult the following documentation page: https://docs.unity3d.com/Manual/TroubleShootingIPhone.html.
Remote connection to an Android device
There are two different methods for connecting an Android device to the Unity Profiler: either through a Wi-Fi connection or using the Android Debug Bridge (ADB) tool. Either of these approaches will work from an Apple Mac, or a Windows PC.
Perform the following steps to connect an Android device over a Wi-Fi connection:
Ensure that the
Development Build
and
Autoconnect Profiler
flags are enabled when the application is built.
Connect both the Android and desktop devices to a local Wi-Fi network.
Attach the Android device to the desktop device via the USB cable.
Begin building the application with the
Build & Run
option as usual.
Open the
Profiler
window in the Unity Editor and select the device under Connected Player.
The application should then be built and pushed to the Android device through the USB connection, and the Profiler should connect through the Wi-Fi connection. You should then see the Android device's profiling data gathering in the Profiler window.
The second option is to use ADB. This is a suite of debugging tools that comes bundled with the Android Software Development Kit (SDK). For ADB profiling, follow these steps:
Ensure that the Android SDK is installed by following Unity's guide for Android SDK/NDK setup:
https://docs.unity3d.com/Manual/android-sdksetup.html
.
Connect the Android device to your desktop machine via the USB cable.
Ensure that the
Development Build
and
Autoconnect Profiler
flags are enabled when the application is built.
Begin building the application with the
Build & Run
option as usual.
Open the
Profiler
window in the Unity Editor and select the device under
Connected Player
.
You should now see the Android device's profiling data gathering in the Profiler window.
For troubleshooting problems with building Android applications and connecting the Profiler to them, consult the following documentation page: https://docs.unity3d.com/Manual/TroubleShootingAndroid.html.
Editor profiling
We can profile the Editor itself. This is normally used when trying to profile the performance of custom Editor Scripts. This can be achieved by enabling the Profile Editor option in the Profiler window and configuring the Connected Player option to Editor, as shown in the following screenshot:
Note that both options must be configured this way if we want to profile the Editor. Setting Connected Player to Editor without enabling the Profile Editor button is the default case, where the Profiler is collecting data for our application while it is running in Play Mode.
The Profiler window
We will now cover the essential features of the Profiler as they can be found within the interface.
The Profiler window is split into four main sections:
Profiler Controls
Timeline View
Breakdown View Controls
Breakdown View
These sections are shown in the following screenshot:
We'll cover each of these sections in detail.
Profiler controls
The top bar in the previous screenshot contains multiple drop-down and toggle buttons we can use to affect what is being profiled and how deeply in the subsystem that data is gathered from. They are covered in the next subsections.
Add Profiler
By default, the Profiler will collect data for several different subsystems that cover the majority of the Unity's Engine subsystems in the Timeline View. These subsystems are organized into various Areas containing relevant data. The Add Profiler option can be used to add additional Areas or restore them if they were removed. Refer to the Timeline View section for a complete list of subsystems we can profile.
Record
Enabling the Record option makes the Profiler record profiling data. This will happen continuously while this option is enabled. Note that runtime data can only be recorded if the application is actively running. For an app running in the Editor, this means that Play Mode must be enabled and it should not be paused; alternatively, for a standalone app, it must be the active window. If Profile Editor is enabled, then the data that appears will be gathered for the Editor itself.
Deep Profile
Ordinary profiling will only record the time and memory allocations made by the common Unity callback methods, such as Awake(), Start(), Update(), and FixedUpdate(). Enabling the Deep Profile option re-compiles our scripts with much deeper level of instrumentation, allowing it to measure each and every invoked method. This causes a significantly greater instrumentation cost during runtime than normal, and uses substantially more memory since data is being collected for the entire callstack at runtime. As a consequence, Deep Profiling may not even be possible in large projects, as Unity may run out of memory before testing even begins or the application may run so slowly as to make the test pointless.
Since this option blindly measures the entire callstack, it would be unwise to keep it enabled during most of our profiling tests. This option is best reserved for when default profiling is not providing enough detail to figure out the root cause, or if we’re testing performance of a small test Scene, which we're using to isolate certain activities.
If Deep Profiling is required for larger projects and scenes, but the Deep Profile option is too much of a hindrance during runtime, then there are alternative approaches that can be used to perform more detailed profiling in the upcoming section titled Targeted profiling of code segments.
Profile Editor
The Profile Editor option enables Editor profiling, that is, gathering profiling data for the Unity Editor itself. This is useful in order to profile any custom Editor scripts we have developed.
Connected Player
The Connected Player drop-down offers choices to select the target instance of Unity we want to profile. This can be the current Editor application, a local standalone instance of our application, or an instance of our application running on a remote device.
Clear
The Clear button clears all profiling data from the Timeline View.
Load
The Load button will open up a dialog window to load in any previously-saved Profiler data (from using the Save option).
Save
The Save button saves any Profiler data currently presented in the Timeline View to a file. Only 300 frames of data can be saved in this fashion at a time, and a new file must be manually created for any more data. This is typically sufficient for most situations, since when a performance spike occurs we then have about five to ten seconds to pause the application and save the data for future analysis (such as attaching it to a bug report) before it gets pushed off the left side of the Timeline View. Any saved Profiler data can be loaded into the Profiler for future examination using the Load option.
Frame Selection
The Frame Counter shows how many frames have been profiled and which frame is currently selected in the Timeline View. There are two buttons to move the currently selected frame forward or backward by one frame and a third button (the Current button) that resets the selected frame to the most recent frame and keeps that position. This will cause the Breakdown View to always show the profiling data for the current frame during runtime profiling and will display the word Current.
Timeline View
The Timeline View reveals profiling data that has been collected during runtime, organized into a series of Areas. Each Area focuses on profiling data for a different subsystem of the Unity Engine and each is split into two sections: a graphical representation of profiling data on the right, and a series of checkboxes to enable/disable different activities/data types on the left. These colored boxes can be toggled, which changes the visibility of the corresponding data types within the graphical section of the Timeline View.
When an Area is selected in the Timeline View, more detailed information for that subsystem will be revealed in the Breakdown View (beneath the Timeline View) for the currently selected frame. The kinds of information displayed in the Breakdown View varies depending on which Area is currently selected in the Timeline View.
Areas can be removed from the Timeline View by clicking on the X at the top-right corner of an Area. Recall that Areas can be restored to the Timeline View through the Add Profiler option in the Controls bar.
At any time, we can click at a location in the graphical part of the Timeline View to reveal information about a given frame. A large vertical white bar will appear (usually with some additional information on either side coinciding with the line graphs), showing us which frame is selected.
Depending on which Area is currently selected (determined by which Area is currently highlighted in blue), different information will be available in the Breakdown View, and different options will be available in the Breakdown View Controls. Changing the Area that is selected is as simple as clicking on the relevant box on the left-hand side of the Timeline View or on the graphical side, although clicking inside the graphical Area might also change which frame has been selected, so be careful clicking in the graphical Area if you wish to see Breakdown View information for the same frame.
Breakdown View Controls
Different drop-downs and toggle button options will appear within the Breakdown View Controls, depending on which Area is currently selected in the Timeline View. Different Areas offer different controls, and these options dictate what information is available, and how that information is presented in the Breakdown View.
Breakdown View
The information revealed in the Breakdown View will vary enormously based on which Area is currently selected and which Breakdown View Controls options are selected. For instance, some Areas offer different modes in a drop-down within the Breakdown View Controls, which can provide a simpler or detailed view of the information or even a graphical layout of the same information so that it can be parsed more easily.
Let's cover each Area and the different kinds of information and options available in the Breakdown View.
The CPU Usage Area
This Area shows data for all CPU usage and statistics. This Area is perhaps the most complex and useful since it covers a large number of Unity subsystems, such as MonoBehaviour Components, cameras, some rendering and physics processes, user interface (including the Editor's interface, if we're running through the Editor), audio processing, the Profiler itself, and more.
There are three different modes of displaying CPU usage data in the Breakdown View:
Hierarchy mode
Raw Hierarchy mode
Timeline mode
Hierarchy mode reveals most callstack invocations, while grouping similar data elements and global Unity function calls together for convenience. For instance, rendering delimiters, such as BeginGUI() and EndGUI() calls, are combined together in this mode. Hierarchy mode is helpful as an initial first step to determine which function calls cost the most CPU time to execute.
Raw Hierarchy mode is similar to Hierarchy mode, except it will separate global Unity function calls into separate entries rather than being combined into one bulk entry. This will tend to make the Breakdown View more difficult to read, but may be helpful if we're trying to count how many times a particular global method is invoked or determining whether one of these calls is costing more CPU/memory than expected. For example, each BeginGUI() and EndGUI() calls will be separated into different entries, making it more clear how many times each is being called compared to the Hierarchy mode.
Perhaps, the most useful mode for the CPU Usage Area is the Timeline mode option (not to be confused with the main Timeline View). This mode organizes CPU usage during the current frame by how the call stack expanded and contracted during processing.
Timeline mode organizes the Breakdown View vertically into different sections that represent different threads at runtime, such as Main Thread, Render Thread, and various background job threads called Unity Job System, used for loading activity such as scenes and other assets. The horizontal axis represents time, so wider blocks are consuming more CPU time than narrower blocks. The horizontal size also represents relative time, making it easy to compare how much time one function call took compared to another. The vertical axis represents the callstack, so deeper chains represent more calls in the callstack at that time.
Under Timeline mode, blocks at the top of the Breakdown View are functions (or technically, callbacks) called by the Unity Engine at runtime (such as Start(), Awake(), or Update() ), whereas blocks underneath them are functions that those functions had called into, which can include functions on other Components or regular C# objects.
The Timeline mode offers a very clean and organized way to determine which particular method in the callstack consumes the most time and how that processing time measures up against other methods being called during the same frame. This allows us to gauge the method that is the biggest cause of performance problems with minimal effort.
For example, let's assume that we are looking at a performance problem in the following screenshot. We can tell, with a quick glance, that there are three methods that are causing a problem, and they each consume similar amounts of processing time, due to their similar widths:
In the previous screenshot, we have exceeded our 16.667 millisecond budget with calls to three different MonoBehaviour Components. The good news is that we have three possible methods through which we can find performance improvements, which means lots of opportunities to find code that can be improved. The bad news is that increasing the performance of one method will only improve about one-third of the total processing for that frame. Hence, all three methods may need to be examined and optimized in order get back under budget.
In general, the CPU Usage Area will be most useful for detecting issues that can be solved by solutions that will be explored in Chapter 2, Scripting Strategies.
The GPU Usage Area
The GPU Usage Area is similar to the CPU Usage Area, except that it shows method calls and processing time as it occurs on the GPU. Relevant Unity method calls in this Area will relate to cameras, drawing, opaque and transparent geometry, lighting and shadows, and so on.
The GPU Usage Area offers hierarchical information similar to the CPU Usage Area and estimates time spent calling into various rendering functions such as Camera.Render() (provided rendering actually occurs during the frame currently selected in the Timeline View).
The GPU Usage Area will be a useful tool to refer to when you go through Chapter 6, Dynamic Graphics.
The Rendering Area
The Rendering Area provides some generic rendering statistics that tend to focus on activities related to preparing the GPU for rendering, which is a set of activities that occur on the CPU (as opposed to the act of rendering, which is activity handled within the GPU and is detailed in the GPU Usage Area). The Breakdown View offers useful information, such as the number of SetPass calls (otherwise known as Draw Calls), the total number of batches used to render the Scene, the number of batches saved from Dynamic Batching and Static Batching and how they are being generated, as well as memory consumed for textures.
The Rendering Area also offers a button to open the Frame Debugger, which will be explored more in Chapter 3, The Benefits of Batching. The rest of this Area's information will prove useful when you go through Chapter 3, The Benefits of Batching, andChapter 6, Dynamic Graphics.
The Memory Area
The Memory Area allows us to inspect memory usage of the application in the Breakdown View in the following two modes:
Simple mode
Detailed mode
