Relative animation?...!

I have my mind bowling due to to something that I’ve released recently.


I’ve been asked to implement one feature that would make happy to many users:

“Be able to recenter the origin of the shape layer to where the user wants without move the shape itself”

This has been discussed with the two persons that requested me that and we get stuck on the problem that using the mouse and the Transform tool, we would need one additional key modifier to take account to do that and add more keyboard modifiers to the Transform tool is not a good idea I think.

In any case, the problem of “re-center the origin” that’s how I call the feature needs to solve the problem of the case that the origin and the shape vertexes were animated value nodes. I have one solution for that. In case it is found an animated value node, then do not add one more waypoint, but modify all the values of the waypoints by one offset given by the translation of the origin form the original position to the final position. The offset for the vertexes would be the same value but negative. This way the origin re-center is achieved.

Spinning on that idea of offset the waypoint’s values then it came to my mind if that could be a mode itself and not a consequence of an action. Then it was born the “Relative Animation” concept.

It is not a new thing (it is available for example in Anime Studio) but here we can push that a little more away.

Let me explain: in Synfig, the parameters can be:
constant or animated
Animated value are just a set of waypoints for a parameter that are evaluable at a certain time.
But a waypoint is composed by:
a) a time
b) a value node that holds the value of the parameter a that time
c) two in/out interpolation type values

So each waypoint has one value inside “and that value can be animates as well” because it is a value node!!!

Usually (always until now) those values inside the waypoint are constant but I want to make them animated if the user wants so there are different cases:

  1. Parameter is constant and you are in non animation mode and in relative animation. If you modify the parameter it would act as usual. Modify a Constant in non animation mode is immune to relative or not relative animation

  2. Parameter is constant and you’re in animation mode. If you’re in relative animation, it won’t produce a waypoint, because relative animation doesn’t produce waypoints in parameters. So it would act like if you’re in non animation mode.

  3. Parameter is animated. Here comes the magic. If you’re not in animation mode and try to modify the animated parameter the program complains, telling you that he cannot modify the animated other than in animation mode, but if you’re in relative animation, it would offset the waypoints instead. What would happen if you modify an animated parameter in animation mode with relative animation enabled? it would animate the offset of the waypoints and won’t add a new waypoint on the animated.

The behavior can be established to not need one additional mode and to not be possible to animate the waypoint offset (because it would need one new user interface to edit those offsets). Also, the relative animation can be act only in non animation mode, so it is simpler for the user for the moment. This will imply that waypoint’s value nodes will be always constant, but can be offset by the user when he wants.

Additionally, maybe, I have to research it, we can check if there are waypoints selected and apply the offset to those waypoints only. Currently I don’t know if the waypoints selection can be accessed easily.

In any case it won’t solve the re-center of the origin completely because it would need two movements from the user like now: select the vertexes and move around the origin, then move the origin to where the vertexes where. But would solve the problem when the vertexes are animated


To solve the problem of the need of a new key modifier to do the origin re-center, I have had another idea.

If the user moves the origin in relative animation mode, then when the user releases the mouse, a pop up menu would offer two options:
Normal relative animation (origin is offset)
Extra relative animation (the objects that are relative to the origin are offset the same value but in contrary direction)

If the user clicks outside the pop up menu the first option is used
It would happen only for layer parameters with a name of origin

This idea can be independent of the relative animation I think because it would be implemented before and independent of the relative animation mode.

So the feature description is:
“when user moves with the mouse a origin layer parameter it is offered a pop up menu to make it a relative offset of the shape to the origin movement”

Alright, I’ve put it on a post, now questions and additional ideas.

Fantastically useful feature!

Note about FEATURE 1:
I remember we have discussed with you at LGM the solution of this problem, but with different approach. It was called… poses, if I remember correctly.

