I’ve been trying to link a small object’s origin to a larger bline, so that when the larger object moves, it takes the smaller one with it, and so that the smaller can move along the larger’s perimeter. However, every time I try to link the small object’s origin to the larger bline, and then move the larger Bline, the smaller always stays behind & instead rides along the outline of a ‘ghost’ version.
(On another note, if the Bline isn’t centered in the canvas when I try to link the small object, the object links to a afore-mentioned ‘ghost’ in the middle on the canvas, not to the Bline I asked it to link to.)
Can someone explain why it does this - is this what’s supposed to happen, and I’m the one who is wrong?
(BTW, the objects and lines I’m using are basic circles and stars. Nothing with fancy vertices or layers.)
I think this behaviour has to do with the way encapsulation works in synfig. When you encapsulate something (a bline for example) it gets its own canvas. This new canvas has it own origin. When you move the encapsulated object around, you’re actually moving that canvas around inside the main canvas. From the point of view of the bline there is no movement (it is sitting still inside the new canvas).
At least that’s how I understand the way canvasses work. Now for a solution to your problem:
You want the small object to move with the bigger object. For this to happen, the small object should be inside the same canvas as the bline that it needs to follow
In the layers panel, this should look something like this:
Aha, got it. Thanks.
So I’m gonna have to encapsulate everything to work with it after all.
I’m pretty unexperienced with coding, but there isn’t a workaround (to get the object to link to the line, and not a ghost, without encapsulating,) is there?
Never use origins to translate regions or outlines but use the blinepoints origins to move the shape.
So, if the linked object and the bline to where it is linked to, are in the same scope (root canvas or paste canvas) AND you don’t animate the origin of the bline, the ghost problem won’t happen.
Linking is a global concept (document scope) so the linked values doesn’t get the transformations (scale and translation) than an encapsulation can provide and simply link the values. What in fact happens is that when you link two parameters of two layers a “value node” is created and the two parameters values are replaced by this single global value. Later if the layers have transformations due to its own scope the linked value (which is the same value in global scope) get separated when rendered due to the difference of transformations each layer suffers.
Paste Canvases are, like dustbunny said, local canvases (even with its own timeline) so you have to consider each sub-canvas parameters when doing crossing linking.
Also, user cannot access to paste canvases definitions beyond the parameters scope, because there is not interface for that. In that case, paste canvases inherits the non explicit parameters (i.e. frame rate) from the parent canvas so it keep expected consistence.
Later, if you export the canvas (right click on the canvas parameter) you can edit all its definitions by double clicking on it at the canvas browser panel, acting like an independent and reusable canvas (like exported value nodes do).
