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

[Johannes Behr]

Hi,

> This is one of the biggest issues with X3DOM and any mapping from X3D to
> HTML (from my perspective) X3D inherently has a DAG model that shows up
> in subtle and not so subtle areas. This is foreign to HTML and adding a
> DAG under the hood making it look like a tree from the outside causes
> funny things to happen, if you make changes to one of the "copies" of a
> multiple referenced objects. Note that you run into CSS issues as well
> this way, which may be as difficult as those in SVG.

I agree. The DAG does not match the HTML tree and it's not just the
CSS assignments but makes serialization results really odd. However,
it's a very powerful feature for users to reuse other parts of scene with
a simple reference. References and deep-copies (e.g. with proto-instances)
are two generic solutions to the reuse problem. 

Render/picking performance is  another good reason not to use
a DAG internally. Therefore we map the X3D graph to an OpenSG-Tree
internally in the native implementation. 

> In XML3D we have avoided the need for a graph in the first place. Every
> object has a clear location in the tree, but you may refer to an object
> somewhere else in the tree through a URL fragment ("#id"). Currently, we
> only allow references to geometry (leafs in the tree, not to internal
> nodes with entire subtrees) for simplicity reason. This means you may
> have to replicate these internal nodes but still share the nodes that
> really maintain the most data. However, for good reasons we may want
> eventually to allow references to entire subtrees.

Which makes your system a DAG :)))

>> 
>> All that is fine I just didn't get the empahsis on modelling behaviors
>> of interesting UI objects..
> 
>>> -- What do you mean by automation?
>> 
>> Well, like having builtin sensors and timers and interpolators and
>> generally, behavior details, and a reliable event system and easy
>> authoring because you can just use the browser and a text editor or a
>> full-fledged authoring system, and being able to lift great gobs of
>> existing content into my little html5 show.
> 
> Now the key part of XFlow is that we also have data elements that can
> refer to a script node and implement any transformation on the input
> data they refer to (other data elements) and provide as "output" new
> vertex arrays. We currently do the processing on the CPU and only have
> predefined "scripts" (using a URI notation), but this is designed to
> work with our new shading language system such that you can write you
> own scripts to modify the data. Eventually, we will even be able to
> optimize the scripts over multiple of these scriptable nodes and pus
> some of these nodes also into the geometry shader pipeline of OpenGL and
> such. But this is still work in progress and not in the distributed
> versions yet.

So if you allow free references to data in your system to build
a separate event or data-flow graph (on top of the scene-graph) it't very 
much like the route system of X3D.

So what is the advantage again?

> 
>>> There is a decent API that deals with
>>> the DOM (including AJAX to download them and many other nice Web
>>> technologies).
>> 
>> Great, I have seen some of that and it works and can work everywhere. In
>> fact WebGL is pushing the limits of XHR and JSON. So, of course we have
>> access to allthat, given the encoding makes sense.
>> 
>>> We have extended this to better support access in native
>>> 3D data types (like WebGL). Javascript is also a pretty decent
>>> programming language that gets a lot of attention in terms of
>>> performance speedup and such. All of this we get for free when working
>>> in the same ecosystem.
>> 
>> Right, looking at stuff in pure WebGL here is showing lots of agreement
>> in all the browsers, so this first pass at doc3D only needs to do the
>> basic features. That makes part of the opportunity easier and gives us
>> some basic features to build a live DOM that understands the kind of
>> data expected by the underlying process and is able to make it live.
>> 
>>> 
>>> The DOM just happens to be used by many times more people world wide on
>>> a daily basis that all programmers that have ever dealt with a 3D scene
>>> graph combined. So even if it has flaws, at least it works for a heck
>>> lot of people and is very well tested :-).
>> 
>> Interesting. But I think it sounds like you have not examined the X3D
>> SAI interfaces. Really, it is just like the DOM if you want it to be
>> that way. To the user it can look like a DOM, just that a child can have
>> may parents and that there is also a hierarchy of contexts.
> 
> The API is different enough that Web people have to learn it anew. This
> argument actually cut even better the other way: Why not replace the SAI
> with the Web DOM API that millions of people use on a daily basis if the
> two are so similar anyway?
> 
>>> -- In case you are referring to Routes, I am not sure I agree with you.
>>> From my point of view, routes help solving the simple cases but easily
>>> get into your way if you want to do more complex stuff. But if you
>>> really need them, they can be easily simulated using other techniques.
>>> And maybe there are convincing arguments that we should indeed add them.
>> 
>> That is fine, the SX3D SAi also gives event notifation and attachemts
>> and that, if yo need them. With little imagination, it gets important to
>> be able to get information around the scene. Route just gives a
>> convenient way to send strongly typed data from mode to node, and is
>> easily readble/settable from the outsde.
> 
> I definitely see the things one can do with the synchronized event
> system and data propagation model of X3D. We just do not have this
> available in HTML. So we could try to add it (but we would have to do
> this across all of (2D-)HTML, which will be a real challenge). Or we can
> see if we can live without it or create a different model. We are
> currently doing without it in XML3D to see how far we can push this (but
> we have the data references and transformations of XFlow). But I can
> definitely see that we end up needing something like this eventually.

I totally agree. The HTML-Event system and the X3D sensor concepts
are hard to combine in a single system design without breaking one of
this concepts. 

This is the reasons, why we didn't include the high-level sensors in the
HTML-Profile of X3DOM. But time will tell. 

best regards
johannes 

\