[Bf-animsys] f-curve modifier thoughts

[Aurel W.]

Hi,

> If it turns out that only 1 modifier, i.e. filter, would require this extra
> complexity, but every other modifier really doesn't, then IMO it's not worth
> it. Filter then would be better made into a operator that users could
> interact with to tweak the results.
All modifiers, which use more than one value on a frame (only one
value means sort of implementing a function R->R) won't be able to be
stacked on other modifiers. I guess most modifiers will do so, except
for those which just generate a curve or perform some scaling or
clipping on the values.

> 2) Not all modifiers modify the keyframes exclusively. So "passing a curve"
> really means passing samples, which leads to...
Yes, modifiers would need to output already sampled data most of the
time, or at least many modifiers can be implemented much easier this
way. So a modifier in a stack would need to pass on all samples on a
curve to the next modifier. However, it would be good to keep things
flexible so even bezier-to-bezier modifiers would be possible at some
point. Of course those won't be able to operate on sampled data and
therefore not on top of modifiers which create such an output. There
are some pros of such modifiers, for e.g. they can be 'applied' and
then curves can be further tweaked by hand (maybe modifiers won't
create exactly the output an animator desires in all situations, but
still be of great use. Therefore it can be an issue to place them
completely at the end of evaluation, where no further editing is
possible). I know, that's not really the issue right now, I just
wanted to mention this too. We shouldn't completely forget about
bezier-to-bezier modifiers and with the current design of evaluation
those won't be possible at all.

> 3) Evaluating the curve only at intervals we are interested in circumvents
> the problems associated with having to generate some cache of sampled
> data-points and having to deal with the problems of making sure the cache is
> updated correctly whenever a change occurs. The pointcache system for
> physics sims is a clear example of how these things can go so terribly
> wrong, painful, and utterly disasterous!
> 4) Associated with caches is an increased amount of data that needs to be
> stored. From personal experiences, I'd most definitely want to avoid this
> whenever the calculations required would not end up taking excessively long
> to run
Yes, when passing the entire curve or only the 'region of interest' up
the stack this has to be handled differently. However, there is not
such a big difference between:
for_all_samples(float->float->float->...->float) and
for_all_modifiers(curve->curve). When there is some change of a
modifier or the underlying f-curve, each modifier can calculate an
entire new curve (sampled one) and pass it up to the next modifier and
so on. With caching, do you mean storing the intermediate samples, the
output of each modifier, so when there is a change somewhere in the
stack that not the entire stack starting from the ground has to be
evaluated again, just only from the point where it was changed?
Exchanging memory for computation time?
Because let me put it this way, the current implementation of
evaluation is slow and when I say slow I don't mean "not fast", I mean
really, really slow, when you take into account what's calculated in
the end. But still, at the moment it is by far fast enough for using
several modifiers (even if the current one don't calculate much) on
one curve. Evaluating sample by sample creates a lot of overhead,
calculating an entire curve and then pass it on can be implemented way
more efficiently.
Therefore I think a real modifier stack wouldn't be slower, I guess
without using any complex caching it would be even faster than current
evaluation. Of course, when at the end of the stack, the values have
to be queried frame by frame any time, the evaluated samples have to
be stored somehow and then be passed value by value, but that's not
complex caching and manageable.

> 5) To have an easy to use system that was immediately understandable
> regarding the operation you are trying to perform. IMO, the mesh modifier
> system fails big time on this, requiring a LOT of confusing boilerplate,
> obfuscuating the underlying operations a lot of the time. Mesh modifier
> system - 3d, f-curve modifier system 1.5d ;)
Yeah, let's don't overdo it and create yet another horrible system.
Keeping it flexible and future save, that's what counts. A well
designed and simple proper modifier stack may be the best solution
here.

> 6) I was lazy at the time ;)
I would say straight forward ;)

> However, I'm not ruling out the possibility of having a 'proper' modifier
> stack going on.
I would be always ready to help on this. Actually I wanted to start
working on some modifiers, but some of the things I have in mind would
require a more flexible stack and I am willing to get it that far.

Aurel




