Issue with Adding Quaternions

Hello everyone, I’ve managed to cause a value error when I attempt to add two Quaternions. This issue then creates a rotation problem when I feed that new Quaternion to a Slerp method.

In Detail:

Essentially, I’m getting values for a Vector3, making sure that the Z value is 0, then convert the Vector3 to a Quaternion. Then I multiply this new Quaternion with the current object’s rotation to get a new additive rotation target for the Slerp method.

But for some reason, when I debug the value of the current object rotation multiplied by the target Quaternion, the Z value is not 0. This non-zero Z value then throws of the rotation of the object because it gets fed into a Slerp method (that now has the wrong values).


targetPosition Z value is 0.

targetQuat Z value (as an euler angle) is 0.

But tempQuat (as an euler angle) has a non-0 Z value (and the object has no Z rotation of its own).

Any ideas as to why this is are greatly appreciated. Thank for reading.

Code Below:

	public void MoveCamera()
		targetPosition = analogInput.AnalogeStickMovementPercentage();
		targetPosition.z = 0f;
		Debug.Log ("targetPosition is: " + targetPosition); 

		targetQuat = Quaternion.Euler (targetPosition);
		Debug.Log ("targetQuat.eulerangles is: " + targetQuat.eulerAngles);

		Quaternion tempQuat = transform.rotation * targetQuat;
		Debug.Log ("tempQuat.eulerangles is: " + tempQuat.eulerAngles);

		transform.rotation = Quaternion.Slerp (transform.rotation, transform.rotation * targetQuat, cameraMovementSpeed * Time.deltaTime);

The euler angles reported by Unity is derived from the Quaternion. There are multiple euler representations for any given physical representation. For example, if you did the following:

 transform.eulerAngles = Vector3(180, 0, 0);

The Debug.Log() output is (0,180,180)…the same physical rotation represented differently. So the fact that ‘z’ is not zero is only an issue if at some other point in your code you are reading the ‘z’ from eulerAngles. As long as you treat eulerAngles as write-only, and don’t run into a gimble lock situation, things should work.

I guess what I’m saying is that, unless you are reading eulerAngles at some other point in the code, look beyond the non-zero z value for your problem.