[x3d-public] change to cycleTime perhaps no longer ignored , example ?

Tue Aug 15 20:23:19 PDT 2023

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 <holger.seelig at yahoo.de> 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 <andreasplesch at gmail.com>:
>
> 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 <andreasplesch at gmail.com> 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 <andreasplesch at gmail.com> 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)
> <brutzman at nps.edu> 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 <x3d-public-bounces at web3d.org> On Behalf Of Andreas Plesch
> Sent: Monday, August 14, 2023 6:56 PM
> To: X3D Graphics public mailing list <x3d-public at web3d.org>
> 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