[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