[X3D-Public] X3dom + PROTO
johannes.behr at igd.fraunhofer.de
Mon Nov 9 15:33:23 PST 2009
> First of all, congratulations for the great work you and your team
> is doing with x3dom. In my opinion, this could be the key for the
> X3D's future, specially because a plug-in will not be necesary for
> I have a question about one think you said in a previus e-mail:
> " X3D reduced to the max: No PROTO or Scripting on the X3D-scene-
> side. All partitioning and scripting is done on the HTML side."
> What does it mean? Does it mean it will not be possible to use X3D
> "files" using PROTO in X3dom? Will exist and alternative way for
> doing the same (or similar) including passing parameters values to
> "proto instances"?
We propose a new experimental "HTML" profile extending the
As in Interchange (Core Level 1, Scripting Level 0) Protos and
scripting are "Optional"
We discussed this issue in the group and choice to keep Scripting and
Protos out for the following reasons:
1) Protos and (multi-language) Scripting are feature which make good,
conforming and performing implementation really hard.
2) There is already a Script-Engine for free on the browser side
3) With this lower set on feature different backends and native-impl.
should be easier compatible
4) Protos are an usual mix of sub-typing and aggregation which is very
unusual for HTML-content people.
5) On some closed mobile platforms is it not allowed to introduce new
We still don't have a good substitute for PROTOS yet but already have
We sill support DEF/USE (and id/USE), Inlines and Routes as X3D
(We do not know any HTML concepts which could be utilized instead)
USE references and Inlines are essential for larger and more complex
data and Routes are needed for per-frame updates in the retained model.
We think we should support those and therefore support Interpolator
and Follower. It's not crucial for the webgl/js implementation since
for native/plugin backends.
The "HTML"-profile is the "minimal" supported profile in X3DOM.
Different Backbends (e.g. WebGL, O3D, SAI-Plugin, browser-native ...
will support various profiles ).
We can even see that the content profile requests or requires a
specific level or kind of implementation.
However, the content author should _never_ choice a specific backend
but only request a specific profile.
But remember always: We do not try to solve all X3D problems with this
proposal and working-group.
We try hard to ease the integration of X3D and HTML and close the gap.
This will not be the optimal platform for all 3D or even X3D
application. There will be always good reasons
(e.g. Augmented Reality) for fat-clients and dedicated X3D-Systems
(e.g. InstantReality, FreeWRL, ...).
We try to build a good ground for Web-Applications which need some
form of easy access to 3D for
there 3D-UI, Visual-Analytics- or shop-application.
> Probably becouse of my lack of knowledge about this topic, but I
> don't imagine how the partitioning could be done on the HTML side
> doing the same things as PROTOs do.
> Thanks and best regards,
> Joseba Beristain / CIDEMCO-Tecnalia
>>> I really like the HTML5 X3D integration work that is
>>> currently being done. I believe the functionality is going
>>> to be a major step forward for X3D, even if initially only
>>> to bridge the gap for when no plugin is installed. I've seen
>>> it work at SIGGRAPH, and the longtime foresight in creating
>>> XML based X3D finally becomes much more apparent. Kudos to
>>> all involved.
>>> Is there any proposal or consensus on how we should
>>> eventually reference to it in a more succinct and marketable
>>> way? Something simple that would stick (around the likes of
>>> Flash) and help spread the word, or maybe just HTML5-X3D ???
>> The current WebGL-based implementation (X3DOM.org) is really only
>> an experimental solution. It helps to sell our main points to the
>> HTML community
>> - Live X3D scene as part of your DOM which allows you to manipulate
>> the 3D content by only adding/ removing or changing DOM elements.
>> - X3D without any plugin or plugin-interface
>> - X3D reduced to the max: No PROTO or Scripting on the X3D-scene-
>> side. All partitioning and scripting is done on the HTML side.
>> This intermediate solution has two major drawbacks
>> - Feature: The current WebGL/Javascrpt layer does not allow
>> advanced feature e.g. (spatial) sound or movie textures.
>> - Performance: WebGL is quite fast but we still have to do all the
>> But the X3DOM architecture is not bound to an WebGL renderer backend.
>> The next step will be support for existing X3D-SAI browser as
>> rendering and animation backbends.
>> The whole design (not the current impl.) was chosen with different
>> backbends in mind.
>> Therefore we believe some single line per (X)HTML document will
>> stay for a while:
>> " />
>> Future version of X3DOM will use WebGL, X3D-SAI, O3D, or browser
>> native implementation
>> transparent for the app-developer.
>> The actually backend will be chosen automatically or based on the
>> content X3D-Profile.
>> Therefore the current HTML-X3D solution should not be called "The
>> webgl solution".
>> "X3D in DOM" or short X3DOM makes more sense.
>> best regards,
>>> IMO, the fact that no plugin is required can make this go
>>> like wildfire. It might just be the spark to light up X3D
>>> like never before.
>>>> -----Original Message-----
>>>> From: x3d-public-bounces at web3d.org [mailto:x3d-public-
>>>> bounces at web3d.org] On Behalf Of Don Brutzman
>>>> Sent: Friday, November 06, 2009 4:58 PM
>>>> To: X3D Graphics public mailing list
>>>> Subject: Re: [X3D-Public] X3D+HTML5 talk presented to HTML5
>>>> working grouptoday
>>>> Don Brutzman wrote:
>>>>> - cochair Sam Ruby was able to run the demos on his
>>>> system without problem.
>>>> his blog has interesting comments
>>>>> Next Tuesday 8-9 am is our regular weekly X3D+HTML5
>>>>> We will review these steps and hopefully craft a website
>>>> as usual Anita is way ahead of us - thanks!
>>>> please also add references to the wiki and the slideset at
>>>> all the best, Don
>>>> Don Brutzman Naval Postgraduate School, Code USW/Br
>>>> brutzman at nps.edu
>>>> Watkins 270 MOVES Institute, Monterey CA 93943-5000 USA
>>>> work +1.831.656.2149
>>>> X3D, virtual worlds, underwater robots, XMSF
>>>> X3D-Public mailing list
>>>> X3D-Public at web3d.org
>>> X3D-Public mailing list
>>> X3D-Public at web3d.org
>> Dr. Johannes Behr
>> Leiter Projektbereich VR
>> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
>> Fraunhoferstr. 5 | 64283 Darmstadt | Germany
>> Tel +49 6151 155-510 | Fax +49 6151 155-196
>> johannes.behr at igd.fraunhofer.de | www.igd.fraunhofer.de
>> X3D-Public mailing list
>> X3D-Public at web3d.org
> Joseba Beristain - Inf.Systems R&D - CIDEMCO - Tecnalia
> Tel.: (+34) 943 81 68 00
> Fax.: (+34) 943 81 60 74
> Área Anardi, nº 5
> 20730 Azpeitia
> (Gipuzkoa) / Spain
Dr. Johannes Behr
Leiter Projektbereich VR
Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5 | 64283 Darmstadt | Germany
Tel +49 6151 155-510 | Fax +49 6151 155-196
johannes.behr at igd.fraunhofer.de | www.igd.fraunhofer.de
More information about the X3D-Public