199
13
3DinaWebBrowser
Rémi Arnaud
Screampoint Inc.
13.1ABriefHistory
The idea 3D graphics in a web browser is not a new concept. Its prototype im-
plementations can be traced to almost two decades ago, almost as old as the con-
cept of the world wide web (WWW) itself, as it was first introduced in a paper
presented at the first WWW Conference organized by Robert Cailliau in 1994.
The virtual reality markup language (VRML, pronounced vermal, renamed to
virtual reality modeling language in 1995) was presented by Dave Raggett in a
paper submitted to the first WWW conference and discussed at the VRML birds
of a feather (BOF) established by Tim Berners-Lee, where Mark Pesce [1] pre-
sented the Labyrinth demo he developed with Tony Parisi and Peter Kennard [2].
This demonstration is one of the first, if not the first, of 3D graphics for the web.
The first version of VRML was published in November 1994 by Gavin Bell,
Tony Parisi, and Mark Pesce. It very closely resembles the API and file format of
the Open Inventor software, originally developed by Paul Strauss and Rikk Carey
at Silicon Graphics, Inc. (SGI) [3]. The current and functionally complete version
is VRML97 (ISO/IEC 14772-1:1997). SGI dedicated engineering and public re-
lations resources to promote the CosmoPlayer and ran a web site at vrml.sgi.com
on which was hosted a string of regular short performances of a character called
Floops who was a VRML character in a VRML world. VRML has since been
superseded by X3D (ISO/IEC 19775-1) [4], an XML encoding of VRML.
Despite its ISO standardization status, VRML/X3D has not had the same
success as HTML. HTML is definitely the standard for publishing content on the
web, but VRML/X3D has failed to garner the same level of adoption for 3D con-
tent publishing. HTML has evolved from static content to dynamic content (a.k.a.
Web 2.0) and has fueled the economy with billions of dollars in businesses that
200 13.3DinaWebBrowser
are still growing despite the internet bubble bursting circa 2000. Currently, there
are over two dozen web browsers available for virtually all platforms, including
desktop and laptop computers, mobile phones, tablets, and embedded systems.
The browser war started in 1995, and Microsoft (with Internet Explorer) won the
first round against Netscape to dominate the market by early 2000. The browser
wars are not over as Google (Chrome), Mozilla (Firefox), Opera (Opera) and
Apple (Safari) are now eroding Microsoft’s dominance.
During the same period of time, 3D has grown significantly as a mass-market
medium and has generated large revenues for the entertainment industry through
games and movies. 3D display systems have materialized in movie theaters and
generate additional revenues. So the question remains: Why has VRML/X3D not
had the same pervasive path as HTML? The web is filled with tons of opinions as
to why this did not work out. (Note: X3D is still being proposed to the W3C
HTML Working Group for integration with HTML 5.) Mark Pesce himself of-
fered his opinion in an interview published in 2004, ten years after introducing
VRML to the WWW conference [2]:
John Carmack pronounced VRML dead on arrival. His words carried
more weight with the people who really mattered—the core 3D develop-
ers—so what should have been the core constituency for VRML, games
developers, never materialized. There was never a push to make VRML
games-ready or even games-capable because there were no market-
driven demands for it. Instead, we saw an endless array of “science ex-
periments.”
This comment is of particular interest in the context of this book since its
target audience is game developers. According to Mark Pesce, game developers
should have been all over VRML and creating content for it. Indeed, content is
what makes a medium successful, and games represent a significant amount of
3D interactive content, although not all games require 3D graphics.
Game developers are important because they are recognized for pushing the
limits of the technology in order to provide the best possible user experience.
Game technology needs to empower artists and designers with tools to express
their creativity and enable nonlinear interactive storytelling that can address a
good-sized audience and build a business case for 3D on the web. Game devel-
opers do not care if a technology is recognized by ISO as a standard. They are
more interested in the availability of tools they can take immediate advantage of,
and they require full control and adaptability of the technology they use, for the
13.1ABriefHistory 201
creation of a game is an iterative process where requirements are discovered as
the game development progresses.
The main issue game developers seem to have with VMRL/X3D is its core
foundation. The Open Inventor scene graph structure (see Figure 13.1) is used to
both store the 3D data as well as define its behavior and interaction with the user,
dictating a specific run-time design that would constrict game engines.
The objectives of Open Inventor, which have been followed closely in the
design of VRML/X3D, are well described in the Siggraph 1992 paper that intro-
duced it:
■ Object representation. Graphical data should be stored as editable objects
and not just as collections of the drawing primitives used to represent them.
That is, applications should be able to specify what it is and not have to wor-
ry about how to draw it.
■ Interactivity. An event model for direct interactive programming must be
integrated with the representation of graphical objects.
■ Architecture. Applications should not have to adapt to object representation
or interaction policies imposed by the toolkit. Instead, the toolkit mecha-
nisms should be used to implement the desired policies. Such flexibility
should also be reflected in the ability to extend the toolkit when necessary.
The problem is that these design goals have not been proven to be universal
or able to solve the needs for all representations of and interaction with 3D con-
tent. In fact, another scene graph technology was developed at SGI at the same
time as Open Inventor in 1991: Iris Performer [5]. Its principal design goals were
to allow application developers to more easily obtain maximum performance
from 3D graphics workstations featuring multiple CPUs and to support an imme-
diate-mode rendering library. In other words, both Open Inventor and Iris Per-
former used a scene graph technology, but one was designed for performance and
the other for object-oriented user interactivity:
■ Inventor defined a file format, which was then repurposed as VRML/X3D.
Performer did not have a documented native file format; instead, it offered a
loader facility so third-party’s modeling tools could provide an importer.
MultiGen’s OpenFlight was a popular tool and format for this.
■ Performer did not offer any default run-time library, but there was sample
code and the often-used and often-modified “perfly” sample application,
which contributed to Performer’s reputation for being difficult to use.
202
Figure 1
1992 AC
M
3.1. An Open
M
.)
Inventor sim
p
p
le scene gra
p
p
h and resulta
n
13.3Din
a
n
t rendering.
(
a
WebBrows
e
(
Image ©
e
r
13.1ABriefHistory 203
■ Inventor provided user interaction with the 3D data as well as an interface to
it. Performer did not have much in terms of built-in tools for user interaction,
but instead focused on generating images at fixed frame rates. Performer was
often used in a simulation environment where the interface to the user was an
external system, such as an airplane cockpit.
SGI tried several times to combine both the performance of Performer and
usability of Open Inventor. First, SGI introduced the Cosmo 3D library, which
offered an Open Inventor-style scene graph built on an Iris Performer-style low-
level graphics API. After the first beta release, SGI joined with Intel and IBM to
push OpenGL++ on the OpenGL architecture review board (ARB) [6] as a stand-
ard scene graph layer on top of OpenGL that could be used to port Performer or
Inventor (or Optimizer, yet another scene graph for the computer-assisted design
(CAD) market). The ARB was also interested in seeing OpenGL++ become a
standard for the web. This project died when SGI turned their attention to an al-
most identical project with Microsoft named Fahrenheit. The idea was that SGI
would focus on the high-level API (scene graph) while Microsoft worked on the
low-level Fahrenheit (FLL) API that would eventually replace both OpenGL and
Direct3D. Fahrenheit was killed when it became clear Microsoft was playing SGI
and was instead focused on releasing DirectX 7 in 1999 [7].
Sun Microsystems was also interested in creating a standard scene graph API
that could be universal and bridge desktop applications with web application:
Java3D [8], based on the cross-platform Java development language and run-time
library. The first version was released in December 1998, but the effort was dis-
continued in 2004. It was restarted as a community source project but then “put
on hold” in 2008 [9]. Project Wonderland, a Java virtual world project based on
Java3D, was ported to the Java Monkey Engine (jME) API, a Java game engine
used by NCSoft that produced better visuals and performance and reduced design
constraints.
Today, game engines are closer in design to Iris Performer than to Open In-
ventor. For instance, game engines provide offline tools that can preprocess the
data into a format that is closer to the internal data structures needed on the target
platform, thus eliminating complex and time-consuming data processing in the
game application itself in order to save precious resources, such as CPU time,
memory, and user patience. Also, game engines often create interactivity and
user interfaces with native programming through scripting languages such as
Lua. This provides maximum flexibility for tuning the user experience without
having to spend too much time in designing the right object model and file
format.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.