Recently, Firefox and Webkit have implemented WebGL into beta builds of their browser engines.  I’ve followed some of the comments on this development and frankly, I don’t get it and can’t see where 3D in a browser improves the user’s browsing experience.  Here’s why I believe what I do.

1) 3D is a completely different environment than browsing.  The input mechanisms, the viewport mechanisms and user expectations are not even close to being the same. 

  • WASD + mouse look rules the roost in 3D and has no meaning what-so-ever in 2D browsing. 
  • The camera is fixed position and not movable in 2D browsing whereas it’s completely customizable in 3D navigation. 
  • In 2D space you move the environment to reveal parts hidden from the current viewport as defined by the fixed camera.  In 3D you move the camera while the environment remains fixed in position.
  • In 2D space the user may or may not have an avatar.  In 3D space it is mostly expected that there is an avatar even if it is implied by the position of the camera.

2) Today’s browsers with their Javascript engines are completely incapable of producing reasonably high standard 3D real-time graphics.  Javascript engines take up to multiple seconds to render a page where as a dedicated 3D engine will do the same for a 3D scene 60 – 100 times in the same time frame.  Javascript would need at least an order of magnitude increase in speed and native floating point acceleration to even be capable of year 2000 real-time graphics.  This is why Unity’s plugin architecture or the Torque plugin based architecture are better for real-time 3D.  Even Silverlight is a better implementation of real-time 3D in a browser than native 3D in the DOM but real-time 3D no matter how it is implemented still suffers from the other problems mentioned in this post.

3) How do you resolve the user interface confusion between the two environments?  Consider the confusion that results from a simple text editor embedded into a browser window.  Which scroll bar takes priority?  How many times have you had trouble controlling both the editor scroll bar and the browser scroll bar?  Now think about the editor as a viewport into a 3D space.  Is the camera attached to the browser scroll bars?  Is it fixed on the screen?  If it’s fixed on the screen, then what happens when I scroll the camera origin off the page using the browser scroll bars while leaving a portion of the 3D viewport still visible in the browser?  What a mess.  User confusion can only result and increases exponentially with every piece of interaction added to the 3D space embedded in the browser.  Consider the clash of input mechanisms that would result from adding a World of Warcraft client into the middle of a web page complete with hotkeys where the Warcraft client forms one element of many elements on the page. Confusion is all I can think of.

I’m of the mind that the only way 3D truly works on the web is if the browser is used as a delivery mechanism for an experience that completely overrides the browsing experience. Browsing in 2D and navigating in 3D are mostly exclusive interactions.  Metaplace does this by taking the application to full browser mode.  Can 3D be embedded in a web browser; sure it can.  Should it be a native part of the DOM, I don’t believe so for all the reasons outlined above.  Metaplace uses a plugin (Flash).  Unity 3D uses a plugin.  Torque uses a plugin.  All of these, plus Flash and Silverlight are architected this way because current browsers don’t have native support for what they are trying to do.  Interestingly, this is one of those times where the first implementation is the right implementation.  Real-time 3D has no business becoming part of the DOM and should remain in the realm of a dedicated plugin.