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

[Len Bullard]

>For example if you don't use DEF or PROTO 
>then you get a natural opening for CSS because the styled item is 
>truely everywhere in the tree instead of just once on the graph.

What would replace the PROTO?

XML does not enable behavioral extensibility.  PROTOs do.

len


-----Original Message-----
From: x3d-public-bounces at web3d.org [mailto:x3d-public-bounces at web3d.org] On
Behalf Of Joe D Williams
Sent: Thursday, December 30, 2010 11:12 PM
To: Philipp Slusallek
Cc: x3d-public at web3d.org
Subject: Re: [X3D-Public] Fwd: Re: [X3D] X3D HTML5 meeting
discussions:Declarative 3D interest group at W3C



> Hi,
>
> Can you elaborate what you mean by this statement? To make this a
> constructive discussion: What is it that you are missing in XML3D or 
> X3DOM?
>

I don't know. I will look deeper. I saw the shows from html5 on the 
web. Great stuff. At this point I think I appreciate the X3DOM stuff a 
little more because it looks to retain more of the inevitable 
complexity needed and so far better recognizes the need to embed a 
high perfomance rendering system in the html5 browser. The high 
performance is needed for behavior stuff and high level scriptless 
interactions. So, for the DOM or however the event graph and the 
rendering graph or whatever, it doesn't actually need to be a DOM, it 
just needs to act like one from the outside.
Fortunately this is easy, except I recall that X3D uses a 'graph' 
(DAG) instead of a tree due to certain advantages that may not even be 
required for simple stuff. For example if you don't use DEF or PROTO 
then you get a natural opening for CSS because the styled item is 
truely everywhere in the tree instead of just once on the graph.
So I mainly want to keep track of what is happening and contribute 
where possible

> Here are some possible answers, for what you may have meant:
>
> -- I have not said that we will use the DOM to optimize the 
> rendering or
> anything like this. In XML3D we have a fully configurable and 
> optimized
> rendering engine behind the 3D-part of the DOM that can drive a
> rasterization as well as various ray tracing renderers.

This sounds really neat and is all nice features. To me, it should be 
readable and expose teh author to necessary complexity as gently as 
possible. I would like to get some reference points by adapting some 
old and current stuff. As I said, so far the X3DOM picked up some 
examples real easy.
I deeply appreciate all progress on these items of interest.

>
> -- One thing that might have confused you: In the past many people 
> have
> mixed up a scene graph with a graph that accelerates rendering.

not really, but I think the item of interest with respect to html5 is 
what we can see and do in the DOM. Whatever is under the covers, it 
should be very straighforward to expose every content and presentation 
detail in a DOM. That, i think is the simple part. The hard part is 
connectiong al the peces and hierarchies. For hifi repeatable realism, 
it gets complicated fast.

> However,
> conceptually they are very different but obviously share the same 
> data.

The DOM has a fairly well defined api, just stick to it and fix where 
necessary and everything will be OK.

> The first is a way to organize your scene data from an application 
> point
> of view, while the other organizes the same data for optimal 
> rendering
> performance. The two organizations typically have very little in 
> common.
> Note, that the rendering organization typically differs dramatically
> even between different rendering strategies (e.g. rasterization/ray
> tracing).

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.

> 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.

>
> -- 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.

>
> Philipp

Thanks, Philipp for your work on this and to everyone else that is 
interested.
I hope you can use this list to expllain the details and show some 
examples.
Joe

>
>
> Am 30.12.2010 21:58, schrieb Joe D Williams:
>>> And funny enough the DOM is exactly what is needed: a nice 
>>> declarative
>>> scene graph
>>
>> for a certain level of funny and a certain set of what is needed, 
>> yes.
>> The hard part and where the contribution is made for authors is
>> automating that DOM.
>>
>> Best Regards,
>> Joe
>>
> 


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