[x3d-public] Validation suggestion on animation events

[Leonard Daly]

Tony,

Multiple TimeSensors are only needed if objects run on significantly 
different (i.e., incompatible) time cycles. E.g., 5 seconds for one loop 
and 4 for another. Yes, you could do a 20 second loop, but tracking all 
of the individual cycles in that loop is a mess. I will describe another 
way below.

If you have one set of coordinated animations that needs to repeat, it 
is probably best to use a single time sensor and ROUTE the output to 
multiple Interpolators. For example if there are two cylinders that need 
to pass through a common point without collision, you could animation 
them as follows (fixed width text to show correctly):


Time -> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Cylinder L/R   |- move left- | -   stop  - |- move right- | -    stop   - |
Cylinder U/D   |-   stop    - | - move up - |- stop    - | - move down - |


With the cycle repeating after each loop. You would need to do something 
like:

<TimeSensor DEF='Timer' cycleInterval='5' loop='true' />
<PositionInterpolator DEF='MoverLR' key='0.00 0.25 0.50 0.75 1.00'
      keyValue='2 0 0, -2 0 0, -2 0 0, 2 0 0, 2 0 0' />
<PositionInterpolator DEF='MoverUD' key='0.00 0.25 0.50 0.75 1.00'
      keyValue='0 -2 0, 0 -2 0, 0 2 0,  0 2 0, 0 -2 0' />
<ROUTE fromNode='Timer' fromField='fraction_changed' toNode='MoverLR' 
toField='set_fraction' />
<ROUTE fromNode='Timer' fromField='fraction_changed' toNode='MoverUD' 
toField='set_fraction' />

The outputs of the PositionInterpolators would need to be ROUTEd to the 
appropriate Transform node.


A single node can be subject to multiple translations; however, within a 
single time-stamp there is no implied order of translations. Since each 
translation is to an absolute position (in the Transform's coordinate 
space), the object could end up at any of the translations specified at 
each time step (including the NULL translation - meaning no movement).

If you DEF/USE a Shape (not a Transform), then that immediate parent 
Transform to each Shape can be separately translated as you would expect.

Chaining TimeSensors is possible, but a little more difficult because 
you need to make sure you capture the correct event (isActive -> FALSE) 
after the sensor had been running (isActive == TRUE and/or cycleTime != 
0). In all of the examples I have seen, you need to use a Script node. 
You cannot send in a context that determines which TimeSensor to next 
activate, so you need to maintain the state of all of the TimeSensors in 
the Script node so a start event is sent to the correct TimeSensor.

Note that in the code above, it is not necessary to loop, but that makes 
debugging much easier.


If you have incompatible intervals (about the only compatible interval 
is 1:2 or 2:1), you can use a Script node to generate the time events 
that would be generated if you had multiple time sensors.

If you have several animations with incompatible intervals (for example: 
3, 7, and 11 second), create a TimeSensor with a cycleInterval equal to 
the product of the interval lengths (231 seconds).

In a Script node, multiply the fraction_changed by the cycleInterval 
(231), then compute the modulus for each of the intervals, and divide by 
that interval length.

You now have three numbers from [0-1] that are the fraction_changed 
values from your three virtual TimeSensors. In one cycle of the 
TimeSensor, there will be 77 cycles of the 3 second interval, 33 cycles 
of 7 seconds, and 21 cycles of 11 seconds.


Leonard Daly



> Whilst making good progress on an animation, I encountered a problem
> which took me much time to understand, because I assumed a data error
> in my relatively large data set. Basically several shapes which I had
> programmed to move remained frozen.
>
> I finally realized that I had made the naive assumption that a single
> shape could not be subject to several simultaneous translations. My
> assumption derived from the sense that I could translate several
> copies of the same shape -- as with Adobe Illustrator, etc. Of course
> a single translation moves the shape so that applying several
> route-distinct  translations to the same originally positioned shape
> is a fundamental error. My suggestion is that this could be a focus of
> a validation procedure.
>
> The issue related to the following (which could be handled under a
> separate thread).
>
> The animation in question is simple in that it has each of the 12
> edges (cylinders)  of a cube moving to their parallel positions. Each
> edge therefore has two parallel (but orthogonal) positions to move to
> -- readily defined by route-translations. This of course works only if
> the separate translations  are governed by different timesensors. and
> do not move simultaneously but sequentially.
>
> I am therefore using 3 timesensors for each set of 4 lines (forming
> the side of the cube. One timesensor can govern the movement of that
> square in both directions.-- sequentially. This results in 24
> movements of the 12 lines.
>
> I have spent a lot of time with the web resources on timesensors in
> relation to routes and have been unable discover anything directly
> relevant to the "simultaneous" movements of multiple shapes. I did
> consider duplicating the edge cylinders in their original positions in
> order to move the copies separately by a single sensor applied to the
> distinct nodes.
>
> My current approach is to link the timesensors, with each passing
> triggering information from one to the other when its cycle ends -- in
> a closed loop.I am totally inexperienced in this. For the x, y and z
> orientations, the relevant lines I have -- which work individually but
> not together  -- are:
>
> <TimeSensor DEF='CLOCKx' cycleInterval='5'  loop='false' />
> <ROUTE fromNode='CLOCKx' fromField='stop-time' toNode='CLOCKy'
> toField='start_time'/>
> <TimeSensor DEF='CLOCKy' cycleInterval='5'  loop='false' />
> <ROUTE fromNode='CLOCKy' fromField='stop-time' toNode='CLOCKz'
> toField='startTime'/>
> <TimeSensor DEF='CLOCKz' cycleInterval='5'  loop='false' '/>
> <ROUTE fromNode='CLOCKz' fromField='stop-time' toNode='CLOCKx'
> toField='startTime'/>
>
> The lines are indicative of what I would like to happen but also
> demonstrate my ignorance of how the chaining of the events could be
> ensured. I have not found any relevant guidance.
>
> Any comments?
>
> Tony.


-- 
*Leonard Daly*
X3D Co-Chair
Cloud Consultant
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20150830/1c35dea7/attachment.html>