[Bf-animsys] f-curve modifier thoughts

[Joshua Leung]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-animsys/attachments/20090516/21768921/attachment.html>