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

[Philipp Slusallek]

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.