# 2D object rotations flip (configurable joint fixed angle)

Hello I have been trying to figure this out myself for the past few weeks but am pretty stuck. My math is a bit limited I’m afraid. I’m having trouble understanding the rotations for objects that are constrained using a configurable joint, it seems they “flip” at certain angles.

For an example, see this example of a simple turret that uses lookAt to track the mouse:

http://www.distortions.com/unity/2dAngleHelp.html

The turret has fixed angles on the Y and Z axis using a configurable joint, so when I rotate I would expect to get a (euler) 0-360 rotation on X. What happens instead is X goes from 0 to 90, then the Y and Z swap 90 and 270, then the numbers goes from 90 down to 0, and the Y and Z flip again. Kind of hard for me to explain, but you can see in this example if you rotate around the numbers “flip” or jump at the 12 and 6 o’clock positions.

I seem to have this trouble whether the objects are being set using LookAt or just being tossed around by physics.

A few days ago I thought I solved it all by doing some 2D calculations (thanks to Google) and wrote a 2D lookAt function to set the X angle manually to 0-360. This works great on my turret, except I’ve reached the point where I need to compare this object to physics objects’ angles now, and the numbers are different since they are flipping… So now I’m back where I was.

Does anyone know how to prevent this in Unity? Or is there some math I can use on the flipped numbers to get a 0-360 angle on the X axis? How can I compare differences of angles in “2D” if all of angles are flipping like that. Ideally all my objects would have Y and Z rotations of 0, and the X goes 0-360.

Any help would be greatly appreciated!

This is almost certainly to do with a cross product somewhere (Vector3.Cross), but without seeing your code it is difficult to say what is causing the problem. Is there any chance you could post what you are using?

The cross product combines two vectors to create a third vector perpendicular to them both. If you imagine the two initial vectors as the hands of a clock, then the product will be a vector pointing out from the centre of the clock or into through the centre depending on the angle formed between the hour and minute hand. This is a common way to find the axis of rotation between two vectors, but you need to be careful, since the product flips direction when the angle between the first and second vector goes above 180º.

andeeee, Thanks for that info. I will look into dot products a bit more, and see if that leads to a solution.

Here is the source to my test app, which I’ve added a 2d constrained physics object you can drag around, and that seems to work fine! (unlike what I said in my original post, so that’s good at least). But the problem remains on the turret’s angles.

So it seems like it is caused by using lookAt (Check the script TurretLookAt.js). Also, for easier reference here’s my code that causes the problem:

``````function Update () {

// find the 3d position under the mouse
var p = mainCamera.ScreenToWorldPoint (Vector3 (Input.mousePosition.x,Input.mousePosition.y,-mainCamera.transform.position.z));
p.z = transform.position.z; // flatten out the 3dness, so that LookAt comes out "2D"
MouseIndicator.transform.position = p; // move the mouse indicator GameObject

transform.LookAt(MouseIndicator.transform.position, Vector3.forward);	// make turret look at mouseIndicator

}
``````

Also, I was tweaking and changing axis around a little bit and I changed the problem, in this example they flip from x,90,90 to x,270,270! They used to flip x,90,270 to x,270,90… sigh yeah, I got problems

(Sunday Bump)

Anyone have any ideas why my lookAt causes the rotations to “flip”? I’m about to implement a hacky-workaround, by parenting two objects, at the top and bottom, and use my 2D angle function to figure out the angle based on their positions. But that’s definitely the hard/wrong way of doing it

I don’t think that having a parent object and rotating it is such a bad approach, actually. Joints are really supposed to be controlled by physics - if you move an object with a joint kinematically (by setting the transform) then it could well cause the error you are seeing.