Controlling Direction of Rotation with Transition.to()

Audio and Graphics
#1

Hey all,

I have a ring with 12 equally-spaced symbols that the player will spin with their finger.  Once the “touch” is released, the ring must auto-correct to the angle on which the closest symbol is located - the marker/indicator is located at top-centre of screen.  I’m using Transition.to() to auto-correct the ring.

Everything is working great except the direction of the rotation seems to be somewhat random.  For example, if the closest symbol is located to the left of the marker/indicator, some times the ring will slowly rotate to the right (perfect!!).  But other times, under the same scenario, the damn thing will spin ~360 deg to the left - it still goes to the correct symbol but takes the long route and looks ugly.

I’ve done a bunch of testing and it seems like it only happens when I change the swipe direction AND cross the 0/360 degree angle.  I’m at a loss as to why this is happening tho.

Here’s the code that’s moving the ring:

--Move ring position of nearest symbol spinnerAngle = spinner.rotation % 360 local moveToAngle = NearestValue(anglesOfSymbols, spinnerAngle) if (moveToAngle == 360) then moveToAngle = 0 end transition.to( spinner, {rotation = moveToAngle} )

Note, my rotations are being normalized/modded to 360.

Any ideas?

Thanks.

#2

Well, transition.to() doesn’t have any built-in support for modular arithmetic, so going from 330+ degrees (or whatever) to 0 backward is the only reasonable thing for it to do, lacking further context.

Note that though you’ve done the mod, you’ve left spinner.rotation intact. You could probably assign to that before checking the nearest value. At that point you might even be able to avoid doing the  moveToAngle  correction. (Sounds good in my head, but untested.)

#3

You need to:

  1. Normalize the object rotation (i.e. clean up the object’s rotation to be in the range 0…359.999)

  2. Determine the target angle and convert it to a value +/- 180 degrees of current rotation.

  3. Set your target angle (transition.to( xxx, { rotation = …) to that.

  4. onComplete, clean up the object rotation again.

I have done this and know it works.  I don’t have the code readily available or I’d drop it here.  If you try to figure this out and are still stuck tomorrow, post back.  I’ll dig through my own code and find an example.  Super busy today though. :frowning:

#4

Thanks guys,

Both answers are correct; tried to choose both as the solution but apparently the forum gods forbid such recognition.  Chose the most complete and straightforward answer.

Because I wasn’t normalizing the actual spinner.rotation property but was moving to a normalized angle, I’m thinking wild spinning was the ring ‘unwinding’ back to the normalized angle.  

Normalizing to 359.999 was also a nice touch, though I never converted the target to +/- 180 and it works like a charm. 

#5

Well, transition.to() doesn’t have any built-in support for modular arithmetic, so going from 330+ degrees (or whatever) to 0 backward is the only reasonable thing for it to do, lacking further context.

Note that though you’ve done the mod, you’ve left spinner.rotation intact. You could probably assign to that before checking the nearest value. At that point you might even be able to avoid doing the  moveToAngle  correction. (Sounds good in my head, but untested.)

#6

You need to:

  1. Normalize the object rotation (i.e. clean up the object’s rotation to be in the range 0…359.999)

  2. Determine the target angle and convert it to a value +/- 180 degrees of current rotation.

  3. Set your target angle (transition.to( xxx, { rotation = …) to that.

  4. onComplete, clean up the object rotation again.

I have done this and know it works.  I don’t have the code readily available or I’d drop it here.  If you try to figure this out and are still stuck tomorrow, post back.  I’ll dig through my own code and find an example.  Super busy today though. :frowning:

#7

Thanks guys,

Both answers are correct; tried to choose both as the solution but apparently the forum gods forbid such recognition.  Chose the most complete and straightforward answer.

Because I wasn’t normalizing the actual spinner.rotation property but was moving to a normalized angle, I’m thinking wild spinning was the ring ‘unwinding’ back to the normalized angle.  

Normalizing to 359.999 was also a nice touch, though I never converted the target to +/- 180 and it works like a charm.