I hope that object scaling can be controlled not only through the UI, but also by manually entering numeric values for both the X and Y scale axes. This would make it much easier to apply the exact same scaling to other objects by simply reusing the same values.
When using the UI scaling handles, I have occasionally encountered strange scaling behavior where objects suddenly move far outside the canvas. So far, I still don’t know what causes this. Hopefully this can be implemented in Synfig someday.
I already tried, but it doesn’t work. As far as I know, we can only use the keyboard arrow keys — up/down or left/right — mainly for very small scale adjustments.
Wow, I didn’t know anyone uses the Scale tool. I thought we all just group things and then use Group Transformation to handle the scale of objects. Isn’t the Scale tool is kinda obsolete now?
You have to enjoy using log values when using Scale Layer instead of Group Transformation (or use converters).
For the strange behavior, maybe it is due to which quadrant was used, and which scale.
That’s true — scaling through a group or a Scale Layer can also work, but only when the group itself is linked to the bones. However, problems occur if a BLine object layer (inside a scaled group) is linked to bones (in my case, the bones are outside the group).
If I place the bones inside that group, another issue appears when those bones have a parent bone outside the group
Can you explain why this happens when I scale a group? This is a comparison between object scaling and group scaling. I also tried using a Scale Layer, but the result was not what I expected.
There were always issues with bones, also depending the quadrant.
Sometimes there are fixes targeting only one issue but having side-effects, or neglicting to check the validity for other layers (or nesting).
By someone alone, in his corner.
We should not scatter on plenty of new features but to organize brainstorming/hackathons.
Like “this month we will try to fix X feature, let’s work on it all together”
AFAIK, the current bone/skeleton code is ready for bone-linking stuff at same layer hierarchy level. If linking to nested layers, you can’t change transformation info of the layer groups/folders (offset, rotation, scaling)…
AFAIK (again XD), the Smooth Move, Rotation, Scale and Mirror tools were created to handle the vertices of Region and Outline layers to ease the drawing back then (2005-6)… Blender does it today yet, some other pro/famous 3D software never had these features. But Blender let it clear to user: in Edition/Modelling mode. Synfig doesn’t make it clear.
One possible issue is that the bone deformation may be evaluated in a different transform space than the BLine when the artwork is placed inside a scaled group.
For example:
Bone = parent/global space
BLine = local space affected by group scale
Because of this mismatch, the bone system may calculate deformation using coordinates that do not fully match the transformed BLine points. This can lead to distorted deformation, incorrect weighting, offsets, or unstable rotations.
A possible improvement could be to evaluate the group transform first, so the BLine points are converted into the correct transformed space before the bone deformation is applied. Another approach would be to transform the bone into the local space of the group so both systems operate in the same coordinate space during deformation.
In other words, the deformation pipeline could become something like:
BLine local points
→ apply group transform
→ convert to matching bone space
→ evaluate bone deformation
instead of evaluating the bone deformation before the group transform is fully resolved.
Another alternative approach could be to treat the group transform as a “bake/apply transform” operation. For example, when a group is scaled, the scale could optionally be applied directly to the actual BLine point data, generating new transformed coordinates while resetting the group transform back to identity.
Example:
Point (10,10)
→ group scale 2x
→ point becomes (20,20)
After that, the group itself would no longer carry additional scale data, and both the bones and BLine points would remain in the same coordinate space. This could help avoid transform hierarchy conflicts and produce more stable bone deformation results.