HTML5 & WebGL

Daniel Davis – 16 May 2011

Innovation comes from funny places. In 2005 Apple introduced the Dashboard; a largely impractical application that overlaid the desktop with little Widgets reminding you of the time, weather, and stock-market prices. The most redeeming feature of the Dashboard was that when you added a new Widget to the Dashboard it made the screen ripple like it was made from water and, since not all computers at the time were powerful enough to do this, the Dashboard’s rippling became an unofficial performance benchmark. Despite the frivolous nature of Dashboard, the Widgets have an important legacy (other than being a precursor of the iPhone apps).

Dashboard Widgets are made up of HTML, CSS, and Javascript – the same stuff websites are made from. Except Apple added one extra word to the Widgets vocabulary: canvas. This little, propitiatory, modification of the HTML language allowed Widget designers to write Javascript code that drew shapes in the Widget – much like Processing.  Three years later, in 2008, and HTML standard was updated to standardise the drawing of drop-shadows across browsers (a big deal if you are a webdesigner) and to include the canvas tag as part of the official HTML standard (a big deal if you are an architect). Now in 2011, ‘canvas’ has been extended to allow the drawing of 3d shapes with WebGL.

What is WebGL?

Prior to WebGL the only practical way of drawing 3d objects in a web-browser was through a plugin like Flash or Java (not the same as Javascript). Plugins are slow because the when the plugin code decides to draw a line, it must ask the plugin, which must ask the webbrowser, which must ask the operating system, which must ask several other layers of the computer, to draw the line onscreen. This journey through the grapevine is inevitably slow. WebGL skips these layers by allowing Javascript access to the GPU, meaning WebGL can send data straight to your videocard to be rendered. WebGL also has the advantage that it is native to the browser, so users don’t need to download or install any additional plugins to view 3d content – currently only the latest versions of Chrome and Firefox support WebGL, but all browsers (except possibly IE) will support it in the coming months.

Why WebGL is important to CAD

It is inevitable that in the near future CAD models will be able to be viewed in a browser using WebGL. There are already some early examples of this happening with PythonOCC/WebGL which exports 3d models to WebGl; the Surface Explorer, which draws doubly curved surfaces from equations; and most beautifully in the Google Body Explorer, which allows you to interact with a rather complex 3d model of the body. And I have it on good authority that at least one major CAD manufacturer is making a ‘dropbox for CAD files and project data.’

With 3d models now viewable on the internet, the critical question becomes how much interaction will be enabled. Will you be able to view associated model data? Will you be able to modify a model? Will you be able to generate a model? Will the browser become your preferred way of designing?  Some early applications like CloudSCAD, 3dTin, Shapesmith (shown above) and TinkerCAD, would say ‘yes’ to all of the above. There are some advantages to this approach:

  1. Users don’t have to download software and updates can be made instantly.
  2. Theoretically the application is cross platform and cross device.
  3. Users can use less powerful computers to do more complex tasks by offloading the work onto the server. The server might be able to do the rendering or object population, the server could also load a really large model while giving the user a simplified version of the area they are working on. It is also a better use of resources to have one server constantly working hard rather than every user intermittently working their computer hard.
  4. Live connections to other databases. A few years ago I helped start ProductSpec, and it has always been on the roadmap to have the Productspec database linked to CAD models so that as manufactures change product data, this is reflected, in realtime, within the model.
  5. All of the associated advantages of cloud computing: less piracy, more payment granularity, online storage/backup ect.

However even with the examples of early WebGL CAD software and all the advantages listed above, I am still not entirely convinced we will be designing with WebGL in the future. For one thing CAD manufactures, who have a lot invested in large code bases, are going to be slow making the switch. There may be a new generation of companies that develop WebGL applications but (at least initially) they are going to look underdeveloped compared to their desktop rivals. Secondly, as painful as C++ development can be, writing a CAD program in Javascript is simply sadistic – there are problems with browsers being consistent, there are performance issues, there are security issues. Instead I think WebGL is going to spark a new generation of software, which are more interactive than a printed drawing and less featured than a full fledged CAD package.

It is interesting to see that the next iteration of architectural representation isn’t emerging from the past 20 years of discourse flowing out of architectural theorists and philosophers, but it comes from a technology Apple developed to add a bit of bling to the desktop.