TimeSensors generate events as time passes. TimeSensors remains inactive until their startTime is reached. At the first simulation tick where real time >= startTime, --- 1,7 ---- !
TimeSensors generate events as time passes. TimeSensors remains inactive until their startTime is reached. At the first simulation tick where real time >= startTime, *************** *** 8,18 **** to drive Interpolators). It may be set to FORWARD, causing alpha to rise from 0.0 to 1.0 over each interval, BACK which is equal to 1-FORWARD, or it may be set to SWING, causing alpha to alternate 0.0 to 1.0, 1.0 to 0.0, ! on each successive interval.
!The minTick field specifies how often the TimeSensor will generate output events; output ! events are guaranteed to be generated no less than one minTick interval apart. For example, setting minTick to 1.0 will guarantee that t TimeSensor will generate output events at ! most once per second. By default, minTick is zero and a TimeSensor will generate time events as often as possible ! (typically, as quickly as the world can be redrawn).
pauseTime may be set to interrupt the progress of a TimeSensor. If pauseTime is greater than startTime, time and alpha events will not be generated after the pause time. pauseTime is ignored if it is less than or equal to startTime.
If cycleCount is <= 0, the TimeSensor will continue to tick continuously, without a cycle interval; in this case, cycleInterval and cycleMethod are ignored, and alpha events are not generated. This use of the TimeSensor --- 11,17 ---- to drive Interpolators). It may be set to FORWARD, causing alpha to rise from 0.0 to 1.0 over each interval, BACK which is equal to 1-FORWARD, or it may be set to SWING, causing alpha to alternate 0.0 to 1.0, 1.0 to 0.0, ! on each successive interval, TICK will generate events only once per cycle, with alpha always set to 0.
pauseTime may be set to interrupt the progress of a TimeSensor. If pauseTime is greater than startTime, time and alpha events will not be generated after the pause time. pauseTime is ignored if it is less than or equal to startTime.
If cycleCount is <= 0, the TimeSensor will continue to tick continuously, without a cycle interval; in this case, cycleInterval and cycleMethod are ignored, and alpha events are not generated. This use of the TimeSensor *************** *** 26,35 **** TimeSensor { startTime 0 # SFTime (double-precision seconds) pauseTime 0 # SFTime - minTick 0 # SFTime cycleInterval 1 # SFTime cycleCount 1 # SFLong ! cycleMethod FORWARD # SFEnum FORWARD | BACK | SWING # eventIn SFTime setStartTime # eventIn SFTime setPauseTime # eventIn SFTime setCycleInterval --- 25,36 ---- TimeSensor { startTime 0 # SFTime (double-precision seconds) pauseTime 0 # SFTime cycleInterval 1 # SFTime cycleCount 1 # SFLong ! cycleMethod FORWARD # SFEnum FORWARD | BACK | SWING | TICK ! actionObject Parent # SFNode ! actionMethod "Tick" # SFString ! actionParameters SFNode Self # MFFields # eventIn SFTime setStartTime # eventIn SFTime setPauseTime # eventIn SFTime setCycleInterval *************** *** 43,46 **** for time, except that if we expect to be dealing with absolute times( from Jan 1 1970 0:00 GMT perhaps) then 32-bit floats don't give enough precision. Inventor writes SFTime fields as 64-bit double-precision values, but stores ! time values internally as two 32-bit integers
\ No newline at end of file --- 44,51 ---- for time, except that if we expect to be dealing with absolute times( from Jan 1 1970 0:00 GMT perhaps) then 32-bit floats don't give enough precision. Inventor writes SFTime fields as 64-bit double-precision values, but stores ! time values internally as two 32-bit integers. ! The unit needs to be specified - if its a float, it could ! be seconds, if it is a Long then a second is too course. ! !Open issue: Do we use wall-clock, real-time, or simulation-time, or do we allow this to be selectable by the author, with a sensible default?