Here's a rectangle, a triangle and two circles to mark my skeleton's pivot points.
I moved the triangle rotation centre to the left apex. Triangle rotation works as expected.
I grouped all the shapes and moved the group's rotation centre to the lower line midpoint. When I rotate this group, I expect the triangle's rotation centre to remain at the apex.
Look what happens instead. The triangle rotation centre appears to move up and left, away from the original pivot. I eventually realised that it stays at centre-left of the triangle's bounding box.
Noticed this as well when reading the same post. Based on my investigation the rotation center is saved relative to bounding box instead of the local coordinate system. So every time you rotate child elements, the parent bounding box changes, ruining previously set rotation center. This make it hard to create a nested transformation hierarchy for describing series of joints or similar objects.
I am guessing that it is partially related to "Transforms/Store transformation/optimized". Which if I am not mistaken is default mode. With it set to "optimized" inkscape will whenever possible remove any path object transformation and instead recalculate the positions of each path node. If the transformation was stored relative to local coordinate system, then the transform flattening would mess with it. On the other hand, it's not like it would be hard to recalculate the transform center not just the node positions.
Another theory for potential reason behind this choice is the default rotation center being in the middle. In the bounding box relative mode that's 0,0. In the local coordinate mode it would vary depending on shape and size. But that's not an unsolvable problem either. Instead of having center type being Vec2, make it Optional<Vec2>. And treat the default unspecified rotation center as center of bounding box.
I noticed similar issues when transform behavior set to optimized. When applying rotations and other transforms, the path data is recalculated. Possible introduction of accumulated rounding errors? Especially with repeated rotations like in this example? Is this causing this issue? No clue.
Should be noted - even if you have transform behavior set to optimized - if you perform a transform (scale, rotate etc) on a group of objects, Inkscape will not recalculate the individual path data. It will apply a Transform matrix on the group. So that blows my theory about accumulated rounding errors.
Playing with this and I noticed that the triangle's rotation center doesn't change math wise (in the XML) in relation to the group each time you rotate the group. In other word, it is not updated. So - when you select it individually to rotate it, the rotation center is wrong in relation to the square. You literally have to reset the rotation center in relation to the rectangle yet again. Bug? Most likely. Will it be fixed? To quote Tyler 🤣 ""not gonna fix" kind of bug."
Sort of blows my theory about groups having "relational constraints".
Playing with this and I noticed that the triangle's rotation center doesn't change math wise
That's what "rotation center is saved relative to bounding box" means. Relative to the center of bounding box center to be more precise. It's seems to be more of bad but intentional design choice for the underlying file format (with major downsides in certain situations) not a bug. The benefit is that it automatically preserves the rotation center when the "store optimized" thing flattens transformation. The downside is that in case of nested transformation hierarchy changing anything breaks the rotation center (which feels like a bug to user).
Storing rotation center relative to local coordinate system would be the most straight forward way of fixing it, but that would be a breaking change affecting all the existing files and compatibility with older inkscape versions.
It could be possible to compensate for the change of bounding box without meaning of rotation center property in a way that's fully backwards compatible, but that would mean modifying properties of all parent objects when you are modifying a child object not just the object you are directly interacting with. That's already much messier and potentially computationally expensive compared to the backwards incompatible way. To make things worse bounding box can change in many different ways not just rotation.
If the backwards incompatible mehtod gets introduced changing the meaning of rotation center it might worth considering to make it a parameter (doesn't have to be exposed to user). With the choice of being relative to: bounding box center (old default behavior), local coordinate system (desired behavior for custom positioning), any other bounding box corner. That would not only be more backwards compatible, but also allow preserving rotation center when it's set to one of the corners. Both the "bounding box center (current)" and "relative to local coordinate system" would break the rotation center set to one of the bounding box corners. After thinking about it more "relative to bounding box corner" wouldn't work as nice as I thought, since after the rotation bounding box corner wouldn't be a corner anymore.
Is it a "programming bug". Of course not. It is what I consider a "UX Bug". The user is expecting a certain behavior and the "fix" would most likely cause other issues. It is simply not worth fixing. Developers have bigger fish to fry. Like this one: https://gitlab.com/inkscape/inkscape/-/issues/5446#note_2275362249 🤣🤣
So - To quote Tyler 🤣 ""not gonna fix" kind of bug."
I am just happy that Paddy posted this so I can compensate for this in the future if I come across this issue.
Beyond the Basics Rotation Centres Inside Rotated Group
Inkscape.org
Here's a rectangle, a triangle and two circles to mark my skeleton's pivot points.
I moved the triangle rotation centre to the left apex. Triangle rotation works as expected.
I grouped all the shapes and moved the group's rotation centre to the lower line midpoint. When I rotate this group, I expect the triangle's rotation centre to remain at the apex.
Look what happens instead. The triangle rotation centre appears to move up and left, away from the original pivot. I eventually realised that it stays at centre-left of the triangle's bounding box.
Is this a bug or intentional behaviour?
This post arises from trying to answer this related topic.
https://inkscape.org/forums/questions/part-vs-assembly-in-inkscape/
Ja that makes my brain hurt. I would regard it as a bug, but it might be a "not gonna fix" kind of bug.
Noticed this as well when reading the same post. Based on my investigation the rotation center is saved relative to bounding box instead of the local coordinate system. So every time you rotate child elements, the parent bounding box changes, ruining previously set rotation center. This make it hard to create a nested transformation hierarchy for describing series of joints or similar objects.
I am guessing that it is partially related to "Transforms/Store transformation/optimized". Which if I am not mistaken is default mode. With it set to "optimized" inkscape will whenever possible remove any path object transformation and instead recalculate the positions of each path node. If the transformation was stored relative to local coordinate system, then the transform flattening would mess with it. On the other hand, it's not like it would be hard to recalculate the transform center not just the node positions.
Another theory for potential reason behind this choice is the default rotation center being in the middle. In the bounding box relative mode that's 0,0. In the local coordinate mode it would vary depending on shape and size. But that's not an unsolvable problem either. Instead of having center type being Vec2, make it Optional<Vec2>. And treat the default unspecified rotation center as center of bounding box.
I noticed similar issues when transform behavior set to optimized. When applying rotations and other transforms, the path data is recalculated. Possible introduction of accumulated rounding errors? Especially with repeated rotations like in this example? Is this causing this issue? No clue.
Should be noted - even if you have transform behavior set to optimized - if you perform a transform (scale, rotate etc) on a group of objects, Inkscape will not recalculate the individual path data. It will apply a Transform matrix on the group. So that blows my theory about accumulated rounding errors.
In other words - I have not the slighest clue.
Playing with this and I noticed that the triangle's rotation center doesn't change math wise (in the XML) in relation to the group each time you rotate the group. In other word, it is not updated. So - when you select it individually to rotate it, the rotation center is wrong in relation to the square. You literally have to reset the rotation center in relation to the rectangle yet again. Bug? Most likely. Will it be fixed? To quote Tyler 🤣 ""not gonna fix" kind of bug."
Sort of blows my theory about groups having "relational constraints".
That's what "rotation center is saved relative to bounding box" means. Relative to the center of bounding box center to be more precise. It's seems to be more of bad but intentional design choice for the underlying file format (with major downsides in certain situations) not a bug. The benefit is that it automatically preserves the rotation center when the "store optimized" thing flattens transformation. The downside is that in case of nested transformation hierarchy changing anything breaks the rotation center (which feels like a bug to user).
Storing rotation center relative to local coordinate system would be the most straight forward way of fixing it, but that would be a breaking change affecting all the existing files and compatibility with older inkscape versions.
It could be possible to compensate for the change of bounding box without meaning of rotation center property in a way that's fully backwards compatible, but that would mean modifying properties of all parent objects when you are modifying a child object not just the object you are directly interacting with. That's already much messier and potentially computationally expensive compared to the backwards incompatible way. To make things worse bounding box can change in many different ways not just rotation.
If the backwards incompatible mehtod gets introduced changing the meaning of rotation center it might worth considering to make it a parameter (doesn't have to be exposed to user). With the choice of being relative to: bounding box center (old default behavior), local coordinate system (desired behavior for custom positioning), any other bounding box corner. That would not only be more backwards compatible, but also allow preserving rotation center when it's set to one of the corners. Both the "bounding box center (current)" and "relative to local coordinate system" would break the rotation center set to one of the bounding box corners. After thinking about it more "relative to bounding box corner" wouldn't work as nice as I thought, since after the rotation bounding box corner wouldn't be a corner anymore.
To quote Tyler 🤣 ""not gonna fix" kind of bug."
Is it a "programming bug". Of course not. It is what I consider a "UX Bug". The user is expecting a certain behavior and the "fix" would most likely cause other issues. It is simply not worth fixing. Developers have bigger fish to fry. Like this one: https://gitlab.com/inkscape/inkscape/-/issues/5446#note_2275362249 🤣🤣
So - To quote Tyler 🤣 ""not gonna fix" kind of bug."
I am just happy that Paddy posted this so I can compensate for this in the future if I come across this issue.