09 Mar Egowall and WebGL (Part 4): Web Player Performance Comparison
UPDATE: This post was modified on March 30, 2016 to correct some of the measurements in the table at the bottom. Numbers which were adjusted are marked with an asterisk (*).
In the first part of our Egowall and WebGL series, we discussed Google’s early 2015 removal of support for the Unity plugin in Chrome, making it necessary to move Egowall to Unity 5. Then in part two we detailed the art and asset-related issues we encountered as we began the upgrade.
Most recently, in part three we talked about the asset-based and code-based issues we encountered and the solutions/workarounds we implemented to address them.
Our next step in the migration to Unity 5 was to ensure that there was no performance degradation between the Unity 4.3 and Unity 5.3 web players. We needed to identify any Web Player-specific performance issues so that when we migrate to WebGL, we will be able to isolate any other performance problems encountered as being specific to WebGL.
In this blog post we want to give you the summary of our performance testing at the end of the Web Player 5.3 upgrade.
Performance Baseline and Metrics
We have an established group of performance metrics that we assess against sets of baseline measurements on each Unity upgrade and Egowall release. The baseline used in this instance was a test case with the following scenarios:
Environment: Living Space (Castle)
Graphic Settings: High, and from the player’s starting position after loading into the living space.
An Example of the Living Space Used in the Referenced Test Case
Variation A: Empty Living Space (Castle)
- No user interaction objects
Variation B: Loaded Living Space (Castle)
- Unique mix of 112 user interaction objects such as furniture, photos and mini-games
- All objects are positioned where they are at least partially visible from the player’s view at the starting position
- All visible living space surfaces have a custom material applied to them
Variations A and B were executed identically using both the Unity 4.3 Web Player and the Unity 5.3 Web Player. We observed the following (details can be found in the table below):
- A drop in frame rate was observed on variation B when moving large stacks of objects all at once, which makes the physics exponentially more complex.
- Rendering performance slightly decreased in regards to the draw calls and tri count batching.
- Material memory went up significantly. (NO LONGER ACCURATE AS OF MARCH 30, 2016).
|
Web Player 4.3 |
Web Player 5.3 |
Web Player 4.3 |
Web Player 5.3 |
|
|
FPS Range |
|
|
|
|
|
Tri Count |
|
|
|
|
|
Batched Tris |
|
|
|
|
|
Draw Calls |
|
|
|
|
|
Batched Draw Calls |
|
|
|
|
|
Texture Count |
|
|
|
|
|
Texture Memory |
|
|
|
|
|
Material Count |
|
|
|
|
|
Material Memory |
|
|
|
|
|
VRAM Usage |
|
|
|
|
|
Game Objects |
|
|
|
|
|
Total Objects |
|
|
|
|
Stay tuned to find out more about what we have learned on the way to Unity 5 and WebGL.
WebGL and the WebGL logo are trademarks of the Khronos Group Inc.
Alex Vanden Abeele
Posted at 12:46h, 15 MarchInteresting series, looking forward to the next post. Did you find out why your material count almost doubled?
Jack
Posted at 19:37h, 03 JuneInteresting. Did you use asset bundles? Super curious on your take on that.