24 Feb Egowall and WebGL (Part 2) – Art and Asset Issues

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™.

In Egowall and WebGL (Part 1) – How We Got Here we talked about Google’s early 2015 removal of support for the Unity plugin in Chrome, making it necessary to move Egowall to Unity 5.

Our first step in that process was ensuring a successful upgrade of our code base from the Unity 4.3 Web Player to the Unity 5 Web Player (i.e., no performance degradation and no loss of functionality with the usage of Unity 5 functions). 

Egowall has over 10,000 game objects (e.g., audio, fonts, menus/UI, models, materials, and textures), which are grouped into individual Unity asset bundles and delivered via our Content Delivery Network on an as-needed basis based on player interaction.

As part of the upgrade we needed not only to guarantee that the code base worked, but also that all the asset bundles behaved and functioned as before (or better).  After almost 700 man-hours of slogging, we have resolved all unexpected issues, completed the successful upgrade of the code base, and verified that everything works.

In future blog posts in this series, we will compare performance between the Unity versions. But in this one, we will cover the art and asset-related issues we encountered during the upgrade.

TAG MANAGER INDEX SHIFT

 After allowing the Unity auto script updater to execute the upgrade, we found that the one of our defined tags in Unity’s Tag Manager was shifted by one slot. This happened because we had removed an unwanted tag in our code base in the past, leaving an empty entry at index 1.

During the upgrade this empty slot was removed by Unity, which caused all the subsequent tags to be offset by 1. To address this we updated our tag class to reflect the new values shown in the Tag Manager. The main impact of this shift was on our asset bundles.  We set our tags in the bundles and this tag shift required that all of our bundles be rebuilt.

The bundles were going to have to be rebuilt anyway to be compatible with Unity 5. So this issue was taken care of by the required rebuild of our 10,000 assets. No additional action was required.  

Transitioning from Beast to Enlighten

While Enlighten – Unity 5’s new light mapping tool – has a lot to offer, we encountered some issues updating from Unity 4’s light mapping tool, Beast. 

Foremost among them was loss of the ability to specify absolute UV cluster locations on a given lightmap. With Beast we could layout UVs in advance, specifying a specific lightmap for each object, and be assured its UV coordinates could directly match the UVs as laid out in a given object.

Enlighten instead packs object UV clusters as best it can into as few lightmaps as possible. This is useful if you’re not relying on absolute UV coordinate to pack several objects into a lightmap as efficiently as possible.

Additionally, in early versions of Unity 5, Enlighten’s UV packing algorithm created a lot of problems for UV clusters that weren’t square, causing UVs to squash or stretch accordingly. This would lead to distorted or inaccurate lightmaps at runtime.

Luckily, this issue was addressed and fixed by the Unity development team in Unity 5.2.

Light Probes

Another issue encountered during the upgrade was light probes. In Unity 4, Beast generated a light probe file that could be pulled from an asset bundle and read. This allowed us to swap out light probe information on the fly.

Light probe information is now stored in a Lighting Data file, which, unfortunately, cannot be accessed from an asset bundle. We were ultimately able to circumvent the issue by utilizing a new feature in Unity 5 that allows us to append scenes, and pull in different Lighting Data attached to those scenes.

On top of this, there were some initial issues with using light probes in Gamma color space being much brighter than the lights that generated them indicated they ought to be. Simply switching to Linear to bypass the issue simply introduced more issues with some shaders no longer behaving as expected.

Fortunately, the issue with over-brightened Light probes in Gamma color space was fixed in Unity 5.3.

Shaders

Carrying over Unity 4’s legacy shaders presented an additional challenge in that some shaders no longer functioned as they used to after being updated to Unity 5. For example, materials using the Diffuse shader no longer appeared to interact properly with light maps, causing blowout.

 In this case, the only solution seems to be simply avoiding the use of these problem shaders, until the possibility of a fix at some point in the future. The image below shows the difference.

So stay tuned to find out what we have learned, what we did to address the issues identified, and where we are in the process. Our story continues with Egowall and WebGL (Part 3): Code-Related Issues.

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