[x3d-public] change to cycleTime perhaps no longer ignored , example ?
Holger Seelig
holger.seelig at yahoo.de
Tue Aug 15 15:41:49 PDT 2023
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230816/ca075bc4/attachment-0001.html>
More information about the x3d-public
mailing list