X3D HTML 5 - 3d-test Panorama of web 3d technologies - Real Time 3D & Interactive media

NEWS TESTS INTERVIEWS DOSSIERS GALLERY 3D 3D SITES

Q&A

John A. Stewart
CRC Canada/ Web3D Consortium
december 2009

“ It took a while for HTML browser writers to natively include SVG and MathML, so we expect it will take some time for all browser writers to include X3D [...].
X3D is a write once, render anywhere, anytime 3D graphics format.”

< Gurob, Freewrl

HTML 5 will add the support of video and 3D. We talk a lot about WebGL, but could you please give us more information about the work of the Web3D HTML 5 working group?

To start this discussion, I'm going to draw a line in the sand of the HTML5 3D sandbox, and describe what I see on both sides of this line, and how both sides have their place on the Web.
On one side, you have programming APIs for Javascript, using some form of 3D canvas, like WebGL or O3D. On the other, you have a retained-mode, DOM-integrated 3D graphics abstraction, like X3D.
The first side, (lets just call it the Javascript side) was created by graphics coders for graphics coders who want to get the utmost out of their hardware, and who revel in 4x4 Matrix manipulation, dream GLSL in their sleep, and love to get their hands into the system. (Many of the X3D people, myself included, love doing this kind of stuff)
The second side, which I'll call the X3D side, is for those who are web developers, or who are using graphics to compliment their work. Maybe they want to build a 3D User Interface, or maybe they work doing research into DNA, or in the mining industry, and they need to use 3D visualization as part of that work.
The people who fall into the X3D side might also want to use features not available in the Javascript layer, such as spatialized sound, or want to use graphics-oriented concepts that are already included in X3D, such as ray intersecting, collision detection or view-frustum culling.
These people might also want their models to be very portable - WebGL is an API that conforms closely to OpenGL ES 2.0, while X3D by design is generic it may be rendered using OpenGL (any version), DirectX or some other future system.
So, people will have a choice. We see choices like this every day. Lets take cars; some like to get under the hood and tinker with the innards, while others just like to get in the car and drive to their destination. We see the Javascript side as the tinkering side, and X3D as the vehicle for those who just want to get from "A" to "B" in comfort with the minimum of fuss.

Is there a chance that HTML5 class browsers would be able to display X3D files, without any plugin?

Absolutely - that is the goal of our liason with the HTML5 Working Group: DOM-integrated cross-platform open-standards 3D graphics in every browser.
It took a while for HTML browser writers to natively include SVG and MathML, so we expect it will take some time for all browser writers to include X3D.
Your readers might want to read more about the X3DOM X3D implementation project (http://www.x3dom.org) which uses Javascript and WebGL to display X3D; this is an interesting and lively project from the people at Fraunhofer.

Does HTML5 include a parser for X3D?

By default, it does. Dr. Behr's X3DOM implementation shows that tight integration of X3D and HTML5 is indeed possible, and easily achieved.
However, we expect that HTML5 browser writers will eventually include X3D natively, either by including an open-source multi-platform library like FreeWRL (http://freewrl.sourceforge.net) or by writing their own.

Frankly, X3D has never been a success as 3d artists can not export in this file format from their DCC software (3ds max, maya, softimage,...). What is the advantage of X3D vs initiatives such as Collada (.dae and .zae)?

There are some conceptual differences between X3D and Collada that we should talk about.
A major difference is that Collada is just a model interchange format, while X3D provides both model interchange and a 3D runtime environment. X3D gives you the ability to create - and interact with - virtual models; it provides the methodology of not only getting triangles on the screen, but also of interacting and managing those triangles - enabling a web page creator to create compelling content.
Collada allows for "bleeding edge" 3D model creation, while X3D gives users a stable, ISO-standardized format that is great for not only general interchange of your 3D model, but also for interaction with this model.
So, once again, we have a duality here, which is good; it gives the user a choice.
Dr Johannes Behr of Fraunhofer, gave me the following example, that I think shows quite well how we view Collada and X3D:
"Collada is really a data-container. So you can move your model from tool "A" to "B" to "C" and would still like to get your "A"-specific extensions in "C" even though "B" does not know about it. You see, almost every Collada-tool writes and adds own specific extensions to the data. The Collada format is made for this extensibility and it is not a bug but a strong feature of the design.
Collada therefore is a container to get data from tool "A" to "C" without losing parts. But it's not a delivery or deployment format.
There are similar cases for e.g. image and 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 a delivery format (like 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 )

There are still very few 3D contents on the web, it seems that websites prefer to use Flash 3D engines even if performances are bad, rather than any other plugin. Do you think that it could change with HTML 5?

Yes, for the following reasons.
1) Flash is not an open standard. The Web is built on open standards.
2) Flash does not currently support use of the GPU.
3) Flash has no multi-vendor support.

