[Bf-vfx] Stabilizer: ideal usage

[Ichthyostega]

...we're here already in the middle of an interesting discussion about
what is still lacking with the current state of the 2D stabilizer.

Thus I'd propose we'll move to the VFX mailing list, and I've
posted this response already there...

On 01.09.2016 07:11, Sean Kennedy wrote:
> Also, another question - is it possible to see the keyframes created when 
> animating the Stab Weight in the dope sheet or graph editor?


No, and this is indeed one of the further topics on my todo list regarding
stabilization. If I understand the problem correct, the current implementation
in blender erroneously assumes that all animated properties live within the
3D scene. But in fact, Blender's animation system is completely generic,
and thus nothing prevents us from animating *any* property which is in
a data block and bound to the UI.

Thus here we're now happily animating values which are *not* part of the
3D scene, but rather somewhere in the postprocessing graph.

Thus, when you try to open and init a new dope sheet or F-curve editor,
Blender just misses those animation data -- in spite of them being there,
being persistent and working just fine when you actually "drive" the timeline.

as said -- this is my guess. I don't know actually, because if I knew, I had
probably fixed it already, since it is an annoyance in practice. :-D
> What about the "expected" tools, if those are keyframed, can we see the keys 
> anywhere? I'm guessing we cannot. If we can, I couldn't find them.

same problem. Can't access them with the regular animation editors.


> Also, when animating the "expected" tools to compensate for the stabilized 
> motion, is the curve applied to these keyframes a smooth curve or linear?

Again, I don't know. But I know that the moment you add animation to those
params, Blender creates a new F-curve behind the scenes. We know this because
the stabilizer explicitly fetches and evaluates these F-curves, in order to
work correct whenever it has to visit another frame than the "current" frame
for its calculations.

Thus probably it is just like the default behaviour for every F-curve


> And watching your original demo video again, Hermann, WOW. It must have
> taken a long time to animate all the Stab Weights on that footage!

It is manageable if you proceed in a systematic way. But yes, stabilizing such
an shot with extended movements does take some time.

Also I was thinking about possible ways how to support and speed up this task.
Unfortunately I am somewhat lacking inspiration here. The only thing I could
imagine is some operator, where you'll select two animation tracks (assumed
that we've managed to make them visible in the dope sheet) and then somehow
"cross-fade" them. That would be at least some support to speed up that
boring task, but even this is a bit of a challenge to specify it on
a technical level. What precise does "cross-fade" mean? What if those
two tracks have multiple overlapping intervals? What if more than two
tracks are selected?

-- Hermann


PS: in practice you do not need to cross-fade *all* irregular tracks,
    only those which cause a visible jump. Which typically is on the
    end facing away from the anchor frame, and also only if that
    track creates a specific "drag" which differs from the effect
    of the remaining tracks