I have a system, in which I get a Vector3, which I use as a value to adjust the localEulerAngles of a transform.
This value is changed as I drag the mouse down.
The system works fine, the transforms rotates exactly as I want. However, the animation was not as smooth as I would like, so instead of the animation being slave only to drag, I introduced a system, which would use Update, and I would apply a Slerp, a Leap or MoveTowards; none of which work as desired and I am not sure why.
So, why would the same values I use here…
void handle_rtn(float power){
if (isRtn) {
//power will be between 0 and 1, where one will = extent, and 0 = default.
rtn_x_crnt = (rtn_x_extent - rtn_x_default) * power + rtn_x_default;
rtn_y_crnt = (rtn_y_extent - rtn_y_default) * power + rtn_y_default;
rtn_z_crnt = (rtn_z_extent - rtn_z_default) * power + rtn_z_default;
trgt_rtn = new Vector3 (rtn_x_crnt, rtn_y_crnt, rtn_z_crnt);
tf_unit.localEulerAngles = trgt_rtn;
}
}
…act very differently for here?
bool isLive;
void Update(){
isLive = UAMng.isLive;
if(isLive){
if (isRtn) {
Vector3 setRtn = Vector3.MoveTowards (tf_unit.localEulerAngles, trgt_rtn,1);
tf_unit.localEulerAngles = setRtn;
}
}
}
First of all, havent slept, that aside I don’t think any of those two choices should give good resoults. what’s the rotation for and what angles are going to be rotated, all three?
edit: oh and man complete the vrbl nms r ls non ll undtnd wt t hll u syn
You probably want to use Vector3.RotateTowards so the values are treated as angles and wrapped accordingly.
The answer, as ever, is because Euler angles are terrible. Once you learn to accept this as fact and get past it, your life will be much better. If you want the full explanation, here’s a link.
Euler angles are good for exactly one thing: For a human to input numerical rotation values. That’s the beginning and end of what they’re useful for (and, if you notice, that’s exactly where Unity uses them).
Specifically, the issue is the first parameter in line 7 of your second block of code. Retrieving .localEulerAngles will get numbers that are wildly unpredictable (though still valid) because Unity has to convert the Quaternion (the native language of a rotation) to Euler angles, and there are many valid Euler angles for any given rotation. Euler-to-Quaternion is reliable; quaternion-to-euler is not.
The good news is that you don’t need to actually understand Quaternions to use them; just use Unity’s Quaternion class, and avoid using Vector3’s to represent angles, and you should be fine. In this situation, if you’re not wild about changing your entire code right now, you should be able to get away with something like:
if (isRtn) {
Quaternion oldRot = transform.rotation;
Quaternion targetRot = Quaternion.Euler(trgt_rtn);
Quaternion newRot = Quaternion.Slerp(oldRot, targetRot, someValue);
transform.rotation = newRot;
}
In other words, convert everything to Quaternions before you attempt to manipulate rotations.