[X3D-Public] Fwd: Re: [X3D] X3D HTML5 meetingdiscussions:Declarative 3D interest group at W3C

Joe D Williams joedwil at earthlink.net
Thu Dec 30 21:56:25 PST 2010


----- Original Message ----- 
From: "Philipp Slusallek" <slusallek at cs.uni-saarland.de>
To: <x3d-public at web3d.org>
Sent: Thursday, December 30, 2010 2:39 PM
Subject: Re: [X3D-Public] Fwd: Re: [X3D] X3D HTML5 
meetingdiscussions:Declarative 3D interest group at W3C


> Hi Joe,
>
> I agree with a lot you are saying. I have been around a lot of the 
> stuff
> from its beginning and we are not as ignorant as it may seem. As I 
> said
> there are many good things in X3D that are worth considering for
> integration.

Please help X3D by reporting something that should be dropped or 
improved.

>
> However, on a rather fundamental level X3D has some very basic 
> features
> that make it incompatible with HTML and Web technology today (tree
> versus DAG, special event system, to name just a few).

This is all superficial. It just has to provide the DOM api. The X3D 
event system is not special, it just works to produce a reliable event 
cascade where that is desired. Well, also it gives some rules, like 
the first bit of work for setting up the next frame is moving the 
viewpoint:)

>
> Now we have a few options:
> (0) We ignore the issues and do not try to get 3D tightly integrated
> into browsers:

Please don't bring this up or even talk about it. The issues are much 
too important to ignore.

Well people will still do 3D using the WebGL API

Well, when you wish to discuss behaviors, there is really no api. They 
have some data structures and some scripts runinng the things, but 
there really is nothing of what we need except the basics. The 
important thing is having nodes that can freely exchange data so as to 
produce and interactive exchange.


> and
> maybe some other declarative approach will likely emerge at some 
> point.

I think more like converge than emerge. Better chance for convergance 
with strong data typing of the types of data that interactive 3D 
needs.

>
> (i) We convince the Web community to change their model to 
> accommodate
> the way X3D does 3D: Good luck with that.

In some ways, I think you are overestimating the SAI complexity or 
underestimating the DOM complexity.
Not looking for trouble, but what part of the model between the web 
community is different. It is all data with some sort of markup and it 
is mostly all the same set of data. I need to look at this more, but 
lots of web things and 3d things are similar, like both can specify 
colors and appearance and complicated visual features in plain 
declarations.

>
> (ii) We somehow try to circumvent at least some of the issues: 
> Certainly
> possible for some issues, but not very likely from all (or even many
> from my perspective). X3DOM has a few suggestions that we should 
> discuss
> in terms of the different features and capabilities and how they fit
> into the HTML/Web technology stack.

Wonderful, since so far X3DOM is clearly showing the best stuff that I 
have see. Of course I say that because X3DOM played playing some good 
old examples.

> This is exactly what the XG group
> aims at. However, I remain unconvinced that this will create a 
> system
> that is even backwards compatible.

Bacwards to what? It is easy to get backwards to VRML1.

I think study of repositories using Collada, for instance would be 
instructive and remembering that it is all XML. There are just a few 
exceptions for HTML..

>
> (iii) We start with the infrastructure the Web provides and fit 3D 
> into
> this (this is what XMl3D does).

That would be the bare minimum for consideration.

> Yes, we will have to do 3D differently,

I am looking forward to seeing something new. However, most of it is 
not new, but just finally now or newly possible.

> but its not clear that this means it will be less useful.

Less useful is not a show stopper for me.
I see. Except what is different? I know that if it is not the same it 
is different, but why should anthing be different? It does after all 
boil down to some numbers aranged in sets that make it convenient to 
turn those numbers into pixels, and to allow the author to bring those 
pixels to life in front of a motivated user.
I will look more to see what is different and what is same. With all 
respect to alternatives, if it is the same, it should not be 
different. That would be counterproductive.

>
> The start of the W3C Incubator Group is the attempt to bring the 
> best
> people and ideas together to make the right decisions going forward. 
> I
> am hoping that we get constructive feedback and suggestions from the
> Web3D community. But as Chris reminded us, we should start with an 
> open
> mind and not just pretend that things will have to be exactly as 
> they
> have been in X3D.

given the proper time an exposure and the availability of an open 
conformant player in every browser I'm sure we will get there.

>
> One of the discussions could be on the merits of the X3D event 
> system,
> how its can possibly be integrated in HTML, and what are 
> alternatives.

* strongly typed
* time stamped
* sensors and scripts
* cascade processing model
* from the outside, same as from the inside

alternative: Do it like the DOM with dpfloats and strings and 
(finally) arrays and libraries for event management..

>
> Philipp

Really, let's show our best stuff.
Joe


>
> Am 30.12.2010 21:12, schrieb Joe D Williams:
>>> Please don't ask me to do brain surgery with a spoon.
>>
>> Maybe some new tools? SInce the end objective must be to represent 
>> the
>> element as a live scriptable DOM tree then lots of stuff like 
>> passing
>> data to and from the embedded context and controlling processing 
>> within
>> the thing may be easier or at least more familiar to many If they 
>> give
>> us a good DOM to play with.
>> But heck we all know how easy it is to do easy stuff with simple
>> animations and interactions. As len said somewhen,"Rendering and
>> behavioral fidelity are equal requirements in these systems". We 
>> now see
>> that it is relatively common to get similar rendering fidelity 
>> between
>> platforms, even approaching 'realistic' high fidelity in appearance 
>> even
>> when an appearance is complex. And, so it will be with fidelity for
>> simple behaviours. Heck maybe all somebody has to learn is some 
>> 3DCSS.
>> When behaviors get complex and require synchronization to achieve
>> fidelity, our mastery of the DOM event system will define 
>> 'realistic' to
>> the user. Then, getting almost to what is needed for real hifi fun
>> discover why the X3D SAI internal/external event system works like 
>> it does.
>>
>> Or, maybe some tech or practice that would shake up our event 
>> system
>> 'pipeline' like shaders changed the rendering pipeline.
>> Joe
>>
>> _______________________________________________
>> X3D-Public mailing list
>> X3D-Public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> _______________________________________________
> X3D-Public mailing list
> X3D-Public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org 




More information about the X3D-Public mailing list