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

[Len Bullard]

"Do you need a "way to route strongly typed data from node to node", or will
the existing mechanisms in HTML be sufficient?"

Which is why I said the proof is in the implementation.

Sharing browser components is a plus if the result is less unnecessary
incompatible behavior and a better content lifecycle.  The argument is as
goes the code so goes the content and because I have been here using your
concepts from the SGI labs I can say with some authority, it ain't true.
The struggle to match the content to the platforms is worse when multiple
authorities control different pieces of the solution.

But if the issue is adoption, composability is the challenge.  While you
explain the origin of protos, what is the replacement and does it help or
hinder composability?

You know the facts, Chris.  Unless real-time 3D objects are highly
interchangeable (even if not interchanged widely), the cost of 3D authoring
itself remains the barrier to adoption at the low end of the skill scale.
This may the point where that goal is abandoned.  Joe Homepage is put to
rest.

The advantage of X3D is still the cost of authoring in terms of tools and
the richness provided.  The downside is to lose the power of the single
language for expressing the real-time 3D and exchange it for multiple
components at varying rates of evolution and control.   No free lunch even
if the right thing to do.

len

-----Original Message-----
From: x3d-public-bounces at web3d.org [mailto:x3d-public-bounces at web3d.org] On
Behalf Of Philipp Slusallek
Sent: Sunday, January 02, 2011 5:19 AM
To: Chris Marrin
Cc: X3D mailing list Graphics public
Subject: Re: [X3D-Public] Fwd: Re: [X3D] X3D HTML5 meeting
discussions:Declarative 3D interest group at W3C

Hi Chris,

I am all with you in separating the concerns and create independent,
orthogonal modules that work well with each other but are reusable in a
variety of contexts. We have tried to follow this as much as possible in
XML3D (and XFlow). There are data elements that map nicely to typed
arrays, there are rendering components, namely the <mesh> tag that
contain/receive/refers to these data elements and interpret them as
renderable primitives.

Shaders, lighting and such as separately described and attached to
geometry via CSS, and so on.

I do believe in declarative interpolators for data intensive processing
(a la XFlow, see other email) as there is much more than just rigid body
animations that we need. Particularly if we are interested in getting to
live-like virtual characters on the Web. We need careful ways to modify
(interpolate, skin, displacement map, light map, whatever) the data
sets. While this could be done in JS (and the nice interface to typed
arrays allows this to be done in XML3D). However, I believe that a
declarative way to specify these operations (similar to a shader network
in many animation tools) is a better and more intuitive way to specify
these operations (and can be implemented way more efficiently and
portably that way). I know that there is some activity to define a
data-parallel version of JS that may be an option but, knowing JS, I am
not holding my breath here.

Note, that the XFlow module would be applicable also outside of XML3D
and we could even design a nice API, where it can take data from typed
arrays (coming from FileIO or whatever). BTW, this is also the way we
plan to handle compressed 3D data representations. There was just no way
we so to fix any representation in this regard.

I am skeptical of declarative sensors and declarative event processing,
though as I have discussed before. DeviceIO and its relatives seem to
provide what we need right now. However, I am not ruling it out
altogether, as there might turn out to be interesting applications or
performance advantages that might be worth considering. I have not yet
seen good proofs of their advantages, though. That's why I keep asking
for them.

	Philipp


We did not go down
Am 02.01.2011 01:52, schrieb Chris Marrin:
>> What would replace the PROTO?
>>
>> XML does not enable behavioral extensibility.  PROTOs do.
> 
> And so I think you need to go back to the drawing board and try to
> understand why protos exist. I know their genesis since we
> whiteboarded them in a lab at SGI in 1995 or so. We were trying to
> solve the problem of reusability. We were working in an environment
> without the support of an underlying object model. So we created one
> ourselves. We didn't have an underlying event system, so we created
> them ourselves. The same is true of sensors, interpolators and the
> entire complex timing model that is in X3D today.
> 
> I think it's important to reset our conceptual model given the
> situation today. When we started WebGL, our informal charter was to
> not do anything that was not directly related to rendering 3D
> content. We originally included typed arrays because we needed them
> for VBO and related data representation. But we later removed them to
> their own spec because they are not specifically about 3D rendering.
> And an interesting synergy occurred. At least 3 other components of
> "HTML5" needed the same thing. So now Safari, Chrome and Firefox have
> compatible typed arrays which are starting to be used not just in
> WebGL, but in XHR, File IO, and in the Audio XG.
> 
> You might say that declarative 3D is not just about rendering, and
> you might be right. But it will serve you much better if you can
> separate rendering from the other needs, real or perceived, in the
> system. If you believe you need declarative interpolators, in what
> way does CSS animation not fit your needs? Maybe adding to CSS
> Animations is a better approach. Do you need a "way to route strongly
> typed data from node to node", or will the existing mechanisms in
> HTML be sufficient? Given Typed Arrays (for strong typing) and the
> existing DOM event and JavaScript mechanisms, can you build a system
> that perhaps has even more flexibility than the current system and
> would be useful to other modules in the browsers?
> 
> Sensors are another area which were added because we had to add
> EVERYTHING. HTML has a rich event model which currently includes
> keyboard and mouse events. And modules are emerging to support touch
> gestures and accelerometer data.
> 
> I understand this is all very different from the thinking of the last
> 15 years. But setting your sights on a simpler and more focused set
> of features could be the best way to get a toehold in the browsers
> and go from there.

_______________________________________________
X3D-Public mailing list
X3D-Public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org