6 ms·

Fixing the Drift in Shape Rotations

59 points by steveruizok 5y ago

_dain_ 5y ago
>However, the rotated shapes probably have a different average center; which means that your second rotation (ie to rotate things back) is pivoting around a different point. And that's what causes the change of position. Uhh, what? Why doesn't the rotated group have the same centre as the original? The article glosses right over this without explaining it. Is it floating point imprecision? Is it from rasterization?
- glenjamin 5y ago
  I think it’s because the centre is computed using the X and Y axis, and the rotated shapes have a different bounding box on those axes.
  - lainga 5y ago
    Why would you use bounding boxes for computing centres!
    - mooneater 5y ago
      Presumably for speed
      - ulber 5y ago
        More likely ease of implementation. The use case shown here is an interactive UI element, so performance isn't really a concern.
    - mkl 5y ago
      You probably already have xy bounding boxes for every element and the selection itself as it helps with selecting, drawing, etc., so using them is the easiest option.
    - bsder 5y ago
      Computational geometry is hard. Let's go shopping! If I'm being less un-charitable, the reason is that this bug is way down the list of priorities and fixing it with a proper solution is a lot of code and work that won't result in any new revenue.
- deleted 5y ago
  [deleted]
- a_e_k 5y ago
  I'd wondered that as well. Playing with tldraw and excalidraw, it looks like it's using the center of the bounding box as the pivot point. Suppose that you have three boxes like this: * - - - * . . . * - - - * | | | | | | | | | | | | * - - - * * - - - * . . . @ . . . . * - - - * . | | . | | . | | . . . . . . . . * - - - * The pivot for rotating them will be at the @ in the center of the bounding box around the three. If you then turn that counterclockwise by 45 degrees: . . . . . . . . . * . . . . . . . . . . / \ . . / \ . . * * . . \ / . . \ / . . * @ * . . / \ / \ . . / \ / \ . * * * * . \ / \ / . . \ / \ / . . . . * . . . . . . . . . . . * . . . then the center of the bounding box has now moved towards the corner of what was originally the upper right square (because there isn't a fourth square to complete the symmetry and push the bottom of the box around the three squares down). Rotating again will now pivot around this new point rather than the original and a rotation 45 degrees clockwise back to the original angle will now have shifted the boxes. Honestly, I'd think the correct solution here would be to pivot around the center-of-mass or some other rotationally-invariant point.
  - kingcharles 5y ago
    Forget the article, I'm more impressed by your ASCII art.
  - iainmerrick 5y ago
    The bounding box is the natural implementation because it matches what the user sees -- when you select multiple objects, the rotation handle is at the corner, because where else would it be? Plus it’s very easy to code and to test. But yeah, using a rotationally-invariant point would be better than the stateful fix the article goes for. Center-of-mass would make sense except it might do strange things if you have a mix of solid shapes and lines. How much mass should the lines have? Using the centre of the bounding circle is probably best, as others in this discussion have suggested.
conradludgate 5y ago
I think instead of the center of the bounding box, I'd instead use the average center of each selected item. Each primitive will have a rotation agnostic invariant center relative to its location, so the average of those will always be invariant
xvedejas 5y ago
There should also be strategies for the choice of center to be invariant even after re-selecting the rotated set of shapes. You should be able to do this by finding the two points farthest from each other, and choosing the midpoint between the two, for instance. But that point might not be unique, so maybe finding the center of the smallest circle enclosing all objects would be a better example?
- etaioinshrdlu 5y ago
  I ran into this problem in my app and found that rotating around the center of the bounding circle instead of the bounding box was a suitable solution.
  - shahar2k 5y ago
    as someone who works with vector drawings often I would say that's unintuitive simply because the selection highlights are usually rectangular... there are many cases (lets say 3 objects in a triangle) where if you show a rectangular selection the rotation "center" will then be quite off the intuitive center
  - mkl 5y ago
    Good idea. It seems more expensive to compute, especially for curves and pen stroke elements. Did you have any problems along those lines?
    - kingcharles 5y ago
      More expensive to compute? I guess technically, but I don't think you could ever measure or see the difference without running a debugger.
      - mkl 5y ago
        If you have a page full of writing, all sorts of things get slow. I do a lot of digital writing, and have encountered a number of strange slowdowns, even in apps designed for the purpose. In particular, selecting a large number of strokes can be quite a problem. There are minimum bounding circle algorithms that are O(n) where n is the number of points, but n can get big enough that you may not want to be doing that in an interactive program. You can put objects in a quadtree or similar to look them up quickly, and that may let you discard entire strokes in e.g. Welzl's bounding circle algorithm, but with stroke or curve data you'll still need to search along each one somehow for the extreme points by whatever measure you're using (and a Bezier curve has uncountably infinitely many points, so maybe you can only find an approximate bounding circle?).
phrz 5y ago
The author treats this kind of destructive rotation as a positive, but this is exactly why rotation modifier as part of the object tree is generally a good thing! There's no need to recompute a center because it's the same center, only a rotate operation has been applied on top of the node. Also, that's how rotation works in the web browser, which these design apps are often targeting.
- keyle 5y ago
  That would mean that these shapes get a common parent once rotated. And if you change the selection to include some but not all, and maybe some other shapes, and rotate, you'd create a many to many relationship? Maybe the appropriate choice here is grouping, like we see app use folders for these. That way you get what you're talking about and it's obvious to the user / it's based on their choice.
- shahar2k 5y ago
  I think you're mis-reading the situation the rotation of each individual shape isnt destructive (been following the author's work for a while, this is a vector based solution) what he's talking about is rotating multiple nodes at once around a common center, so each individual shape receives a new rotation but also a translation. as an artist who uses these kinds of tools, and someone who'se had to design easy to use interfaces, it's hard to convay "invariant center of mass" when the selection for multiple shapes usually involves drawing a screen aligned rectangle (which has a convenient and intuitive center point)

