<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>An idea for implementing a "fade out" on Stab Weights (from 1 to 0, or a fade in from 0 to 1) could be to set a number of frames over which the fade out should occur, say 10 or 15 (input by the user), then just click Apply, and it does it automatically to
any track that doesn't run the entire length of the shot, or that doesn't start or end on the first or last frame.</p>
<p><br>
</p>
<p>That could also be set up to just work on the selected tracks.</p>
<p><br>
</p>
<p>I did this manually to a long panning shot last night, fading between 5 tracks, and it worked very nicely.</p>
<p><br>
</p>
<p>Sean</p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Ichthyostega <prg@ichthyostega.de><br>
<b>Sent:</b> Thursday, September 1, 2016 7:36 AM<br>
<b>To:</b> Blender tracking and VFX list<br>
<b>Subject:</b> Re: Stabilizer: ideal usage</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
...we're here already in the middle of an interesting discussion about<br>
what is still lacking with the current state of the 2D stabilizer.<br>
<br>
Thus I'd propose we'll move to the VFX mailing list, and I've<br>
posted this response already there...<br>
<br>
On 01.09.2016 07:11, Sean Kennedy wrote:<br>
> Also, another question - is it possible to see the keyframes created when <br>
> animating the Stab Weight in the dope sheet or graph editor?<br>
<br>
<br>
No, and this is indeed one of the further topics on my todo list regarding<br>
stabilization. If I understand the problem correct, the current implementation<br>
in blender erroneously assumes that all animated properties live within the<br>
3D scene. But in fact, Blender's animation system is completely generic,<br>
and thus nothing prevents us from animating *any* property which is in<br>
a data block and bound to the UI.<br>
<br>
Thus here we're now happily animating values which are *not* part of the<br>
3D scene, but rather somewhere in the postprocessing graph.<br>
<br>
Thus, when you try to open and init a new dope sheet or F-curve editor,<br>
Blender just misses those animation data -- in spite of them being there,<br>
being persistent and working just fine when you actually "drive" the timeline.<br>
<br>
as said -- this is my guess. I don't know actually, because if I knew, I had<br>
probably fixed it already, since it is an annoyance in practice. :-D<br>
> What about the "expected" tools, if those are keyframed, can we see the keys <br>
> anywhere? I'm guessing we cannot. If we can, I couldn't find them.<br>
<br>
same problem. Can't access them with the regular animation editors.<br>
<br>
<br>
> Also, when animating the "expected" tools to compensate for the stabilized <br>
> motion, is the curve applied to these keyframes a smooth curve or linear?<br>
<br>
Again, I don't know. But I know that the moment you add animation to those<br>
params, Blender creates a new F-curve behind the scenes. We know this because<br>
the stabilizer explicitly fetches and evaluates these F-curves, in order to<br>
work correct whenever it has to visit another frame than the "current" frame<br>
for its calculations.<br>
<br>
Thus probably it is just like the default behaviour for every F-curve<br>
<br>
<br>
> And watching your original demo video again, Hermann, WOW. It must have<br>
> taken a long time to animate all the Stab Weights on that footage!<br>
<br>
It is manageable if you proceed in a systematic way. But yes, stabilizing such<br>
an shot with extended movements does take some time.<br>
<br>
Also I was thinking about possible ways how to support and speed up this task.<br>
Unfortunately I am somewhat lacking inspiration here. The only thing I could<br>
imagine is some operator, where you'll select two animation tracks (assumed<br>
that we've managed to make them visible in the dope sheet) and then somehow<br>
"cross-fade" them. That would be at least some support to speed up that<br>
boring task, but even this is a bit of a challenge to specify it on<br>
a technical level. What precise does "cross-fade" mean? What if those<br>
two tracks have multiple overlapping intervals? What if more than two<br>
tracks are selected?<br>
<br>
-- Hermann<br>
<br>
<br>
PS: in practice you do not need to cross-fade *all* irregular tracks,<br>
only those which cause a visible jump. Which typically is on the<br>
end facing away from the anchor frame, and also only if that<br>
track creates a specific "drag" which differs from the effect<br>
of the remaining tracks<br>
<br>
<br>
</div>
</span></font></div>
</div>
</body>
</html>