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

["seamless3d" <thyme@seamless3d.com>]

Len wrote:

> Actually, an explanation of what the notion of scripting for a single 
> frame
> entails would be interesting reading.   Regardless of routing or calling
> functions through direct out, getting acts to perform sequentially is a
> little murky anyway without chaining open and close events for the 
> objects.
> I'm not sure how many authors script at the granularity of a frame, and if
> they need to, that's screwed up anyway.  It's too low level.

What do you mean by "too low level"?

In order to be able to write scripts for animation there is going to be the 
need
for an understanding of writing for a single point in time for the frame.
Typically for VRML and X3D the single point in time  is supplied by
a TimeSensor's fraction_changed field and or the time stamp.

If for example we wanted some 3d object to be delayed in relation to another
3d object in the cycle for a looping TimeSensor, in understanding we are
writing for a single frame we are able to write a delay:

if(fraction_changed > .25){
   orientationInterpolator.set_fraction = fraction_changed - .25;
}
else {
   orientationInterpolator.set_fraction = fraction_changed + .75;
}

I am not sure what you mean by "granularity of a frame"
How long it takes to run the code for the frame does not come into the 
equation
because the TimeSensor provided us with the point in time
(the value of fraction_changed) and so it could take all day to render this 
frame
and not cause a problem for our above script.
The issue I am talking about is not the sequentialness of the frames being 
at
equal intervals in time (I am not aware of any 3d platform that has this 
design),
it is the sequentialness of the script is what I am talking about.
If for example a beginner wanted to use a single OrientationInterpolator for 
2
different 3d objects and he/she was not well versed on the VRML/X3D specs,
they are likely to try this:

orientationInterpolator.set_fraction = fraction_changed;

transformA.rotation = orientationInterpolator.value_changed;

if(fraction_changed > .25){
   orientationInterpolator.set_fraction = fraction_changed - .25;
}
else {
   orientationInterpolator.set_fraction = fraction_changed + .75;
}

transformB.rotation = orientationInterpolator.value_changed;

This example will work fine for Cortona, Contact and Cosmo and fine for
OpenGL or DirectX and my guess all other 3d platforms except for VRML
and X3D because of their unorthodox design.

This will not be ok for VRML or X3D because we have written to an
OrientationInterpolator and used its resulting value_changed more than
once for a single frame (time stamp).
The extra overhead designed for the VRML event system was obviously
not to make scripting more intuitive or easier or to make processing
more consistent for scripts.
Perhaps it is more "high level" if we use the term high level to mean extra
overhead but this extra overhead forces the scripter to have to understand
more complicated low level concepts (scripting for parallel processing).

regards
thyme



----- Original Message ----- 
From: "Len Bullard" <cbullard@hiwaay.net>
To: "'seamless3d'" <thyme@seamless3d.com>; "'Joe D Williams'" 
<joedwil@earthlink.net>; "'Paul Aslin'" <fabricatorgeneral@yahoo.com>
Cc: "'www-vrml'" <www-vrml@web3d.org>; "'X3D Graphics public mailing list'" 
<x3d-public@web3d.org>
Sent: Thursday, February 01, 2007 9:14 AM
Subject: RE: [x3d-public] RE: [www-vrml] Walking Kamala


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