Re: X3D comments in Bug 8238.

In response to John Stewart's claims that COLLADA tools add their own
extensions to data, precluding them from being used for delivery - this
statement is untrue.

The model in question below that John Stewart and Johannes Behr reference is
a Spore model exported in COLLADA, and does not contain any Maya specific
extensions. It includes the creature's geometry and 3 texture files, all of
which open perfectly in COLLADA supporting tools such as Photoshop CSe.

Note that :

- COLLADA extensions are designed so that they can be entirely ignored by
applications not recognizing them.

- Apple Preview fails to open this file because it is incomplete and does
not load models that are defined as skins. A bug was opened and we encourage
anybody to report bugs to the app vendor in question. Note that it is really
easy to test if extensions are problematic by removing every <extra> tag
information in the .DAE file. I did this with the Spore model file for
instance. Extensions are definitely not private to a particular tool - in
fact it is the exact opposite. Extensions are documented in the extension
directory (i.e., here is the link to the COLLADA extensions page so that an
application can take advantage of registering extensions if so they choose -
https://collada.org/mediawiki/index.php/Portal:Extension_directory).

In the case John discusses, the COLLADA extension mechanism works just fine..
This extension was originally developed by an implementation of COLLADA
(Feeling Software Max and Maya plug-in specifically has been used by EA for
the Spore exporter). Once again, this information can be simply ignored -
resulting in a model without a bump map.

The big difference between X3D and COLLADA as explained in the white paper
John references is the fact that COLLADA does not attempt to standardize the
user interaction with the model (events, actions) and leaves this to the
application to decide what to do with the model. In other words, using
COLLADA with WebGL for instance, the JavaScript code incorporated in the
html page has to probe the model and decides how and what to expose; with
Web3D the model contains the code to be executed by the X3D runtime. It is a
matter of choice, but IMHO the COLLADA choice provides greater flexibility
and does not impose a specific interaction model. This also allows  an
application's user interface to be designed to better target specific usage
models.

Rita Turkowski
Khronos COLLADA WG Marketing Chair


"Collada is really a data-container if you would like to go from tool
A to B to C and would still like to get your A-specific extensions in
C even so B does not know about it. The disadvantage is, that almost
every Collada-tool writes and adds own extensions to the data. The
Collada format is made for this extensibility and it is not a bug but
feature of the design.

Take, for example, the spore model which Vladimir used in his first
WebGL showcase:

                      ftp://ftp.igd.fhg.de/outgoing/jbehr/Amahani-
dae.zip

It uses some own and Maya specific extensions and can therefore not be
opened in other tools like e.g. the "Snow-Leopard Preview" even though
it is a standard- and schema-compliant file.

Collada therefore is a container to get data from tool A to B without
losing parts. But it's not a delivery or deployment format.



Collada and X3D are in many ways complementary; X3D and Collada do
have a working relationship.

We believe that HTML5 needs a strong deployment format, like X3D, for
HTML5/DOM integration. Our reasons follow.

3D (X)HTML-ized retained graphics requires a royalty-free, open,
standardized XML-encoded format. At first look, both Collada and X3D
are suitable candidates, but below I will indicate why X3D is the
clear winner.

O3D, while a great design from a graphics-programmer point of view,
does not support a declarative XML-Model which could be directly
mapped to live DOM elements. (We view it as synonymous with WebGL; eg
Johannes Behr's group are planning to write an O3D backend, to
compliment the the WebGL backend, for x3dom.org)

Collada is a great format for a specific purpose: It is designed as an
interchange format to transport and manage specific 3D assets. The
Collada specification does not include, unlike X3D, a runtime or event
model, which is needed for per-frame updates on the 3D-side (e.g.
animations).

We believe that 3D in HTML5 will be crippled if it chooses a 3D format
that does not have a runtime environment that supports dynamics in the
declarative model.

Dr. Johannes Behr of Fraunhofer has given the following example that
might put more light on the situation:

"Collada is really a data-container if you would like to go from tool
A to B to C and would still like to get your A-specific extensions in
C even so B does not know about it. The disadvantage is, that almost
every Collada-tool writes and adds own extensions to the data. The
Collada format is made for this extensibility and it is not a bug but
feature of the design.

Take, for example, the spore model which Vladimir used in his first
WebGL showcase:

                      ftp://ftp.igd.fhg.de/outgoing/jbehr/Amahani-
dae.zip

It uses some own and Maya specific extensions and can therefore not be
opened in other tools like e.g. the "Snow-Leopard Preview" even though
it is a standard- and schema-compliant file.

Collada therefore is a container to get data from tool A to B without
losing parts. But it's not a delivery or deployment format.

There are similar cases for e.g. image or text files. Many people use
psd-files to store images with all layers and to get from one tool to
another but one does not distribute the psd file on the net. The same
goes for text-files. Everyone uses .doc or .odf for text but pdf for
the final delivery. Therefore there is always this duality for
different areas.

The same process goes with 3D. Use Collada in your pipeline and an
delivery format (e.g. X3D) in the final runtime.

And this is not just my opinion:  For more background information
about how Collada and X3D relate and why “X3D is ideal for the Web”
please read the Whitepaper by Rémi Arnaud (founder of the COLLADA
initiative) and Tony Parisi, (co-founder of VRML, and X3D architect):
http://www.khronos.org/collada/presentations/Developing_Web_Applications_with_COLLADA_and_X3D.pdf

-----------------------------------------------------------
John A. Stewart
(representing the Web3D Consortium)