| Q&A |
 Google
O3D,
May 2009 |
| |
 |
“I
think one of the most important features of O3D balance
we've struck between exposing low level functionality
required for advanced graphics techniques and choosing
an architecture that performs well in the browser. ”
<
O3D in action |
|
| |
|
| Q1 |
There
have been a lot of initiatives to integrate 3D contents into
web pages. Do you think that O3D will succeed where VRML, X3D,
Shockwave 3D (etc.) have failed?
|
| A1 |
The
goals of O3D are very different from these approaches. X3D takes
a very high level approach to describing 3D content. O3D takes
a very low level approach of exposing graphics capabilities
to developers via Javascript. Furthermore, X3D is the successor
to VRML, a standard that was conceived more than 10 years ago,
and is thus incompatible with a lot of functionality that a
modern graphics API should provide. Google believes that the
advances in graphics that have occurred since VRML/X3D were
conceived warrant a redesign of a 3D API for the web. |
| |
|
| Q2 |
O3D
can import 3D assets in Collada. Why Collada files are converted
into .json rather than using .zae? What are the main features
of .json files in the terms of memory bandwidth and features
(shaders, bones animations, etc.)? |
| A2 |
O3D
does not "import" any type of asset. We have provided
a sample utility that converts Collada files into JSON, and
a sample Javascript library that reconstructs the model from
JSON using the O3D javascript API. For more information, see
our O3D Blogpost about this topic:http://o3d.blogspot.com/2009/04/why-json-rulez.html |
| |
|
| Q3 |
O3D
comes with a large set of functionalities : what kind of users
are you targeting (games developers, web agency, hobbyist...)? |
| A3 |
Google decided to present O3D to the open source community to
participate in the conversation on how to best address the lack
of an open web standard in the 3D graphics space. Google hopes
to collect valuable feedback about the needs of all types of
developers (game developers, web agencies and hobbyists included!)
to inform the open source community. |
| |
|
| Q4 |
Do
you plan to add an interactive 3D view in GoogleWarehouse using
O3D? |
| A4 |
Like
other Google developer products, the goal of O3D is to move
the web platform forward. We'd love to see an interactive 3D
view in 3D warehouse, but don't have anything to announce at
this time. |
| |
|
| Q5 |
Is
it possible to mix 2D and 3D together? Is it possible to "map"
HTML document or a video on a 3D Object? |
| A5 |
It's
not currently possible to mix the two content types freely.
This is one of the major downsides to being implemented as a
plugin, and therefore a reason that we're excited to see 3D
become a native capability of browsers instead of a plugin. |
| |
|
| Q6 |
Is
O3D easy to learn? Do you plan to develop more tools like a
3D scene editor? |
| A6 |
We
designed O3D so that developers can quickly and easily get up
to speed on the code and begin creating applications. However,
developers who already have some experience working with OpenGL
or Direct3D will feel most comfortable using O3D. We hope to
see easy-to-use tools for creating O3D content, but expect these
to primarily come from companies that specialize in building
these tools. |
| |
|
| Q7 |
Do you think that CAD users can take advantage of O3D to share,
visualize their 3D data? |
| A7 |
Just as the web has helped users collaborate and share 2D content,
we think the ability to share 3D content on the web will be
enormously helpful to users who create 3D content. Imagine,
for example, an architect being able to send a client a 3D model
of a house, and the client being able to take a virtual walkthrough
and provide feedback! |
| |
|
| Q8 |
We
have look at O3D samples and been impressed by performances
(multiple clients, instancing, fractal shader...) and the quality
(z-sorting for transparent faces, 2D post processing...) of
the 3D engine. Could you please details some unique features
that make O3D so powerful? |
| A8 |
I
think one of the most important features of O3D balance we've
struck between exposing low level functionality required for
advanced graphics techniques and choosing an architecture that
performs well in the browser.
For example, true multipass rendering is an important advanced
graphics technique that is impossible in many retain-mode APIs
because they use a high-level scenegraph. We provide multipass
rendering by providing a retain-mode API that allows the client
to specify the rendering order of the render graph. This way,
the developer gets both the control of a very low-level API,
but gets the performance of a retain-mode API because native
code is actually running through the render-graph instead of
Javascript. |
| |
|
