[x3d-public] FloatSequencer ? step functions and optimization, avoiding node bloat

[Andreas Plesch]

On Tue, Oct 10, 2017 at 10:58 AM, Don Brutzman <brutzman at nps.edu> wrote:
> On 10/10/2017 7:36 AM, Andreas Plesch wrote:
>>
>> On Oct 9, 2017 11:02 PM, "Andreas Plesch" <andreasplesch at gmail.com
>> <mailto:andreasplesch at gmail.com>> wrote:
>>
>>     Good points but consider:
>>
>>     Interpolators with step functions act almost like sequencers but do
>> not have
>>     the 'next' and 'previous' fields. These fields could be added,
>> however.
>>     'next' would proceed to next keyValue interval, either to the lower
>> limit or
>>     to the equivalent interpolated value within that interval. With these
>>     fields, I agree, there would be no need for more sequencers.
>
>
> true.  though the notion of /next/ and /previous/ wouldn't seem to be
> workable for interpolators since each range interval can be nonlinear or
> even instantaneous/discontinuous.
>
> so this point about gaining /next/ and /previous/ functionality is actually
> a good justification in support of defining sequencer nodes for
> floating-point values.
>
>> Another, perhaps less invasive approach would be to allow integers as
>> input to interpolator key fields. Then IntegerSequencer could be used to
>> drive any interpolator. Although keys are often in the 0 to 1 range, they
>> can have any value.
>
>
> as above, I don't think this can work for interpolators.

Although I do think that a dedicated scalar sequencer would be
preferable, I am not sure I can see the problem of next/previous
fields for interpolators. When an Interpolator produces an output, it
selects a well defined interval which it could remember. When the
interpolator in the next cascade receives a next input, the next
interval will be also well defined. It is now just a matter of
specification which value from the corresponding keyValue interval
should be returned. It could be the lower limit. Or it could reuse the
relative position of the key within the previous interval (the local
fraction), and use that to interpolate within the current interval,
either linearly or non-linearly in the case of the case of spline or
spherical interpolators.

Another idea would to augment IntegerSequencer with a SFFloat [out]
floatvalue_changed field which provides the value as a float in
addition to integer.

> however we might have an inputOutput SFInt32 /index/ field for sequencers
> that would allow such selection and reporting of which range-interval is
> active. presumably setting index to value i would be equivalent to providing
> set_fraction value of key[i].

Yes, that would be equivalent. I think an index field for
Interpolators in addition to Sequencers could work as well, somewhat
similar to allowing Integers as input to set_fraction.

> remaining task: ensuring the algorithm works in all cases, similar to
> current discussion on interpolator prose/equations.

You may be referring to the discussion on sequencer function definition ?

Best, Andreas
-- 
Andreas Plesch
Waltham, MA 02453