Optimizing Large Scenes in Unity

How we put 5,000 bases on a planet and lived to tell about it

Noam GatTacticsoft

@noamgat

Hello!

Noam Gat

CTO @ Tacticsoft

Past - JoyTunes, Omek Interactive, OGRE

Earth Arena Case Study

Tacticsoft’s upcoming Mobile Strategy MMO

Take over the world with your friends!

http://www.eartharena.com

Earth Arena Case Study

5,000 bases on a planet, with 3 levels of detail and smooth transitions

The challenge (today) is not to make a single object look good, but to make an entire scene run smoothly

- Frames per second- Loading Time- Memory footprint- Artist pipeline

Scene Management

Step 1 - Prove the problem

Step 1 - Prove the problem

Premature optimization is the root of all evil

Naive solution

- Instantiate a prefab for every base in the world- Each object contains 3 LOD objects- Show / hide object groups based on camera

https://youtu.be/Q2gNauFxwMA

Naive solution

Worked surprisingly well!

- It was faster to disable/enable renderers rather than game objects

- Started becoming heavy on iPhone 6 with 1k objects, but was good enough

Test Driven Development (TDD)

Not only about unit tests.

Create a consistent, easy to run, reproducible environment to check that what you created meets your expectations.

Stress Test, Take 1

https://youtu.be/fjEkRZsrUSA

Step 1 - Prove the problem

Not stupid, but naive.

Step 2 - Investigate

Step 2 - Investigate

Between the different aspects of the scene, which one was causing the crash?

- Frames per second- Loading Time- Memory footprint- Artist pipeline

Unity’s Toolset

Benchmarking

A few experiments revealed:

- Unity objects / components cost ~1k per instance

- 5k objects, 10 GOs/object, 3 components / GO -> 150k components -> 150MB scene

- Dynamic batching was the biggest CPU hit, and batching was also becoming a problem

Step 3 - Solve

We wanted a solution that has:

- A stable memory footprint in large worlds- Good FPS / batching performance- Looks like the previous solution- Won’t be a nightmare to control artistically

Solution approaches

Two approaches:

- Pooling - Return out of camera objects to a pool, reuse them when the camera moves

- Baking - Dynamically a large mesh with many objects packed together (similar to Unity’s static batching)

Solution problems

Pooling - When looking at the world from far away, we see half of the objects in the world, so pooling is only a 50% reduction

Solution problems

Baking - When looking at the world from up close, we have 3d models with relatively high poly counts and some with animations

Solution

The problems never happen at the same time, and we can predict which will happen when.

Solution (Artist side)

Baked objects go to baking pipeline

Instanced objects go to pooling pipeline

Array of Structs / Struct of Arrays

- Array of structs is the intuitive way to look at things (every object has several properties)

- Struct of arrays is a bit weird (several properties have values for every object)

Struct of arrays allows us to look at a vertical of all objects (“All baked LOD1 objects”) and do something special for them

Baked pipeline

Not MonoBehaviour, ~ 200 bytes memory

Minimal amount of information to render and order

Baked pipeline

Baked pipeline

Less batches, much less game objects / components

Baked pipeline gotcha

When viewing a lot of sprites from far away, better to turn off “Tight” sprite packing to allow more sprites in same amount of geometry

Pooled pipeline

Which instance to instantiate

Where to put it

Pooled pipeline

Rest of pooled pipeline reiles on previous “camera culling” method from first naive attempt - instead of disabling / enabling objects we take / return them to the pool

Object permutations

The objects have different properties (colors etc) based on their role in the world.

We do not want a different prefab for each permutation of each object.

“Visitor” Design Pattern

“Visitor” Design Pattern

“Visitor” Design Pattern

The visitor pattern allows us to easily reuse prefabs, making modifications as needed in both the baked and pooled pipelines.

It puts healthy design constraints on what you can and can’t put on objects placed on the map (MVC principles etc)

Step 4 - Test

Number of objects

Number of batches

https://youtu.be/Jys5bdeJCtM

Device performance

https://youtu.be/skRCgq093Mc

The future...

https://youtu.be/sOnzYTT793Y

TL;DR

- It’s OK to be naive for 99% of the code- TDD applies to optimization as well- Many approaches to solve problems, the

correct one stems from understanding the problem

- Several design patterns are very useful for optimization

Thank You!

Come play our games!http://www.eartharena.com

http://www.tacticsoft.net

@noamgat