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

[Joe D Williams]

>  As I said before it does not include the event processing that you 
> seem to be looking for, though. Maybe we can discuss the need  (or 
> non-need) for this separately.

If you will look at processing X3D events, the important item that 
emerged time after time is getting whatever events are related into 
the same frame. Let's look at a relatively simple event such as a 
touch that will result in some numer of changes to the scene, 
communication with the host DOM, possilbly talk to an embedded context 
of some kind, and some more changes to the scene contents. Please 
excuse the use of the word scene, just habit, but I mean the entire 
contents being rendered.
Without the X3D event cascade system some of the related events may 
show up in the next frame then the rest show up in subsequent frames. 
This is generally not good and it gets worse for more complex 
simulations where it becomes visually obvious that some parts are 
behind, maybe even causing errors in the user's recognition of what is 
happening.
So, the cascade system, using timestamps in X3D, makes sure that 
leakage doesn't happen by giving the author a chance to define what 
events are processed in a single cascade with no leakage between 
frames. Obviously this is an advanced feature but it gives a guarantee 
of what you see is seen as intended (behavior fidelity).
For cases where the event cascade is not needed, then X3D scripts can 
use/update other nodes outside a cascade with dorectout.
I think stating the rules clearly may be simple, like a statement 
about when the values are set (as the script executes or when the 
script returns, and what happens when a script calls another script 
that makes changes and what happens after at the point where the scene 
contents are actually updated. The innovative way of using CSS in this 
effory is great and since it carrys real data, its events need to be 
defined in the mix.
I think the VRML and X3D folks spent some time working this out 
because it gives X3D the best shot at developing realistic realtime 
simulations sometimes also called GUI stuff, along with addressing 
serialization of results at any point.
As we have seen, sooner or later the user wants to see it as it is 
actually happening and as the author declared it should happen.
Say for instance you are brave enough to wish to animate a fairly 
realitic avatar with scripts moving lighting, appearances, and 
vertices around and you want to catch or kick the ball. If you don't 
have a way to synchronize sets of events (which characterize most 
interesting transactions) passed to the data being rendered, things 
may get out of sync. When the fine details of event processing vary 
with the platform, then the author may not know what is actually going 
to happen and the user may not trust what is there.
Even in html layouts wtih glyphs and layout boxes, the DOM has become 
so interactive that work is proceeding to more carefully define a 
document event system. Why? Because there finally gets to be a level 
of where the concept that some platform dependant allowances no longer 
work for the wide range of folks using our WWW. For some level of 
confidence, we need to spec some details so we can know that it should 
work everywhere.
As an example, html processors may not all work the same when there 
are lots of scripts from different places being loaded at different 
times. I think some work has proceeded to a point where an html 
author/publisher/producer/user might be able to predict details of 
what 'should' happen when the site uses lots of library parts at 
loading and different times as is common and implementers will 
converge on solutions. (Imagine you had the greatest static html 
browser ever and somebody said hey, at least you gotta do DOM0 to play 
here!) Anyway, this level of complexity will sooner of later need to 
be addressed and will certaintly be needed in a canvas3D.
I will note here that these type of operations in X3D are carefully in 
the spec and have been since VRML2, with small refinements. In this 
case, processing at this level of complexity was not initially a core 
consideration for html at the document level as it was originally for 
VRML at the scene level, and plus VRML/X3D had Time to play with.
>From a political standpoint, please do not think it was in any way a 
'political' decision to make the X3D event system a longstanding ISO 
standard. A multiude of experts from all over the world have agreed 
upon its details aiming at high reliablility and repeatablity for 
'live' high fi realtime simulations regardless of application and 
platform.
If using a 3D renderer to produce video then not so important, just 
wait until you are sure everything is ready then record. For real 
time, then authors may need some simple help to make sure that stuffs 
that affect the next frame are ready for pixelation.

Also, If I am not fast enough in getting some reasonable (in my mind) 
examples, then please have a look at some things here

http://www.hypermultimedia.com/acontents.htm

maybe in X3D H-Anim Examples

http://www.hypermultimedia.com/x3d/hanim/JoeSkin4EX0.x3dv

at least there is a simple animatable indexed mesh (skin) in there.
or this one:
http://www.hypermultimedia.com/ajax3d/AJAX3Dlogo2.x3d
or this old one:
http://www.hypermultimedia.com/x3d/x3dxmlsyntax/x3dScenes/z3Dkalidoscope.wrl

Maybe not the best stuff ever but no tricky stuff anywhere and I would 
be happy to work on one of these in transcoding to a new way. For 
looking deeper into X3D you will need to install an X3D browser and 
have access to the simplist possible text editor. At this time I 
recommend BSContact and Notepad because BS is the only one that does 
h-anim texturing totally correct for animated skeleton as shown. 
Otherwise, use instant (which does all but the skin texture anim 
right) or octaga ( shich doesn't do the deformable skin yet). None of 
these will damage your system and will uninstall when not needed.
Really, there is so much to learn about this that I don't think anyone 
will get bored looking for something to be amazed about. The 
complexity of X3D nD+1 applications is wide and deep, including 
H-Anim, medical, geographical, and more. I think when you have an X3D 
browser installed, then you won't have to ask for examples because 
there are lots out there, for instance nps has a fairly complete set 
and all text sources are always available. .

Thanks Again and Best Regards,
Joe
http://www.hypermultimedia.com/Logo/Web3dLogo-X3d-animated-logo2.x3d