Note about FEATURE 2:
I think we can solve that in more simple way. Imagine if we can set offset to the origin duck. So, the vertex positions are unchanged, but the origin is drawn into different place (according to the "offset value). It’s much the same as the “focus” property we already have in group.

Yes, that poses ideas is the consequence of expand the relative animation idea. That poses feature would imply much more work, changes and interface. On contrary, the relative animation could be implemented with a few lines of code and in its light version (only constant value nodes for waypoints) wouldn’t need even any new user interface.

I don’t think it would work. You can offset the origin with a convert type but it won’t ‘-offset’ the vertexes at all. Otherwise, I don’t understand how can be achieved without change the layers behavior when calculates the vertexes position based on the origin.

The idea of this action is something quick and accessible for the user that avoid to need to move the origin and move then back the vertexes to the original place.

I mean, do we really need to change vertexes position? Maybe it will be enough if origin duck will get shifted?

I have a concept about this, it is introducing the “Initial Status” for layers (for group layer, warp layer, bone layer). I need some time to elaborate on that.

Idea: Offset the origin using “Add” value node convert.

The duckmatic code can be modified to allow editing of the “LHS” param inside the “Add” (and ignore the “RHS” completely).

Then an action is needed to take the current origin and encapsulate it inside an “Add” value node convert. The current value becomes the “RHS” and the “LHS” is initially set to (0.0, 0.0).

If the origin is animated before the action is applied then it will remain animated after also, but the animation would become uneditable. Maybe have an action to swap the “LHS” and “RHS” too, so that both can be edited as necessary.

EDIT: Hmmm, this would also allow things like linking the origin of two layers, apply an offset to one (or both), then move both layers by editing (animating) the original linked origin value.

I don’t get it!
it sounds simple but it’s not. For example: Radial vectors with animation will act differently if you just change the the values by the offset of the new desired origin.
Maybe I misunderstood the concept you are mentioning, but I think a tool like that can be applied only after the drawing. when the splines are pure x y values.

Regardless if you can edit the LHS or the RHS subparameters of the origin converted to Add, the layer will always look up the result of the origin value node to calculate the rendered shape. And if you don’t modify the values of the vertexes they will move, what is not wanted.

Maybe this image could help.

The shape, originally has its origin at O, then I modify the origin with one Offset to be at O’ but the shape will move to the other place (the washed out shape) so we need to apply -Offset to each vertex to restore the original position.

Whatever modification you do to the origin, you need to modify the vertexes too. Unless you want to modify the layer’s logic what I think it is not a good idea.

I guess for me it will be easier to explain in the following form:

That implementation is absolutely fantastic! I’ve always missed layer rot. in Synfig. And using focus point as origin offset is great!

Would be a nice addition to my cut-out animation workflow.

Then just make the RHS equal to -Offset and the LHS equal to O’:

Should work as long as only the LHS value is shown as the green origin duck.

The minus_Offset can be calculated once (when user does recenter action), it doesn’t have to be a Substract value node.

In short, the Add value node does the same thing as the Translate layer in the first part of Zelgadis explanation (but without the need of adding a Translate layer and making a Group).

EDIT: Back to the original idea of relative animation. Does it make sense to make the value of waypoints animated? Sure it allows to do silly things like:
stacked-waypoints.sif (146 KB)
The red square interpolates linearly from the green square to the blue square, both of which are animated themselves. Unluckily editing with synfigstudio doesn’t work as expected (wrote the SIF file manually). Is there any use for this? (besides completely confusing the user :laughing:)

Is this an idea that will be developed? It would be very helpful in setting up characters i think.

This is a part of the “Improve tools for cut-out animation” priority. It is planned to develop someday, but it’s not the priority for the next month. For next month the chosen priority is Bones. :slight_smile:

Ah, I’ll grab that one as soon as I can!

here is a animation of a helicopter fly by animated using the scale widgt and focal point widget as they currently are.The animation is done by scaling the copter along the focal point.
whirlybird 1.sifz (15.9 KB)

The solution got its basic implementation as part of Ivan’s work on bones branch -