2009/5/16 Joshua Leung <aligorith at gmail.com>:
> Hi,
>
> Some good comments here.
>
> The current evaluation method was designed in this way for a few reasons:
> 1) To get the basic functionality available at least
> 2) Not all modifiers modify the keyframes exclusively. So "passing a curve"
> really means passing samples, which leads to...
> 3) Evaluating the curve only at intervals we are interested in circumvents
> the problems associated with having to generate some cache of sampled
> data-points and having to deal with the problems of making sure the cache is
> updated correctly whenever a change occurs. The pointcache system for
> physics sims is a clear example of how these things can go so terribly
> wrong, painful, and utterly disasterous!
> 4) Associated with caches is an increased amount of data that needs to be
> stored. From personal experiences, I'd most definitely want to avoid this
> whenever the calculations required would not end up taking excessively long
> to run
> 5) To have an easy to use system that was immediately understandable
> regarding the operation you are trying to perform. IMO, the mesh modifier
> system fails big time on this, requiring a LOT of confusing boilerplate,
> obfuscuating the underlying operations a lot of the time. Mesh modifier
> system - 3d, f-curve modifier system 1.5d ;)
> 6) I was lazy at the time ;)
>
> However, I'm not ruling out the possibility of having a 'proper' modifier
> stack going on.
>
> If it turns out that only 1 modifier, i.e. filter, would require this extra
> complexity, but every other modifier really doesn't, then IMO it's not worth
> it. Filter then would be better made into a operator that users could
> interact with to tweak the results.
>
> Regards,
> Joshua
>
> On Sat, May 16, 2009 at 10:51 AM, Aurel W. <aurel.w at gmail.com> wrote:
>>
>> Hi,
>>
>> I spend the evening reading most of the f-curve modifier and
>> evaluation code so far in 2.5 and I though I should share some
>> thoughts about it. What's currently there is pretty straight forward
>> and works great for the modifiers so far implemented. I want to
>> address some ideas for features and some issues with current design
>> and evaluation, which I cam across too.
>>
>> - Stack
>> At first I was a little bit puzzled about how the evaluation of
>> modifiers works, since I was more expecting a real modifier stack for
>> f-curves, where each modifier takes a curve, modifies it and passes it
>> on to the next modifier in the stack. Currently this is done a bit
>> differently, which makes a slight difference with the current
>> modifiers, but a huge one for other modifiers and even renders some
>> things impossible to implement.
>>
>> More precisely, at the moment the original curve and it's modifiers
>> are evaluated frame by frame. That means for the first modifier, the
>> entire original curve (mostly a bezier curve) is passed to
>> fcm_modname_evaluate(), which then calculates and returns a value for
>> the frame in question. This value and the original curve is then
>> passed to the next modifier, which performs another operation. The
>> value, which is evaluated by the last modifier becomes the overall
>> value of the curve on the current frame. I hope it is clear, that this
>> is more a modifier stack for single float values rather than one for
>> curves. Current modifiers (Generate, Noise, Envelope,...) operate on
>> single samples and therefore it is not a problem to stack those. But
>> other modifiers as the not yet ready 'Filter' will have to use more
>> samples then just the current one (for e.g. at frame 20, samples from
>> frame 15-25), to determine the value at the current frame. It gets
>> apparent, that such modifiers will only be able to operate on the
>> original curve and not on already modified ones.
>>
>> So with current design, each modifier will have to be evaluated
>> independently from other ones and the results will have to be merged
>> in some way to determine the over all value. My question is, wouldn't
>> be a real modifier stack much better than the current solution?
>> Personally I can think of many situations, where modifiers would need
>> to operate on top of each other, rather than just using the original
>> curve. I am also aware, that the current implementation has advanced
>> quite a lot, but maybe this should be still discussed and maybe
>> changed.
>>
>>
>> .. I guess that's enough for now,... to be continued,...
>>
>> Aurel
>> _______________________________________________
>> Bf-animsys mailing list
>> Bf-animsys at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-animsys
>
>
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> http://lists.blender.org/mailman/listinfo/bf-animsys
>
>