5 ms·

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 fin

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?).
- spankalee 5y ago
  How do you efficiently compute the bounding circle, especially in the presence of curves?
  - iainmerrick 5y ago
    Curves aren’t important in this scenario because the circle isn’t visible, it’s purely there to provide a consistent center of rotation. It doesn’t matter if it hugs the curves or not. This is the kind of thing where there are plenty of well-established algorithms (although there might not be a good off-the-shelf implementation in your language of choice). I doubt efficiency is going to be a problem unless you have many thousands of points.
    - mkl 5y ago
      Good point, but the centre of the circle is the important thing, and that is visible if you want good UX. It does matter that it consistently leaves out the same part of sticking-out curves in different rotations. You could sample some number of points along each curve or something. Many thousands of points is exactly what you have in a page of handwriting. They're organised into strokes, which should help.
      - tonyarkles 5y ago
        Just spit-balling here, but it seems to me that you could probably get away with just using the endpoints and maybe the control points. There might be some odd cases where this falls apart, but in general I suspect it would work pretty well and in the edge cases it probably wouldn't be too confusing; you'd still get a point to rotate around in the vicinity of the curve at the centre of a line between the endpoints. If you included the control points, it would still end up roughly close to the centre of the visual curve.
ssivark 5y ago
It should be easy enough to compute the "center of mass" (quite efficiently too, by considering a weighted average of component centers of mass recursively) for the objects, rather than something even more naive like the center of the bounding box. The former, being a sensible physical quantity is much more likely to be well-behaved under physical transformations.
- Someone 5y ago
  It is rotation invariant, so it behaves well under rotation, but I think it sometimes would give highly surprising/undesirable results. For example, the center of mass between earth and the sun is deep inside the sun, IIRC, so it would almost rotate around the sun. So, if you have the sun showing at the left of your screen, earth at the right, and rotate that pair over 180 degrees, the sun would stay put, and earth would move off-screen. You could auto-scroll to keep both on-screen, but I don’t think users would find either a good choice. In general, I think users would expect a rectangle with some parts cut out if it to keep the same bounds after a 180 degree rotation, or a circle with some parts after any rotation.
  - ssivark 5y ago
    Try drawing the two circles to the scale of the masses, and you’ll see how massive the sun actually is, relative to the earth :-)

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?).
spankalee 5y ago
How do you efficiently compute the bounding circle, especially in the presence of curves?
- iainmerrick 5y ago
  Curves aren’t important in this scenario because the circle isn’t visible, it’s purely there to provide a consistent center of rotation. It doesn’t matter if it hugs the curves or not. This is the kind of thing where there are plenty of well-established algorithms (although there might not be a good off-the-shelf implementation in your language of choice). I doubt efficiency is going to be a problem unless you have many thousands of points.
  - mkl 5y ago
    Good point, but the centre of the circle is the important thing, and that is visible if you want good UX. It does matter that it consistently leaves out the same part of sticking-out curves in different rotations. You could sample some number of points along each curve or something. Many thousands of points is exactly what you have in a page of handwriting. They're organised into strokes, which should help.
    - tonyarkles 5y ago
      Just spit-balling here, but it seems to me that you could probably get away with just using the endpoints and maybe the control points. There might be some odd cases where this falls apart, but in general I suspect it would work pretty well and in the edge cases it probably wouldn't be too confusing; you'd still get a point to rotate around in the vicinity of the curve at the centre of a line between the endpoints. If you included the control points, it would still end up roughly close to the centre of the visual curve.

ssivark 5y ago

It should be easy enough to compute the "center of mass" (quite efficiently too, by considering a weighted average of component centers of mass recursively) for the objects, rather than something even more naive like the center of the bounding box. The former, being a sensible physical quantity is much more likely to be well-behaved under physical transformations.

Someone 5y ago
It is rotation invariant, so it behaves well under rotation, but I think it sometimes would give highly surprising/undesirable results. For example, the center of mass between earth and the sun is deep inside the sun, IIRC, so it would almost rotate around the sun. So, if you have the sun showing at the left of your screen, earth at the right, and rotate that pair over 180 degrees, the sun would stay put, and earth would move off-screen. You could auto-scroll to keep both on-screen, but I don’t think users would find either a good choice. In general, I think users would expect a rectangle with some parts cut out if it to keep the same bounds after a 180 degree rotation, or a circle with some parts after any rotation.
- ssivark 5y ago
  Try drawing the two circles to the scale of the masses, and you’ll see how massive the sun actually is, relative to the earth :-)