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

[Philipp Slusallek]

Hi Joe,

I know what the problem and the event cascade system is and appreciate
its solution to the problem. It just turns out that it may be difficult
to implement in the browser without too much changes to its core. And
maybe there are other solutions as well (some sort of nested locks on
the DOM come to mind, or copy on write semantics of changes that can
consolidated just before rendering (that is what we are working on for
optimal multi-threading support in the renderers and it may apply here
as well).

But maybe the X3D event system is the right solution here and we should
work on getting some of its power into the HTML/DOM core, where it could
be used for related purposes by other groups as well. This would be
great and is certainly not unthinkable, if we argue the right way.

For this we need to do is clearly define the problem, list all the
requirements, go through possible other solutions, and make a decision
on what is the best one for the problem at hand and in the Web context.

Ideally, someone who is more familiar with the process back then (Don?)
can dig out the documents used then as a good starting point. That would
be extremely helpful. Also someone more familiar with ongoing discussion
in other Web working groups may want to point to other solutions being
discussed there.


I believe, after all, we may have found a good way to start working
together here and benefit from the accumulated know-how of all of us!


	Philipp


Am 02.01.2011 23:01, schrieb 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
>