Our Journey to Unity 5 and WebGL

Check out our Unity-based social networking platform to see what you can do with Egowall. Then sign up for a free account and start using it to be The Real You™.


Unity Logo

The process of upgrading a large, complex application like Egowall to Unity 5 and WebGL™ is neither as easy nor straightforward as you might think - or hope. Beyond the fact that WebGL is significantly slower than native code, there are many other things to deal with.

We are sharing a series of posts with behind-the-scenes information about our journey on this road. In the articles, we talk about the issues we have encountered during the conversion and how we dealt (and are dealing) with them.

WebGl Logo

Below are links to all of those posts in a single place. We wanted to make it easy for newcomers to the series to read any or all of them. As additional articles in the series are written, this post will be updated.

We hope you get value from the information contained in the posts. Please share any thoughts you may have in the comments and let us what your path to Unity 5 and WebGL has been like.


Egowall and WebGL (Part 1): How We Got Here

In the first post in our series, we talk about Google’s early 2015 removal of support for the Unity plugin in Chrome and the resulting impact on our development process.

Egowall and WebGL (Part 2) - Art and Asset Issues

The second post covers the art and asset-related issues we encountered during the upgrade and how we dealt with them.

Egowall and WebGL (Part 3): Code-Related Issues

In this third post, we summarize the code base changes we had to make in order to resolve Web Player-related issues encountered during our Unity 5 upgrade.

Egowall and WebGL (Part 4): Web Player Performance Comparison

The fourth post summarizes the results of our performance testing at the end of the Unity Web Player 5.3 upgrade, comparing it to Web Player 4.3.

EGOWall and WebGL (Part 5): WebGL Issues

Coming soon.


WebGL and the WebGL logo are trademarks of the Khronos Group Inc.

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

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):

  1. 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.
  2. Rendering performance slightly decreased in regards to the draw calls and tri count batching.
  3. Material memory went up significantly. (NO LONGER ACCURATE AS OF MARCH 30, 2016).

Web Player 4.3
Empty Space

Web Player 5.3
Empty Space

Web Player 4.3
Loaded Space

Web Player 5.3
Loaded Space

FPS Range

66-70

64-69

66-69

66-70

Tri Count

9.8K

16.5K

153.3K

155.0K

Batched Tris

208

448

166

7700

Draw Calls

76

107

532

472

Batched Draw Calls

21

35

19

114

Texture Count

1427

1439

1589

1586

Texture Memory

33.5MB

34.9MB

131.4MB

130.2MB

Material Count

213

598

556

638 (*)

Material Memory

113.8KB

0.6MB

293.8KB

0.7MB (*)

VRAM Usage

18.9MB - 29.5MB

21.5MB - 33.0MB

18.9MB - 79.3MB

23.7MB - 84.5MB

Game Objects

518

508

2657

2647

Total Objects

5383

5963

13763

13948

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.