Pierre Marc Dumuid wrote:
> In regards to this, I was thinking of proposing: modify the right click on
> keyframe menu to show:
>
....
> but then, I figured it would be really cool if we could be comply with the
> inkscape way of beizer
> management.
....
>
> Does anyone with knowledge of the source know about this stuff, and could
> offer a comment??
>
> I am purely playing around, (and should be writing up...) so please don't
> expect anything too
> soon...
Hello Pierre,
what a nice coincidence! Yesterday I was looking in excactly the same issue.
For our
film project I have to do some sequences with heavy automation and I came up
with the
conclusion that I need to somehow fix this behaviour with every keyframe
initially having
slope=0, ere I will get mad at some point ;-)
At first glance, it seems you located exactly the code I was searching. As
Andraz pointed out,
when using the CTRL-Key you can drag the two control points out of every
keyframe. By this you
can indeed control the slope, but this is very tedious and almost never 100%
exact. So, if you
demand professional results, this will be much much much work.
There seems to be another Problem: If I am informed right, Cinelerra uses this
bezier-courve
feature for all Plugin Autos as well. Is this correct??
Some weeks ago I tried to "stabilize" a shot taken from bicycle. It is rather
smooth, but has
some slight slow tilt movement. I thaught, I could correct this rather easy by
keying the
rotate plugin but found (to my surprise) that I had to set a keyframe on
virtually every frame
because the automation never did what I expected. If my theory is right and
this bezier courve
feature ist used for this sort of keyframes as well, this whould explain why
this happened...
I located code calculating a bezier courve. It is in cinelera/floatautos.c
FloatAutos::get_value(position, direction, &previous, &next)
This function indeed calculates a bezier courve in the well known way. But
there are
some oddities around this.
1) There are a lot of case distinctions of the sort
if(direction == PLAY_FORWARD &&
.....
I really can't beleave why the direction of playback should matter in any way
how the bezier courves of the automation are calculated!
OK, we have to be carefull on what time position we evaluate the bezier
courve
because every frame spans a time intervall and if we are moving backwards, we
enter this time intervall at another position. :-)
2) Some of the "backward movement" cases are looking very "fishy" at first
glance.
I have the suspicion that they use the altogether wrong control points. But
the
corresponding PLAY_FORWARD - cases look right.
3) The bezier function is evaluated only in one dimension: they calculate
y-values.
Normally, a bezier function is a parametric courve and by moving the control
points, you can create accelerations of movement along the courve as well.
OK, for the keyframes, we really don't need accelerations etc, as we always
have to evaluate the function at a given point on the time scale.
But I draw another conclusion from this: The displayed control points can't
be
correct in a mathematical sense. Because, if we draw the points far away from
the start or endpoit of the line segment, there should be much acceleration,
but this info isn't used (and can't be used, because we rather set x=t and
only
use the y value of the bezier function).
Or, to put it the other way round: we fix the x coordinates of the control
points
to be 1/3 and 2/3 of the distance on the x axis. Because for this value, the
bezier function yields x = t
If you would like, we could "combine forces" in some way!
I would propose, to proceed in rather small steps
(1) fix the initial value of new keyframes to be such as to yield a
smooth courve while taking into account the positions of the
immediate neibouring keyframes
(2) add a "Mode" to each keyframe. This mode can be:
- smoth (default)
- linear
- free
Add this three modes to the context menu of the keyframes.
Whenever a keyframe is modifyed by ctrl-dragging the handles
with the mouse, its Mode switches to "free"
extend the "smoth" mode such as to readjust the control points
(i.e. the slope) if any of the neibouring keyframes is modified.
(3) Extending the keframe editing code in the way you proposed to go some way
into
the direction of common graphics programs like inkscape or corel draw or
the like...
What do you think of this proposal?
Cheers,
Hermann Vosseler
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
