[x3d-public] Need help with 3 or more chained animations using event utilities, no scripts.

Thu Aug 17 05:12:02 PDT 2023

The shared X3D seems to start a stand animation, at certain times from
a sequencer, or from clicking.

Then it makes sure other animations are stopped when the stand
animation is started.

I added a few comments below.

Not sure when the other animations are started.

Perhaps the concept is that a chain of animations is playing
automatically. Then, if something is clicked, everything is stopped
and a selected animation is playing ? Presumably, then after the
selected animation is completed, the full chain starts again.

Andreas

> Date: Wed, 16 Aug 2023 16:39:59 -0500
> From: John Carlson <yottzumm at gmail.com>

>
> Here's what I'm trying to do.  I'm trying first of all, startf of a chain
> of animations .  Perhaps I do need to double up interpolator values or
> cartesian product? I've also tried pause and resume without success. I
> think what I need to do next is only have 1 user event to start off the
> whole chain, or start automatically.
>
> DEF LilyScalarInterpolator ScalarInterpolator {
>         key [ 0 0.8999999999999999 1.1 2.2 2.23 2.25 2.27 4.3 4.33 4.35
> 4.37 5.5 6.3 7.3 8.5 9 10 ]
>         keyValue [ 0 0.8999999999999999 1.1 2.2 2.23 2.25 2.27 4.3 4.33
> 4.35 4.37 5.5 6.3 7.3 8.5 9 10 ]
> }
> ROUTE z100sTimer.fraction_changed TO LilyScalarInterpolator.set_fraction
> DEF Lily_Stand01BooleanSequencer BooleanSequencer {
>         key [ 0 0.8999999999999999 1.1 2.2 2.23 2.25 2.27 4.3 4.33 4.35
> 4.37 5.5 6.3 7.3 8.5 9 10 ]
>         keyValue [ TRUE TRUE TRUE TRUE TRUE FALSE FALSE FALSE FALSE FALSE
> FALSE FALSE FALSE FALSE TRUE TRUE TRUE ]
>         # [ Lily_Stand01 Lily_Stand01 Lily_Stand01 Lily_Run01 Lily_Turn01
> Lily_Walk01 Lily_Walk01 Lily_Skip01 Lily_Stand01 Lily_Stand01 Lily_Stand01
> Lily_Pitch01 Lily_Roll01 Lily_Kick01 Lily_Stop01 ]
> }
> ROUTE LilyScalarInterpolator.value_changed TO
> Lily_Stand01BooleanSequencer.set_fraction
> DEF Lily_Stand01BooleanFilter BooleanFilter {
> }
> DEF Lily_Stand01OffTimeTrigger TimeTrigger {
> }
> DEF Lily_Stand01OnTimeTrigger TimeTrigger {
> }
>
> ROUTE Lily_Stand01BooleanSequencer.value_changed TO
> Lily_Stand01BooleanFilter.set_boolean
> ROUTE Lily_Stand01BooleanFilter.inputFalse TO
> Lily_Stand01OffTimeTrigger.set_boolean
> ROUTE Lily_Stand01BooleanFilter.inputTrue TO
> Lily_Stand01OnTimeTrigger.set_boolean
> ROUTE Lily_Stand01BooleanFilter.inputTrue TO Lily_Stand01Timer.enabled
> ROUTE Lily_Stand01OffTimeTrigger.triggerTime TO Lily_Stand01Timer.stopTime
> ROUTE Lily_Stand01OnTimeTrigger.triggerTime TO Lily_Stand01Timer.startTime
> ROUTE Lily_Stand01_Touch.touchTime TO Lily_Stand01Timer.startTime

This seems to start a stand animation, either from the sequencer or
from a touch/click.

> ROUTE Lily_Stand01BooleanFilter.inputNegate TO
> Lily_Run01BooleanFilter.set_boolean
> ROUTE Lily_Stand01_Touch.touchTime TO Lily_Run01Timer.stopTime

Turns off run animation if stand is on. Apparently run can still be
active when stand is activated.

> ROUTE Lily_Stand01BooleanFilter.inputNegate TO
> Lily_Turn01BooleanFilter.set_boolean
> ROUTE Lily_Stand01_Touch.touchTime TO Lily_Turn01Timer.stopTime

Same for turn.

> ROUTE Lily_Stand01BooleanFilter.inputNegate TO
> Lily_Walk01BooleanFilter.set_boolean
> ROUTE Lily_Stand01_Touch.touchTime TO Lily_Walk01Timer.stopTime

