[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [x3d-public] RE: [www-vrml] Walking Kamala

hi thyme,

When scripting directly for OpenGL and DirectX, script functions do not begin on a
new frame until all of the functions for the next frame to be rendered have exited. 

i don't understand your point. if you look at the VRML97/X3D event
model there is the same idea of an event cascade.

An event is generated to cause update of the scene and that
event may cause other events to be generated, This sequence of
events is a cascade. When all events in the cascade are known,
then the scene is updated. Overall, this should be able to be
controlled by the author using default and author-set operation
of beginUpdate and endUpdate.

<http://www.web3d.org/x3d/specifications/ISO-IEC-19775-X3DAbstractSpecification/Part02/servRef.html#UpdateControl>

Consider default operation of these browser services. It is different
for 'internal' and 'external' scripting. By default, events from the outside
are processed individually as they occur. Internal events are by default
processed in terms of the cascade.

There are a couple of places in the standard that describe this.

<http://www.web3d.org/x3d/specifications/ISO-IEC-19777-1-X3DLanguageBindings-ECMAScript/Part1/concepts.html#InternalInteractions>

The model for an individual script is that events are not sent until
the script is complete. I think it is an intent of the X3D standard
to improve definition of that model to include the ideas that
a directOut is treated the same as a ROUTE, that all scripts involved
in a cascade complete before the next frame, and that an evemt
from outside the scene may be the first event in some external cascade
and thus does not require immediate action.

This makes for a much more script friendly environment. If the VRML/X3D event ... 

Reading the VRML97 and X3D standards will describe the same
concept. This is necessary to achieve a realistic simulation.
So, events have a time stamp. All events with the same time stamp
are in the same cascade. When the cascade is complete, then
the scene is updated and the next frame is produced.

But please note that this is hard to do. Many times realism is
sacrificed for relative simplicity and utility. Close examination of
great engines may show some shortcuts or deliberate change to
the model. For instance, is it OK to go ahead and set the new state
after each script, even though there are multiple scripts in the
cascade? I would say no, however it may be a lot simpler in the
browser to just do that. If the cascade is not complete and the
browser wants to maintain frame rate, is it OK for the browser
to set incomplete results and catch up in the next frame?

I think one misunderstanding happened because clever scene
programmers wanted a short cut inside that model. For these
guys, even though the main browser design provided the idea of
preserving the cascade, use of directOutput bypassed the cascade
by essentially allowed them to set a new state ansync from the
current cascade. Another side benefit is the very compact scripts
that resulted.  The fantastic USE feature, no need for ROUTE, and
the ability for the author to knowingly or unknowingly produce an
event model that is 'asynchronous' because directOut may bypass
the otherwise 'synchronous' cascade.

In my story of it, I got bit by this stuff early when i needed
frame-by-frame control of event sequences and have since
always voted for a consistent event model and consistent
ways for the author to break it.
Maybe unfortunately, the way i learned it best was to not use
that tricky directOut and related stuff unless I really needed it.

If the VRML/X3D event
models were replaced with the way the popular browsers implemented the event
system, more old VRML content 

The way I see it, if you have been using directOut, you have
probably been bypassing the VRML97 and X3D event model.
That is why you are seeing what you called asynchronous behavior.

However, i think you will see that very meticulous reading of the
X3D standard will show that it is at least the _intent_ of the X3D
standard that directOuts get treated the same as ROUTEs in
terms of the cascade which they are a part of.
Even though there may be phrases that might be read as allowing
a different interpretation, which may be related to ecmascript/java
platform differences.

Thank You and Best Regards,
Joe

-------------------------------------------------------------------------
for list subscription/unsubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html