Oh, 3D

A few years ago, I complained quite extensively about the sad state of the 3D Web. Nowadays, things are entirely different, and almost exactly the same. Let me explain.

Last week, Google announced O3D, their stab at an open standard for 3D Web development based on Javascript. Well, it’s Javascript, plus a native compiled plug-in that does almost all of the actual work. And there’s the rub. No install, no work.

People somehow think that "running in a browser" is some magical feat of performance, when in fact plugins are just native applications that use the browser windows instead of their own desktop window. And O3D is just another compiled application that provides hooks for Javascript code to control it. Running 3D in Flash or Silverlight in any performant way is a magical feat, but only because sandboxing plugins like Flash and Silverlight have chosen to eschew native 3D hardware support in favor of safer CPU-only code, finally dipping some toes in the water this year. No native 3D support means slow, circa-1995 graphics, end of story.

The question will be, can Google get everyone to install their plugin? If so, it could become as ubiquitous as Flash or Silverlight and therefore be a viable candidate for the common platform for Web 3D. Of course, it also assumes that people, including developers, will like using it. A casual look at the Javascript bits of source code for several of the demos Google put out dashed my hopes that they’d cracked the nut of making 3D easy to use.

My guess is no. Without compelling applications (streaming video did this for Flash), people won’t install O3D and developers won’t develop for it. It’s the classic cold start problem. In fact, Google would be smart to use O3D to provide better video playback for YouTube to drive adoption.

Meanwhile, some very smart approaches, like Unity3D, which uses C# plugins to provide sandbox security for unknown code, do as good or better job at the same idea. Unity has its own integrated WSIWYG editor, web packaging systems for multiple OSes, and comes with professional support. Other approaches, like Vivaty (also a browser native rendering plug-in) keep alive the last major attempt at Web 3D standardization, X3D, which was born VRML, Cosmo, and SGI Inventor before that. Some ideas never die.

The shining star in all this is the Mozilla and Opera efforts at adding native 3D canvas support. You see, if there’s no plug-in, then there’s nothing to install. Web pages could leverage 3D content as long as people are running a recent browser. But these approaches are not entirely compatible and it’s been slow going. Khronos is also trying to get OpenGL ES in browsers, which again could do well if it’s adopted, chicken and egg.

My own take is that no Web 3D system will truly work until 3D web content is made as flexible as text and imagery. Right now, my fonts will scale to my wishes and text will flow to fit my screen width. With 3D graphics, the equivalent is generating objects via declarative modeling, not polygons. None of the approaches I’ve mentioned really make use of this fact. And because of it, no matter how fast they get Javascript to run, you’ll still see that "loading…" 30 second delay in starting up any real 3D scenes, not to mention any crash due to bad or malicious data bringing down the whole browser or worse. And that, right there, is the kiss of death.

The problem isn’t that there isn’t one common language for 3D, or that it doesn’t run in a browser. The problem is human nature, and very few of these efforts seem to be designing for the real world.

Leave a Reply

Your email address will not be published. Required fields are marked *