Same for walk

> ROUTE Lily_Stand01BooleanFilter.inputNegate TO
> Lily_Skip01BooleanFilter.set_boolean
> ROUTE Lily_Stand01_Touch.touchTime TO Lily_Skip01Timer.stopTime

Same for skip

> ROUTE Lily_Stand01BooleanFilter.inputNegate TO
> Lily_Pitch01BooleanFilter.set_boolean
> ROUTE Lily_Stand01_Touch.touchTime TO Lily_Pitch01Timer.stopTime

Same for skip

> ROUTE Lily_Stand01BooleanFilter.inputNegate TO
> Lily_Roll01BooleanFilter.set_boolean
> ROUTE Lily_Stand01_Touch.touchTime TO Lily_Roll01Timer.stopTime

Same for roll

> ROUTE Lily_Stand01BooleanFilter.inputNegate TO
> Lily_Kick01BooleanFilter.set_boolean
> ROUTE Lily_Stand01_Touch.touchTime TO Lily_Kick01Timer.stopTime

Same for kick

> ROUTE Lily_Stand01BooleanFilter.inputNegate TO
> Lily_Stop01BooleanFilter.set_boolean
> ROUTE Lily_Stand01_Touch.touchTime TO Lily_Stop01Timer.stopTime

Same for stop

> ROUTE Everything_Touch.touchTime TO Lily_Stand01Timer.stopTime
> ROUTE Lily_Stand01_Touch.touchTime TO EverythingTimer.stopTime

everything stops stand
stand stops everything

Unclear what everything timer is driving