HTML 5 will use JavaScript to handle interactions. In terms of performance, do you believe that JavaScript could handle large scenes, gaming interactions (AI, Physics...)?

... and collisions with objects in the scene, and frustum culling, and navigation and user interaction and actions within the scene and all the other things users currently expect, or will want as their knowledge expands....
Can Javascript "handle" large scenes? You can program almost anything in any computing language, whether it is optimal or not is really the question.
First, lets talk about vertex/texture rendering speed.
In Javascript over WebGL, a minimum amount of Javascript can be used to render triangles and textures - it is really the GPU that is doing the rendering. If you throw a little bit of housekeeping or interaction in, frame rates drop dramatically.
To use some real-world numbers: Dr. Johannes Behr of Fraunhofer is finding that small models in his X3D-Javascript-WebGL X3DOM implementation render at least 30 to 50 times more slowly than on a natively written X3D browser on the same platform. Certainly, some more code optimizations could still take place; but to put it into perspective, I think the biggest optimization that I did for the FreeWRL browser was to move away from using Perl for housekeeping to being completely "C" based - the framerate improvements were outstanding. How well Javascript can calculate fast ray intersects, frustum culling, user interaction and so on is yet to be determined, but it is looking like it might be about two orders of magnitude slower than a native implementation. For desktop systems this might not be an issue, but in the mobile field where battery life and cpu cycles are closely tied, it might be more of a concern.
Second, your readers should also remember that X3D has the runtime environment built in; and X3D Browser authors spend a considerable amount of time ensuring that this runtime environment performs well. Having a native X3D implementation means not only fast rendering of your triangles and textures, but a unified, efficient runtime architecture.
Third, We have found that the precision of floating point numbers is not sufficient for accurate placement of data; thus X3D uses double precision numbers for internal calculations, such as interpolators, and managing Geospatial data. Dr. Behr has mentioned that his group have encountered this floating point accuracy problem with the X3DOM Javascript-based X3D implementation.
Finally, an issue that seems to be missed by many is that X3D gives you an abstracted view of your graphics hardware; it is the job of the X3D Browser implementer to ensure that geometry gets rendered as efficiently and quickly as possible, and the X3D browser tracks both hardware and associated library improvements. The optimal use of an artists' time is to not worry about runtime implementations and efficiencies on specific hardware, but to create compelling cross-platform content.

For non-specialist, Web3D consortium means VRML. Do you think that the consortium can still bring new technologies that can be spread widely?

VRML is an old series of standards. There is no denying that in the beginning, VRML graphics files displayed - by todays standards - crude, non-realistic graphics. But one has to remember that when VRML-1 came out, the computer graphics industry was in its infancy, and computers that could render such graphics were expensive and beyond the reach of many interested people. So possibly the negative feelings some have towards VRML have less to do with VRML and more to do with the state of the computing industry at the time.
The current X3D specification retains backwards compatibility with VRML-97. We are consciously keeping this backwards compatibility intact while continually bringing the standard up to today's graphics needs, and pushing the technology; such as real-time ray-tracing with X3D.
The "longevity" and "cross-platform" compatibility of the VRML/X3D standards are important for many users. Can I give you a story? I was recently asked by a NASA employee to integrate VRML-1 into the FreeWRL browser; VRML-1 pre-dates VRML-97. I looked up the specification on-line, and half a day later this user was able to view these files on his desktop Macintosh computer. How many other 15-year-old graphics formats can still be rendered?
I'd suggest that when someone mentions "3D graphics" the first thing that comes to mind are the great products coming out of Hollywood and the gaming companies. We tend to forget fields such as scientific and medical imaging where longevity and cross-platform compatibility are of paramount importance for 3D models.
The Web3D Consortium is continuing to bring open, 3D rendering technologies to the world. X3D: write once, render anywhere, anytime.

About embedded devices such as Smartphones & iPhones ; would HTML 5 be able to display 3D on those "computers" too?

If we are talking about using X3D for 3D, absolutely. X3D is an abstracted graphics format; as long as the underlying OS and hardware supports some form of pixel display, X3D can be rendered on it. Whether your device uses one of the Direct-X graphical libraries, one of the continually evolving series of OpenGL versions, or some as-yet unwritten low-level graphics layer, X3D will be able to render on it, and if that device contains user i/o capabilities, X3D will be able to use that capability, too.
X3D is a write once, render anywhere, anytime 3D graphics format.

A PROPOS DE 3D-TEST INFORMATIONS LEGALES LINKS TRANSLATE WITH GOOGLE