I started following WebGL a few months ago when it was in beta in several browsers. Many creative web folks were already working with it, and some of the experiments were spectacular. Fast forward to the present, and Google Chrome now officially supports WebGL (although your computer may not be up to it), and Google has a WebGL Experiments website.
I was fortunate to be contacted by a client who needed a browser based visualization solution, and was willing to fund a short “show me” pilot project. The objective was to create a small demo that would run a typical architectural scene of 500K triangles at 30 frames per second. A secondary objective was to fail fast – there was no point in going on if download times and interactive performance were dismal. It would be a win for both of us regardless of the outcome – I was going to get some practical experience in real-world WebGL development, and the client would have enough data to navigate the next fork in their visualization roadmap.
Since the client’s files were in Collada DAE format, I was able to try them out in some of the existing WebGL frameworks such as GLGE and SpiderGL, which happened to have Collada import functionality and demos. Results were mixed: on the one hand, setting up a demo for an architectural scene was relatively easy (for GLGE, I started from the Quake-style demo). On the other hand, the scene had some quirks (such as multi-texturing with multiple UV maps per surface) that the frameworks didn’t handle. And performance was disappointing: 3 FPS for a 500K-triangle scene in GLGE. Nevertheless, my clients seemed to be excited by the fact that their scene could be displayed in a browser at all.
GLGE is an impressive framework, and there is much to learn by browsing its source code. It is a “how to” for a number of techniques such as shadow generation, canvas textures, collision detection, and object selection, and I will refer to it when I want to see examples of advanced techniques. But I concluded, wrongly or rightly, that its generality was what lay behind the disappointing performance. If your scenes are not as large as the ones I was using, it may well work well for you. But my next step was to write a display engine that exploited the relative simplicity and predictability of my scene to get maximum performance.
I quickly discovered that Lesson 10 involved downloading a small scene and navigating it Doom-style, so I skipped ahead and using it as a scaffolding to build the demo, slowly replacing most of what was there. And after a day or two I had a pseudo-architectural scene that ran 506K triangles (spread over almost 600 objects, most of them textured, some semi-transparent) at something like 26-28FPS (on my MacBookPro) . Success! This was certainly enough for the client to greenlight a second phase.
2 Replies to “WebGL in the real world – a short case study – Part 1”