>
> On Wed, Aug 16, 2023 at 3:52?PM John Carlson <yottzumm at gmail.com> wrote:
>
> > Also, not just 2 animations, like run/jump/run/jump, but 3 or more
> > animations chained together, and looping in a cycle.
> >
> > On Wed, Aug 16, 2023 at 3:42?PM John Carlson <yottzumm at gmail.com> wrote:
> >
> >> Questions:  Can you change animations without user input or scripts?
> >>
> >> Thanks, great examples.
> >>
> >> JOhn
> >>
> >> On Wed, Aug 16, 2023 at 2:15?PM Joe D Williams <joedwil at earthlink.net>
> >> wrote:
> >>
> >>> What a great lesson, Thanks Andreas. Is it too early to ask if result is
> >>> pretty much the same if new set of keys and/or a set of keyValues are sent
> >>> in live?
> >>> Say I want to change the motion from constant rotation to a path where
> >>> it spins faster for part of the rotation and slower for the rest?
> >>> That is fun and nlce demo of proto behavior.
> >>> Joe
> >>>
> >>> -----Original Message-----
> >>> From: Andreas Plesch <andreasplesch at gmail.com>
> >>> Sent: Aug 16, 2023 11:12 AM
> >>> To: X3D Graphics public mailing list <x3d-public at web3d.org>
> >>> Subject: Re: [x3d-public] change to cycleTime perhaps no longer ignored
> >>> , example ?
> >>>
> >>> I found that it should be ok to adjust the startTime after
> >>> cycleInterval was changed. The only time when startTime_changed is
> >>> emitted is directly after a set_startTime was received. So the
> >>> adjusted startTime would never be emitted and cannot disturb any
> >>> processing. Presumably a script could access the startTime field at
> >>> any time but it is not unreasonable to expect that it may have changed
> >>> along with a cycleInterval change given the spec. algorithm for
> >>> fraction.
> >>>
> >>> Clicking on the column in the example now also tests if pauseTime and
> >>> resumeTime still works since resumeTime also needs to maintain
> >>> fraction for resuming:
> >>>
> >>>
> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/6ceca45348203b6faf8d8563d8fee7aa490e56b9/dynamicCycleInterval.x3d
> >>>
> >>>
> >>> https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/6ceca45348203b6faf8d8563d8fee7aa490e56b9/dynamicCycleInterval.x3d
> >>>
> >>> This uses event utilities in their typical verbose fashion.
> >>>
> >>> Seems to work fine.
> >>>
> >>> A subtlety is that in the example only the animation clock is paused
> >>> while the interval clock continues to run in the background. This
> >>> means that after resuming the cycleInterval may change at any moment
> >>> (unless one keeps track manually of the 7s period change period).
> >>>
> >>> I think I will also adapt Holger's example to xdom scripting for
> >>> testing, and that should suffice for providing the feature in a x3dom
> >>> dev. version.
> >>>
> >>> Any feedback or thoughts always welcome,
> >>>
> >>> Andreas
> >>>
> >>> On Wed, Aug 16, 2023 at 9:09?AM Andreas Plesch wrote:
> >>> >
> >>> >
> >>> https://gist.github.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e#file-dynamiccycleinterval-x3d
> >>> >
> >>> > has the rotating column example in a format which can work both in
> >>> x3dom and in x_ite:
> >>> >
> >>> >
> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/c04865919178d0b26f49d49982bc31a3da56c2e9/dynamicCycleInterval.x3d
> >>> >
> >>> >
> >>> https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/c04865919178d0b26f49d49982bc31a3da56c2e9/dynamicCycleInterval.x3d
> >>> >
> >>> > It has simple type converter scripts with directOutput for both. x3dom
> >>> ignores the x3d script and x_ite ignores the dom script and the
> >>> onoutputchange attribute. In addition, the x_ite playground strips out all
> >>> the non-parseable nodes in the editor, so the file appears more tidy.
> >>> Everything else is the same.
> >>> >
> >>> > The type converter scripts do not actually do anything since the
> >>> Javascript SAI type for both SFFloat and SFTime is the same (numeric).
> >>> >
> >>> > The example works for both. view3dscene probably would have to have a
> >>> version with castlescript. Thinking about adding pause and resume when
> >>> clicking on the column.
> >>> >
> >>> > I will see if I can adjust cycleTime instead of startTime to maintain
> >>> the fraction after a cycleInterval change.
> >>> >
> >>> > On Tue, Aug 15, 2023 at 11:23?PM Andreas Plesch wrote:
> >>> > >
> >>> > > Sorry, for some reason I keep typing cycleTIme when I mean
> >>> cycleInterval.
> >>> > >
> >>> > > Good idea to adjust cycleTime and use cycleTime to calculate fraction
> >>> > > although it deviates slightly from the spec. algorithm (but gives the
> >>> > > same result).
> >>> > >
> >>> > > Since cycleTime is updated anyways during the next cycle, I think it
> >>> > > is ok to update it during the same cycle when cycleInterval was
> >>> > > changed since it would not be emitted anyways until the start of the
> >>> > > next cycle.
> >>> > >
> >>> > > I ran into another problem, the lack of suitable SFTime event sources
> >>> > > to route to cycleTime.
> >>> > >
> >>> > > In order to come up with the simplest possible test scene for
> >>> changing
> >>> > > cycleInterval, I was hoping to find a way to feed cycleInterval a
> >>> > > suitable SFTime value without using a script. I was hoping to use
> >>> > > TimeTrigger but TimeTrigger only emits the absolute current time
> >>> > > (seconds after 1970). Also all other sources of SFTime events I could
> >>> > > find emit absolute time values except for elapsedTIme. But it would
> >>> be
> >>> > > necessary to wait a full cycle (say 7s) every time such an SFTime
> >>> > > event is needed so this is not useful.
> >>> > > Finally, there is cycleInterval itself which is [in, out] but is only
> >>> > > emitted when it is changed and never otherwise. So this is also not
> >>> > > useful.
> >>> > >
> >>> > > This means it is only possible to change cycleInterval in a useful
> >>> way
> >>> > > with a Script node.
> >>> > >
> >>> > > Most other input fields of any node, probably all fields, can be
> >>> > > usefully modified without a Script node, for good reason.
> >>> > >
> >>> > > Should X3D also have a convenient source for duration type SFTime
> >>> values ?
> >>> > >
> >>> > > Low impact proposals for sources of relative (small in size) time
> >>> > > SFTime events could be:
> >>> > >
> >>> > > - add a field to TimeTrigger SFTime [in,out] triggerValue, same as in
> >>> > > IntegerTrigger, which can hold a custom value.
> >>> > > - emit a cycleInterval event when a TimeSensor becomes active along
> >>> > > with isActive. This way a TimeSensor can become something like a
> >>> > > TimeTrigger
> >>> > >
> >>> > > Higher impact would be:
> >>> > >
> >>> > > - a new TimeSequencer node
> >>> > > - a new TimeInterpolator node (too strange probably but could be used
> >>> > > for strange time compression or dilation effects)
> >>> > > - a new type converter node which can convert SFFloat to SFTime,
> >>> > > should be easy to implement but could have unforeseeable impact.
> >>> > >
> >>> > > For the time being I think this means that I will add a type
> >>> converter
> >>> > > script to my earlier test example, both for x3dom type scripts and
> >>> x3d
> >>> > > type scripts.
> >>> > >
> >>> > > Cheers, Andreas
> >>> > >
> >>> > >
> >>> > >
> >>> > > On Tue, Aug 15, 2023 at 6:42?PM Holger Seelig wrote:
> >>> > > >
> >>> > > > I recalculate the last cycleTime new (yes really outpuOnly
> >>> cycleTime):
> >>> > > >
> >>> > > > cycleTime = currentTime - fraction * cycleInterval
> >>> > > >
> >>> > > > From this time point you can calculate fraction as well:
> >>> > > >
> >>> > > > fraction = (currentTime - cycleTime) % 1.0
> >>> > > >
> >>> > > > Best regards,
> >>> > > > Holger
> >>> > > >
> >>> > > > --
> >>> > > > Holger Seelig
> >>> > > > Leipzig, Germany
> >>> > > >
> >>> > > > holger.seelig at yahoo.de
> >>> > > > https://create3000.github.io/x_ite/
> >>> > > >
> >>> > > > Am 15.08.2023 um 23:37 schrieb Andreas Plesch :
> >>> > > >
> >>> > > > I forgot the cycleTime is actually of type SFTime, not SFFloat. So
> >>> > > > ScalarInterpolator would not work, although x3dom does not enforce
> >>> the
> >>> > > > type.
> >>> > > >
> >>> > > > Back to the drawing board, using TimeTrigger now, or perhaps
> >>> > > > elapsedTime from a TimeSensor to feed into cycleInterval.
> >>> > > >
> >>> > > > Thanks, Holger, for the test scene. Great to see. Will try to come
> >>> up
> >>> > > > with a simple scene without a Script node. How do you maintain the
> >>> > > > fraction after changing cycleInterval ?
> >>> > > >
> >>> > > > Cheers,
> >>> > > > -Andreas
> >>> > > >
> >>> > > > On Tue, Aug 15, 2023 at 3:41?PM Andreas Plesch wrote:
> >>> > > >
> >>> > > >
> >>> > > > Developing a test scene uncovered that the requirement to continue
> >>> > > > smoothly on the same fraction after a cycleInterval change appears
> >>> to
> >>> > > > require a change to the startTime field value. An unintended
> >>> > > > consequence, perhaps ?
> >>> > > >
> >>> > > > Details:
> >>> > > >
> >>> > > > Here is a simple test scene for dynamic changes to cycleTime based
> >>> on
> >>> > > > a vrml2 source book scene for OrientationInterpolator:
> >>> > > >
> >>> > > >
> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/22a7b7f13bd597b55f136cee96a3b30747e14931/dynamicCycleInterval.x3d
> >>> > > >
> >>> > > > For X3D3.3 the scene is expected to show a rotating column at
> >>> constant
> >>> > > > speed. For X3D4.0 the scene is expected to show a rotating column
> >>> > > > which switches speed every 5 seconds without stuttering or resets.
> >>> > > >
> >>> > > > Above includes a first, rough x3dom implementation (in the Scene,
> >>> > > > javascript allows redefining almost anything) which at least shows
> >>> the
> >>> > > > changes in animation speed but is not successful at maintaining the
> >>> > > > correct fraction to smoothly continue after a change.
> >>> > > >
> >>> > > > Let's see. The fraction is elapsedTime/cycleInterval. This means
> >>> that
> >>> > > > either elapsedTime will need to change with a change to
> >>> cycleInterval
> >>> > > > or that startTime will need to change. Since elapsedTime is derived
> >>> > > > from the current time and startTime this only leaves startTime.
> >>> > > >
> >>> > > > new_fraction = old_fraction
> >>> > > > new_fraction = elapsedTime/new_cycleInterval
> >>> > > > elapsedTime - new_fraction * new_cycleInterval
> >>> > > > time - startTime = new_fraction * new_cycleInterval
> >>> > > > startTime = time - new_fraction * new_cycleInterval
> >>> > > >
> >>> > > > I think it is safe to change startTime but it will also change
> >>> > > > elapsedTime for the remainder of the cycle. Not sure what to do
> >>> about
> >>> > > > that. Also there may be scenes which somehow rely on startTime not
> >>> > > > being changed. But the algorithm for calculating fraction in the
> >>> spec
> >>> > > > really requires startTime to change when cycleInterval changes if
> >>> the
> >>> > > > goal is to maintain the fraction. Is this a matter for the spec. to
> >>> > > > address to remain internally consistent ?
> >>> > > >
> >>> > > >
> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/181894e010f35d242f9f24cf39478e941bccf234/dynamicCycleInterval.x3d
> >>> > > >
> >>> > > > does adjust the startTime in that way and it does work to continue
> >>> > > > smoothly with the same fraction after the speed change. Not sure if
> >>> > > > there are implications for pausing and resuming. Probably worth
> >>> adding
> >>> > > > to the test scene, as well as enabling and disabling.
> >>> > > >
> >>> > > > I guess the alternative is to keep an internal effective startTime
> >>> for
> >>> > > > fraction calculation which may be a bit messy.
> >>> > > >
> >>> > > > I also tried briefly what happens when cycleTime changes every
> >>> frame,
> >>> > > > eg. at the same pace as Timesensor fractions are generated which
> >>> also
> >>> > > > seemed to work after the startTime adjustment.
> >>> > > >
> >>> > > > -Andreas
> >>> > > >
> >>> > > >
> >>> > > > On Tue, Aug 15, 2023 at 12:18?PM Andreas Plesch wrote:
> >>> > > >
> >>> > > >
> >>> > > > It appears that a question on x3d-public back in 2016 was the
> >>> trigger
> >>> > > > for the change:
> >>> > > >
> >>> > > >
> >>> https://web3d.org/pipermail/x3d-public_web3d.org/2016-November/thread.html#start
> >>> > > >
> >>> > > > It involves the x3d-svg-html "rosetta stone" page but that is not
> >>> > > > really suitable as a focused test scene.
> >>> > > >
> >>> > > > Since this is a new feature there are probably no existing
> >>> examples. I
> >>> > > > may try to generate a pure X3D one showing a bouncing sphere:
> >>> > > >
> >>> > > > A sketch:
> >>> > > >
> >>> > > > "SENSOR" TouchSensor
> >>> > > > "POSITION" Transform
> >>> > > > "BALL" Shape
> >>> > > > ..
> >>> > > > "CLOCK" TimeSensor
> >>> > > > "MOVER" CoordinateInterpolator
> >>> > > > ROUTE CLOCK.fraction_changed to MOVER.set_fraction
> >>> > > > ROUTE MOVER.value_changed to POSITION.position
> >>> > > > #Begin of cycleInterval switching without a script
> >>> > > > #Use ScalarInterpolator to emit SFFloat (there is no
> >>> ScalarSequencer)
> >>> > > > "INTERVAL5" ScalarInterpolator keyValue="5.0"
> >>> > > > "INTERVAL1" ScalarInterpolator keyValue="1.0"
> >>> > > > ROUTE INTERVAL5.value_changed to CLOCK.set_cycleInterval
> >>> > > > ROUTE INTERVAL1.value_changed to CLOCK.set_cycleInterval
> >>> > > > "Use Timers to trigger
> >>> > > > "TIMER5" TimeSensor loop=true enabled=false
> >>> > > > "TIMER1" TimeSensor loop=true enabled=false
> >>> > > > ROUTE TIMER5.fraction_changed to INTERVAL5.set_fraction
> >>> > > > ROUTE TIMER1.fraction_changed to INTERVAL1.set_fraction
> >>> > > > #Use BooleanToggle and BooleanFilter to control activity
> >>> > > > "NEGATER" BooleanFilter
> >>> > > > "TOGGLER" BooleanToggle
> >>> > > > ROUTE SENSOR.isActive to TOGGLER.set_boolean
> >>> > > > ROUTE TOGGLER.toggle_changed to NEGATER.set_boolean
> >>> > > > ROUTE TOGGLER.toggle_changed TIMER5.set_enabled #on/off TIMER5
> >>> > > > ROUTE NEGATER.inputeNegate TIMER1.set_enabled #off/on TIMER1
> >>> > > >
> >>> > > > Is there an easier way to send a SFFloat to cycleInterval without a
> >>> > > > script node ?
> >>> > > >
> >>> > > > Thinking about it may be better to avoid all the event utilities
> >>> in an
> >>> > > > example and just switch continuously between speeds:
> >>> > > > ...
> >>> > > > #Begin of cycleInterval switching without a script
> >>> > > > "INTERVAL1OR5" ScalarInterpolator key='0 0.5 0.5 1' keyValue='1 1
> >>> 5 5'
> >>> > > > ROUTE INTERVAL1OR5.value_changed to CLOCK.set_cycleInterval
> >>> > > > "SPEEDCLOCK" TimeSensor cycleInterval=5 # =3 for more challenging
> >>> test
> >>> > > > ROUTE SPEEDCLOCK.fraction_changed to INTERVAL1OR5.set_fraction
> >>> > > >
> >>> > > > This brings up if it will be necessary in the spec. to define
> >>> > > > behaviour for the case when cycleInterval receives a new value
> >>> which
> >>> > > > is the same as the existing value ? Probably not since the proposed
> >>> > > > language only covers actual changes implying that nothing should
> >>> > > > happen if there is no actual change.
> >>> > > >
> >>> > > > -Andreas
> >>> > > >
> >>> > > > On Tue, Aug 15, 2023 at 10:46?AM Brutzman, Donald (Don) (CIV)
> >>> > > > wrote:
> >>> > > >
> >>> > > >
> >>> > > > Thanks for pointing out the error with CD1 urls in X3D Tooltips,
> >>> which eluded prior search/replace.
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > Now fixed. Correct current url prefix follows, sourceforge commit
> >>> and web3d.org deploy will happen later today.
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > >
> >>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > The older behavior can be considered defunct and rectified by
> >>> specification. Devising an example that explicitly shows such correct
> >>> behavior is a good idea. All candidates welcome from any author.
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > Thanks for pursuing this important interoperability
> >>> consideration… we want duck models to consistently walk, talk, and
> >>> look like a duck.
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > Not sure what is going on with the following url, will investigate
> >>> further. Probably an early (and now unintended) redirect.
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > https://www.web3d.org/documents/specifications/19775-1/V4.0
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > all the best, Don
> >>> > > >
> >>> > > > --
> >>> > > >
> >>> > > > Don Brutzman Naval Postgraduate School, Code USW/Br
> >>> brutzman at nps.edu
> >>> > > >
> >>> > > > Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
> >>> +1.831.656.2149
> >>> > > >
> >>> > > > X3D graphics, virtual worlds, navy robotics
> >>> https://faculty.nps.edu/brutzman
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > -----Original Message-----
> >>> > > > From: x3d-public On Behalf Of Andreas Plesch
> >>> > > > Sent: Monday, August 14, 2023 6:56 PM
> >>> > > > To: X3D Graphics public mailing list
> >>> > > > Subject: [x3d-public] change to cycleTime perhaps no longer
> >>> ignored , example ?
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > >
> >>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/time.html#TimeSensor
> >>> > > >
> >>> > > > (as linked from tooltips page)
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > has the change that resetting the value of cycleTime of an active
> >>> TimeSensor in v.4-CD1 does what is probably expected rather than being
> >>> completely ignored which was the old behaviour.
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > Is there an example scene somewhere which demonstrates that
> >>> change, for testing purposes ?
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > A bouncing sphere which changes its frequency over time, perhaps ?
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > This proposal may have been taken out since
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > >
> >>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/time.html#TimeSensor
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > does not have the change ? In that case, apologies for the
> >>> confusion.
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > -Andreas
> >>> > > >
> >>> > > > --
> >>> > > >
> >>> > > > Andreas Plesch
> >>> > > >
> >>> > > > Waltham, MA 02453
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > _______________________________________________
> >>> > > >
> >>> > > > x3d-public mailing list
> >>> > > >
> >>> > > > x3d-public at web3d.org
> >>> > > >
> >>> > > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > --
> >>> > > > Andreas Plesch
> >>> > > > Waltham, MA 02453
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > --
> >>> > > > Andreas Plesch
> >>> > > > Waltham, MA 02453
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > --
> >>> > > > Andreas Plesch
> >>> > > > Waltham, MA 02453
> >>> > > >
> >>> > > > _______________________________________________
> >>> > > > x3d-public mailing list
> >>> > > > x3d-public at web3d.org
> >>> > > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> > > --
> >>> > > Andreas Plesch
> >>> > > Waltham, MA 02453
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Andreas Plesch
> >>> > Waltham, MA 02453
> >>>
> >>>
> >>>
> >>> --
> >>> Andreas Plesch
> >>> Waltham, MA 02453
> >>>
> >>> _______________________________________________
> >>> x3d-public mailing list
> >>> x3d-public at web3d.org
> >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> x3d-public mailing list
> >>> x3d-public at web3d.org
> >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >>>
> >>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230816/efe20e70/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 173, Issue 69
> *******************************************

-- 
Andreas Plesch
Waltham, MA 02453