Related to the edition of rotation via 2d gradients, i stumble upon a nice little logical issue: how to pick the shortest path form current value to target one when space is cyclic and not linear. Indeed, rotations are cyclic, PI and PI*3 are not the same angles, ok, but you end up at the same place with the 2 rotations. Therefore, the 2d picker i’ve developed must take this fact into account to smooth rotations.

In 50% of the cases, it is shorter to go the opposite direction! With a little image, it is much clearer.

Instinctively, a human would pick the shortest path around a circle. But when programming, it is much easier to consider rotation as a line from 0 to 2PI. And that’s precisely when all hell breaks loose! You now have to compute 2 distances between 2 points:

  • the classic one, on the line
  • the opposite way, looping from 0 to 1 and from 1 to 0

Once done, you just have to compare the 2 distances and pick the shortest one. It would be too simple if it was only that.

For the UI, i wanted to allow limitation of rotation (a range). It disturbed the computation of the shortest path, because the range is forcing usage of a smart way to pick the shortest path: it can not go throughs the forbidden values.

Here is an openprocessing implementation of the full process.