Re: X3D comments in Bug 8238.

Hi Maciej;

Thanks for the response.

>>
>> "Tentatively, I would not be in favor of an X3D-specific mechanism  
>> in the parser. X3D is not supported directly by UAs, and it's not  
>> clear if it ever will be (since there are competing 3D model  
>> serializations with similar or greater levels of traction)."
>> May I ask what other 3D model serializations you have in mind?
>
> COLLADA.
> O3D (has a JavaScript API that creates a retained-mode scene graph,  
> and a JSON-based serialization).
>
> These seem to have more active support and interest in at least some  
> quarters than X3D.

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 
  )
"


>
>> "... But it doesn't make me, as a UA implementor, feel more  
>> motivated to add built-in parsing complexity for a feature to be  
>> implemented by third-part code."
>> There are a number of open-source code bases for X3D out there;  
>> Johannes created the X3Dom javascript implementation that we  
>> demonstrated last week; I have FreeWRL, a OSX/Linux/Windows native  
>> implementation, and there are others.
>> I am not yet fully aware of the W3C process, nor of individual  
>> member's requirements, but could such open-source codebases be of  
>> interest to UA implementors? Hopefully it is apparent that we wish  
>> to work with the W3C to promote X3D as one possible candidate for  
>> 3D rendering and interaction within HTML5.
>
> If X3D looks like the right technology for the problem space, then  
> we will definitely want to implement it natively. What I'd be  
> hesitant to do is to expend effort on parsing hooks without doing  
> the rendering natively as well. I don't think we're ready to bet on  
> X3D at this time. But we (Apple) do think that a logical next step  
> after WebGL is some sort of retained-mode mechanism for 3D graphics.
>


We agree with the native implementation statement.

There seems to be a requirement for an abstraction for retained-mode  
3D graphics so that 3D graphics can not only be cross-platform but  
also allow for technological improvements that will come over time  
with improvements in both hardware and lower layer graphics drivers.

Dr. Behr's x3dom.org is an excellent first step to allow design and  
testing of tight X3D-HTML5 integration, but is hampered performance- 
wise by it's implementation (Javascript) running on top of a pseudo- 
lower layer API (WebGL). There are open-source, natively written,  
multi-platform, multi-threaded X3D codebases that are not hampered by  
the Javascript/WebGL performance limitations.

We believe that HTML5 should use a retained-mode model (or, "scene- 
graph") which can be directly mapped to a live DOM-Tree for easy  
access and programmability, and X3D looks like  an excellent candidate.

Thanks again for the dialogue;

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

Team Leader: Networked Virtual and Augmented Reality
alex.stewart@crc.ca

Network Systems and Technologies -
         Systemes et technologies des reseaux
Communications Research Centre Canada  |
          Centre de recherches sur les communications Canada

3701 Carling Ave.  |  3701, avenue Carling
PO Box 11490, Station H  |  CP 11490, succursale H
          Ottawa ON K2H 8S2   |  Ottawa (Ontario) K2H 8S2

http://www.crc.ca

Received on Thursday, 19 November 2009 14:35:16 UTC