I think my title is misleading - Here is my basic question:
How can I go about tracking my objects rotation on any given axis (in my case Y) when I am trying to limit it to several complete rotations, such as 3 complete rotations in my case?
More detailed question:
This is an image to represent a “circular” texture on a plane, which should be able to rotate on its y axis 3 full rotations (1080 degrees would be 3 full rotations from far left to far right…) and when it hits either 1080 (max right turned) or 0 (max left turned) it should stop rotating the object and ignore users input until they start going back the other direction (all of which is controlled by touch input from the user).
Now in my scripting, I have a number (float) between 0 and 359.999999… that represents the direction in which this object can be facing, and when the object is touched by the user, it then takes the relative position of that touch, and once it starts moving it starts to rotate the object relatively with the touch.
Right now I can rotate the object infinitely with my finger. I created some code to help me keep track of the “rotation since start” but it won’t work right for me to clamp the rotation…let me explain:
- I get touch input, and take finger position and transform to viewport coordinates
- I take the viewport location of the touch, compared to the viewport location of the plane im rotating, and get an angle that comes out 0-360 to represent the fingers rotation from the “origin” of the plane.
- I then use that number - relatively - to rotate the object between 0-360 (well 359.9999 you get the idea) as the finger moves in a circle around the origin of that object.
- the “default rotation” I save as 540 (between 0 and 1080, 540 is midpoint) which will then either get added to, or subtracted from, with the amount of difference since we last added to 540, so it takes 540 + difference and that becomes the number I track for its overall rotation around the three turns.
so when doing this, I use debugging to show the values im coming up with as I turn the wheel, and what happens is, I start my finger say, 45 degrees “right” of the planes “top”, and then start draggin my finger down to 90 degrees right of the planes top, and the wheel will then have completed a 45 degree rotation (because it moves relatively, not snapping to the finger like lookat would do) and my float for its overall current rotation will show at about 599 or so (starts at 540, plus about 45-50 degrees because of the movement my fingers taken)…then the problem is that once my finger has rotated all the way back around and passes between 359.9999 (or close to) back to zero (the variable holding the rotation angle my touch is actually happening at) the math for my “overall rotation” variable gets messed up…
what its doing is:
-
checks with if statement whether or not our value has changed since we last checked (if our finger rotated more)
-
if it did rotate more, then do this code:
currentOverallRotation = currentOverallRotation + difference;
and difference is the amount since we last checked (last frame) which it has changed (can be positive or negative number depending which way our finger moves).
So it takes our starting “currentOverallRotation” (which is 540) and adds the difference, so in my previous example of my finger starting a touch thats at 45 degree angle (0 being pointing straight up for the physical gameobjects Y) that means when my finger moved to 90, we got the currentOverallRotation (540) plus the difference (about 45 more degrees) and get about 585ish out, but when that same finger (still touching down) moves more in the same clockwise direction, and passes over the very top of the plane circle, the math says "currentOverallRotation (now about 540 + 350ish) plus the difference (which now becomes vastly different, it was just close to 359 and became near 0) which causes it to be crazy numbers near 360 in difference from the last number.
SO yeah if you can follow me, I need to little bit of code to consider that when it passes clockwise over the peak of the rotation, take whatever number its giving me, plus like - an extra number for how much we crossed over on our way around to hitting zero again… if that makes sense and uh, I suppose if it comes around from the 0 into 359ish the same problem happens, just gotta reverse the math for that I suppose…
Does anyone have experience fighting this simple math issue with rotation tracking over multiple complete spins on an axis? Help me out then