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

[Philipp Slusallek]

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?

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.

-- One thing that might have confused you: In the past many people have
mixed up a scene graph with a graph that accelerates rendering. However,
conceptually they are very different but obviously share the same data.
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).

-- What do you mean by automation? There is a decent API that deals with
the DOM (including AJAX to download them and many other nice Web
technologies). 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.

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

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

	Philipp


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
>