Visual storytelling using WebGL
Recently we were working on a redesign of the uformit website. Uformit, an online marketplace for personalized 3D design, was already presented at the 3D Printshow in London and New York, but never announced to the public. It features a WebGL powered product display, allowing the user to directly form the product by adjusting its parameters and see the result in real-time.
However, during the show, it was easily possible to explain in person how it worked, what’s the story behind it and what is so special about the technology that allows designers to create products that can be personalized to be a truly unique piece. We first thought about creating a video that would explain the whole process, but after a few discussions we quickly came up with the simple, yet obvious idea: If we have the product as a 3D object on the website, why not use exactly this to explain the story around it?
Our designer Kevin Kalde came up with a design idea we instantly fell in love with: He combined traditional visual storytelling techniques with the use of a WebGL rendered object that moves from page to page, allowing us to explain the different steps and aspects in the creation of a design on uformit without losing focus. And after developing a first prototype, we all agreed that it really felt right. Unfortunately, a few issues (dragons) came up…
Firefox: Works great (until it freezes)Even without using background workers for loading the model, Firefox was the only browser which seemed to handle the model-loading without any jittering. Unfortunately, after some time we stumbled upon a huge issue: Under certain circumstances, it seems the browser (v28) is likely to freeze when the WebGL canvas is hidden and then re-appears, either by hiding it by code, or by scrolling past the element and scrolling back.
After checking out the current nightly build, we noticed that this bug seems to be fixed in version 29, which is scheduled to be released on April 29th. This way, we just decided to live with this problem for a few days and to disable features that cause the freeze where possible. Perhaps there would have been a way to mitigate the problem by doing some tricks, but sacrificing code quality and stability to mitigate an already fixed bug (and additionally wasting even more resources on the problem than we already did), we decided to just leave it for now.
Update: Unfortunately, the bug still exists in the production version of Firefox, so it seems we are forced to find a way around this. Since the debug version seems to have no problems with the page, this might be a lot of trial and error…
IE: WebGL light
Internet Explorer up to version 10 is not able to display WebGL content at all. Although version 11 supports WebGL, there are a few things you cannot use, explained by Microsoft in this post. They show workarounds for some of the problems, but keep in mind that some libraries like three.js are not willing to adjust code due to missing features (which is basically a good idea), so you might have to keep an eye on this by yourself. However, Microsoft is working on getting everything in place.
Safari: So optimized your animation does not work
Looking at the numbers, it seems Apple did a great job in tweaking Safari’s performance. Trying to actually use this performance for implementing animations, you slowly get the impression they don’t do it faster, they just do less. Of course, it is well known that some methods are well suited when it comes to web animations and others aren’t, but in case you have to do calculations based on scrolling progress and position of other elements, you rely on having these updated very often as well. Even when using animation frames and getting acceptable high frame rates, the animation we implemented seemed to run not very smoothly, especially when moving synchronously with other elements on the page while scrolling. After investigating a little further, we recognized that the values we used for doing position calculations were just not updated very often, even though the page itself scrolls smoothly.
Additionally, Safari seems to sometimes have a buffer problem when changing the size of the WebGL context, causing a strange flickering effect during size-related animations, and causing real problems for things like a zoom function, causing the whole screen to flicker, looking like a bad designed computer malfunction in an old science fiction movie.
Of course, at least for position calculations, there are ways around this, like handling the scrolling by oneself, so at least everything moves synchronously slow, and of course this is not directly related to the use of WebGL, although having the WebGL container on the page does not exactly increase performance, so you run earlier into these issues. However, we decided to completely disable WebGL in Safari for this specific page, having a fallback page which is less interesting, but at least moves as fast and smooth as intended without being forced to do crazy tricks. We really hope that Apple works on this for the next updates of Safari - It’s correct that a browser should not necessarily try to be optimized for a certain type of pages, but forcing the developers in a specific direction by just not giving them the tools to build all kinds of webpages at the same quality cannot be the correct way, either.
Chrome: Thank you, Google
First of all, we used this browser during development, so perhaps there are things that work in other browsers and not in Chrome. However, there were no bad surprises - nothing behaving slow, no workarounds needed. It did not flicker, and did not display strange things. So: Thank you, Google!
WebGL - it’s almost there!
Despite the few problems we had during development, the feedback we got for this page really makes up for it. People not only liked the design of the page and the fact that the story builds up around a moving 3D object, it also really helped them to understand what uformit is about, and how the process we described on the page worked. So, yes, of course, we would do it again!
Do you have experience with WebGL for this kind of pages? I’m happy to hear from you on this blog or on Twitter.
