[X3D-Public] chaining TimeSensors, TimeSensor cycleTime, and end-of-cycle event?

Tony Parisi tparisi at vivaty.com
Tue Oct 13 15:54:29 PDT 2009


Good god;

We don't need to make TimeSensor more complicated. It's already a bitch to
implement all the cases correctly-- we added more features for X3D than were
in VRML97 (elapsedTime, pauseTime etc) and that was painful enough-- and
this node HAS to be bedrock because all animation content depends on it. I
don't want to see it bloated even more.

If the TimeSensor is looping, cycleTime gives you what you want. The
beginning of the cycle is the end of the previous one. If you want to make
that TimeSensor a one-shot, ROUTE its cycleTime to its stopTime and it won't
fire again (even though loop is true). And you can use that cycleTime to
trigger then next animation in the chain.

Vizx3D I mean Flux Studio I mean Vivaty Studio generates X3D content like
this all the time. Pretty easy, and requires NO new fields or browser
changes.

Tony



On 10/13/09 3:25 PM, "Len Bullard" <cbullard at hiwaay.net> wrote:

> Since this is reasonably easy with a script, I assume you want to get rid of
> scripting and create a canned behavior.  Ok.
> 
> len
> 
> -----Original Message-----
> From: x3d-public-bounces at web3d.org [mailto:x3d-public-bounces at web3d.org] On
> Behalf Of Don Brutzman
> Sent: Tuesday, October 13, 2009 1:58 PM
> To: X3D Graphics public mailing list
> Subject: [X3D-Public] chaining TimeSensors, TimeSensor cycleTime,and
> end-of-cycle event?
> 
> A common animation task is to start a second TimeSensor clock after
> a first TimeSensor clock finishes.
> 
> A hopefully easy way to do this would be to chain TimeSensors together,
> in other words, have the completion of one interval ROUTEd to trigger
> the start of the second clock.  This is particularly important for
> single-shot clock animations.
> 
> the TimeSensor cycleTime field indicates the beginning of a new loop.
> This is not the same as end of loop, which is what is needed for this
> functionality.
> 
> So don't authors need an end-of-cycle event for TimeSensor in X3D?
> 
> Should we add a cycleComplete (or somesuch) field to TimeSensor?
> 
> p.s. we have come up with a prototype to deal with this missing
> functionality.
> It's called TimeDelaySensor and works well.  But I'd think that adding
> prototypes is a bit involved for such a common task, particularly if you
> want to do it using lightweight/mobile Interactive profile.
> 
> https://savage.nps.edu/Savage/Tools/Animation/
> Time Delay Sensor Example
> Time Delay Sensor Prototype
> 
> What do other scene authors think?  Thanks for considering this question.
> 
> all the best, Don




More information about the X3D-Public mailing list