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

[Joe D Williams]

> Let me continue politely answering technical questions and comments 
> on
> this list as long people raise them..
>

well, i shouln't have thrown proto in there, but the thing is, 
whatever, we need a highly intreractive DOM for the HTML crew, at 
least until the 3D can really be sufficently embedded that we don't 
have to call it a plugin anymore.
That is a basic idea, right. Since interactive 3D processing can take 
all resources there are, and since there is a natural proven access 
model for the 3D visualization, then we know we need another 'engine' 
down there to provide highest performance processing for the 3D 
object, mostly because it is made up of some hierarchy of other 3D 
objects.

anyway, with WebGL, it doesn't get complicated until there is 
interaction with whatever data and event tree/graph.
like if there is a webgl scipt that modifies the data structures. If 
you have ten things changing then you start to need the majik 'plugin' 
that does the data intensive stuff in some knowable order.
That, my friend is the 'engine' of the 3D visualization device of 
interest here.
What 'engine' should be picked?
Does it depend upon the encoding of the input data?
Yes but to no great extent since most all is really all the same data, 
there is usually a simple front end to transcode to whatever you 
wish - if there is a common vocabulary - most all the numbers are the 
same. So whether the vertices are descibed in X3D, Collada, or maybe 
even a more modern and improved syntax, no matter, all it has to do is 
produce a DOM with nodes (elements) accessible using DOM techniques.
So then what I might call the render (data) graph (DOM Tree/X3D DAG) 
is fairly simple and known with several open variations to choose 
from,
and so it is the behaviour graph - or in X3D the event graph - where 
it starts to get really interesting. Sure,the processing you do to get 
the rendering is all very fine and becoming very advanced with many 
new hardware accelerated techniques and like special accelerators for 
fantastically neat (possibly enforceably platform dependant) stuff 
like raytracing

Maybe gog angle or something like that is getting some hints that may 
pass down into the typical html browser. until then there is the need 
for a special piece of software that is optimized for processing the 
3D data structure and enlivening the 3D event structure.

Thus, in this case, if all is open for discussion, the best place to 
start the discussion is describing details of both the DOM structure 
and (if different) the rendering data structure organization(s) and 
then showing the sequence of processing used to prepare the data 
structures for producing the next frame. Please know that is is 
natural to expect some future version will incorporate 3D or nD 
physics for html so we need to consider how to incorprate that 
possiblity into this event graph processing.


To sumarize, then I will keep looking at any alternative encodings 
presented and give some opinion since it is so easy to get way off in 
the human-readable encoding part, but really not much care unless 
really silly and not informed, but that part is minor
Reltive to the need for clear hifi defintions for the actual 
processing and updating of all those numbers.

So then, we are down to choosing an engine to run this so called 
htmlized thus webified version. Assuming this engine is aimed at 
fairly real time interactions with some complex enough to be 
interesting GUI and scenic features, like not just to produce a 
photorealitic rendering of some spinning tennis shoe but a complelling 
and somwhat immersive multimodal interaction, then the 'first step in 
defining the 'engine' is figure out how it must process events. That 
is, what does it do when some external requests a change, and what 
happens when some internal requests some change?
Anyway, that is why I thought I might get a laugh when I said the 
first thing an X3D engine does for each new frame is to check then 
move the viewpoint,  then work to figure out the result. (Heck, I 
haven't looked to see if there is even the concept of a viewpoint or 
animated camera in this new stuff.)

> It is certainly not our intension
> to use the X3D mailing list for the discussions of the future W3C 
> XG. We
> just asked for our input and comments.
>

oh, sorry if any of the above is off topic:) just rambling on this 
newyear's evening.

> I agree that prototypes are a valuable feature that do not exist in 
> this
> form in HTML.

well that was wrong of me to use that where I did. I hope you see the 
connection and complication with DEF which is another thing html does 
not do but html tried that with a Declare, but it never caught on.

The important thing is that right now, in html, X3D is playing in the 
sandbox as a distinct context. Maybe here we can be a more ouside the 
sandbox and a more accessible distinct context.


> However, on the HTML side there is something called XBL

OK, I will check that.

summary:
* data syntax not that important,
* data structure (transform hierarchy) is important.
* show event system frame to frame processing steps


Thanks and Best Regards,
Joe