IntoWebGL: A postmortem of porting to a post-plugin existence
IntoScience is large● 124 unique activities mapped to curriculum.
● 6 interactive 3D environments.
● 38 ‘quests’ (including multi-part, ambience & portals)
● Multiplayer live science quiz.
● Always on-line.
● Teacher control over student navigation.
● Reporting
● And much more!
IntoScience is Cross-Platform● WebPlayer
● iPad
● Standalone (Windows & Mac)
● Windows App Store
● Working Android prototype
● And now… WebGL!
Our customers are schools● Slow networks● Slow machines● Restrictive firewalls / proxies● Limited IT support
Basically, IntoScience is rather ambitious● Small team (<15 people)● Lots of 3rd party Assets from the Asset Store
○ NGUI○ AStar pathfinding○ Marmoset○ Json utils○ Tween utils○ Playmaker○ Mega-Fiers○ ...and many more
● Lots of Playmaker driven content (eep)● So the LEAST likely app to be able to port smoothly into a new platform like
WebGL
Why WebGL?● Chrome were the first to move away from the old plugin structures.
● There is no Chrome without using WebGL
● Chrome is 46.1% of our browser users (28% of all platforms)
● No choice but to support it if we want to keep using Unity (we do!)
● Google has forced our hand in the short term
● In the long term everyone will need to use it anyway because…
● No plugin!
○ Makes it a lot easier to deploy to schools
○ Easier to release new versions
WebPlayer is dead● The rest of the vendors will soon be following the same path as Chrome
● WebPlayer won’t exist in Unity 5.4
● Reality is WebPlayer is already gone. You should already be using
WebGL.
● The problem?
WebGL is still a ‘Preview’● Not quite there yet… but close!
● Clearly a work in progress.
● Must be treated as an entirely new platform
● Many missing features
● Critical bugs from all sides
● BUT!! It’s still possible to get something working
IntoScience on WebGL
Current stats
● Initial download of 21Mb of compressed data and javascript.
● After the initial download the results should be cached.
● But still have to compile the javascript every time.
● About 10 seconds load time on an i7 with fast internet. (after initial load)
● 5 to 6 minutes initial load time on a slow chromebook
● 1 to 2 minutes on subsequent loads.
IntoScience on WebGLFirst release (Google September deadline)
● Had problems with memory
● Tended to crash if re-loading the page.
● 3D scene performance was poor.
IntoScience on WebGLSecond Release (World Education Games)
● Lots and lots of students (800,000)
● Scary
● Solved the problem with the memory and stability
● Improved 3D performance.
What went right?● Released on time.
● Multiple releases in short period of time.
● Most of the content ‘just worked’
● Unity managed to fix the most critical issues before the deadline.
● Still sharing the codebase between all our platforms.
● Content team didn’t have to worry about the WebGL differences.
● Now have a plugin free environment.
What went wrong?● Being on the bleeding edge of Unity releases is problematic.● Bug fixing ‘whack-a-mole’● WebGL was/is ‘coming in hot’ which means we were too.● Cache fun.
○ Always be clearing○ Require production asset versioning.
● Some audio assets crash on import.● Lots of memory issues● Lots of performance issues
WebGL performance● WebGL is super hard to profile accurately. Very unstable at the moment.
○ To profile memory, start with the profiler turned off. Switch it on and take a memory snapshot before it crashes.
○ Don’t profile memory usage in the editor game window.
○ Luckily, framerate profiling in the editor is almost accurate enough to point you in the right directions.
○ CPU will pretty much always be the problem at the moment○ Reduce draw calls as much as possible ○ Make sure your scripts are optimised.
● Framerate of WebGL is about half of WebPlayer for the same scene.● Using asset bundles turns off static batching. Manually recombine with
StaticBatchingUtility.Combine(..)
Cross-Origin Resource Sharing (CORS)● CORS!● WebGL requires CORS headers for all the www calls you make.● This means you have tell your webserver to add them.● http://enable-cors.org/server_apache.html● There are no movie textures in webgl. Use the WebGLMovieTexture plugin.● Add video.crossOrigin = “anonymous”; to the .jslib file
Our WebGL App Goals● Smallest possible initial download.
● Bundle/Stream everything.
● Minimise wait time with scaling asset detail levels.
● Avoid third party plugins!
● Remove all exceptions (not easy).
● Generally try to reduce codebase size.
Asset Bundles● “chunk” your asset bundles as much as possible.
○ Promotes better caching.
○ More flexible detail level scaling.
○ Make sure to AssetBundle.Unload(..) asap.
○ Only load/unload one bundle at a time.
○ Download one asset at a time.
Asset Bundles● Regularly sanity check asset bundle contents.
● Don’t use the old asset bundle system. (bugs)
● Use crunched texture compression for everything.
● Compress all your meshes as much as you can.
Code Stripping and Asset Bundles● Use namespaces to fix stripping problems.● Brute force the rest. Find the errors and add to list.
○ Look for “Could not produce class with ID XXX”
○ http://docs.unity3d.com/Manual/ClassIDReference.html
WebGL Memory● Memory usage was one of the key limitations● Try set your WebGL Memory Size to a max of 256 for
stability. This can be hard.● Turn off ‘Data Caching’ for now!!● Recommend you don’t use www.
LoadFromCacheOrDownload(..) for now!!
Random Tips● Use the chrome developer tools. (Ctrl + Shift + I)
● Don’t try inspect/debug the .js files!
● Chrome can throttle bandwidth now. Useful for testing for clients with poor
internet.
● Use the .jslib plugins for unity->javascript communications.
● Setup a local Apache server to test your stuff. I use XAMPP.
Random Tips● For too long we didn’t have a backspace key!!
● Here’s useful snippet for the HTML wrapper: (Backspace and ESC blocking)
TIP: Testing Webgl Apps● Unity dev may not have experienced a lot of these
issues before. ● Maintain a local web server.● Modify local hosts file to allow cross-domain fakery.● e.g. Add:
○ 127.0.0.1 mydomain.com○ This will let me access my local server via http:
//mydomain.com and test the CORS setup.
The Future● Multiple vendors working on making WebGL better.
● New technology coming to improve WebGL/javascript performance
○ WebAssembly - faster, smaller download/compile times
○ SIMD.js - faster math stuff
○ Shared Array Buffers - threading
○ Unity tools for code stripping.
● Stick with it! Things will constantly improve!
http://intoscience.com/signin/
Questions and Live Test!!
Questions?
IntoSciencehttp://www.intoscience.com
Ryan Alcock
Rob Lee