59 points by steveruizok 5y ago

>However, the rotated shapes probably have a different average center; which means that your second rotation (ie to rotate things back) is pivoting around a different point. And that's what causes the change of position. Uhh, what? Why doesn't the rotated group have the same centre as the original? The article glosses right over this without explaining it. Is it floating point imprecision? Is it from rasterization?

glenjamin 5y ago
I think it’s because the centre is computed using the X and Y axis, and the rotated shapes have a different bounding box on those axes.
- lainga 5y ago
  Why would you use bounding boxes for computing centres!
  - mooneater 5y ago
    Presumably for speed
    - ulber 5y ago
      More likely ease of implementation. The use case shown here is an interactive UI element, so performance isn't really a concern.
  - mkl 5y ago
    You probably already have xy bounding boxes for every element and the selection itself as it helps with selecting, drawing, etc., so using them is the easiest option.
  - bsder 5y ago
    Computational geometry is hard. Let's go shopping! If I'm being less un-charitable, the reason is that this bug is way down the list of priorities and fixing it with a proper solution is a lot of code and work that won't result in any new revenue.
deleted 5y ago
[deleted]
a_e_k 5y ago
I'd wondered that as well. Playing with tldraw and excalidraw, it looks like it's using the center of the bounding box as the pivot point. Suppose that you have three boxes like this: * - - - * . . . * - - - * | | | | | | | | | | | | * - - - * * - - - * . . . @ . . . . * - - - * . | | . | | . | | . . . . . . . . * - - - * The pivot for rotating them will be at the @ in the center of the bounding box around the three. If you then turn that counterclockwise by 45 degrees: . . . . . . . . . * . . . . . . . . . . / \ . . / \ . . * * . . \ / . . \ / . . * @ * . . / \ / \ . . / \ / \ . * * * * . \ / \ / . . \ / \ / . . . . * . . . . . . . . . . . * . . . then the center of the bounding box has now moved towards the corner of what was originally the upper right square (because there isn't a fourth square to complete the symmetry and push the bottom of the box around the three squares down). Rotating again will now pivot around this new point rather than the original and a rotation 45 degrees clockwise back to the original angle will now have shifted the boxes. Honestly, I'd think the correct solution here would be to pivot around the center-of-mass or some other rotationally-invariant point.
- kingcharles 5y ago
  Forget the article, I'm more impressed by your ASCII art.
- iainmerrick 5y ago
  The bounding box is the natural implementation because it matches what the user sees -- when you select multiple objects, the rotation handle is at the corner, because where else would it be? Plus it’s very easy to code and to test. But yeah, using a rotationally-invariant point would be better than the stateful fix the article goes for. Center-of-mass would make sense except it might do strange things if you have a mix of solid shapes and lines. How much mass should the lines have? Using the centre of the bounding circle is probably best, as others in this discussion have suggested.

conradludgate 5y ago

I think instead of the center of the bounding box, I'd instead use the average center of each selected item. Each primitive will have a rotation agnostic invariant center relative to its location, so the average of those will always be invariant

xvedejas 5y ago

There should also be strategies for the choice of center to be invariant even after re-selecting the rotated set of shapes. You should be able to do this by finding the two points farthest from each other, and choosing the midpoint between the two, for instance. But that point might not be unique, so maybe finding the center of the smallest circle enclosing all objects would be a better example?

etaioinshrdlu 5y ago
I ran into this problem in my app and found that rotating around the center of the bounding circle instead of the bounding box was a suitable solution.
- shahar2k 5y ago
  as someone who works with vector drawings often I would say that's unintuitive simply because the selection highlights are usually rectangular... there are many cases (lets say 3 objects in a triangle) where if you show a rectangular selection the rotation "center" will then be quite off the intuitive center
- mkl 5y ago
  Good idea. It seems more expensive to compute, especially for curves and pen stroke elements. Did you have any problems along those lines?
  - kingcharles 5y ago
    More expensive to compute? I guess technically, but I don't think you could ever measure or see the difference without running a debugger.
    - mkl 5y ago
      If you have a page full of writing, all sorts of things get slow. I do a lot of digital writing, and have encountered a number of strange slowdowns, even in apps designed for the purpose. In particular, selecting a large number of strokes can be quite a problem. There are minimum bounding circle algorithms that are O(n) where n is the number of points, but n can get big enough that you may not want to be doing that in an interactive program. You can put objects in a quadtree or similar to look them up quickly, and that may let you discard entire strokes in e.g. Welzl's bounding circle algorithm, but with stroke or curve data you'll still need to search along each one somehow for the extreme points by whatever measure you're using (and a Bezier curve has uncountably infinitely many points, so maybe you can only find an approximate bounding circle?).

phrz 5y ago

The author treats this kind of destructive rotation as a positive, but this is exactly why rotation modifier as part of the object tree is generally a good thing! There's no need to recompute a center because it's the same center, only a rotate operation has been applied on top of the node. Also, that's how rotation works in the web browser, which these design apps are often targeting.

keyle 5y ago
That would mean that these shapes get a common parent once rotated. And if you change the selection to include some but not all, and maybe some other shapes, and rotate, you'd create a many to many relationship? Maybe the appropriate choice here is grouping, like we see app use folders for these. That way you get what you're talking about and it's obvious to the user / it's based on their choice.
shahar2k 5y ago
I think you're mis-reading the situation the rotation of each individual shape isnt destructive (been following the author's work for a while, this is a vector based solution) what he's talking about is rotating multiple nodes at once around a common center, so each individual shape receives a new rotation but also a translation. as an artist who uses these kinds of tools, and someone who'se had to design easy to use interfaces, it's hard to convay "invariant center of mass" when the selection for multiple shapes usually involves drawing a screen aligned rectangle (which has a convenient and intuitive center point)