Simple Fix For "Look Rotation Viewing Vector Is Zero"

[Bunny83]

@unity_3KAIcHNkHzTZvw

Either live with the performance cost of the console error (which is massive, don’t do this), or go through the mild inconvenience of writing a wrapper for LookRotation that includes checking for Vector3.zero and decides what to do about it in a way appropriate to your use-case. Local functions are good for this, as the use-cases are usually highly specific.

Exactly. Funny enough that if you actually look at the OPs solution, it’s not really about fixing “the error” but to provide a resting direction and as we can see, it’s not the identity rotation but he wants to face to the right.

This condition btw looks like it makes no sense:

 if(axisCombined >= 0.1f || axisCombined <= 0.1f)

and yes, under normal circumstances this makes absolutely no sense. However it’s an implicit NaN check. So this is essentially a hacky solution to exclude the case where both input axis are 0 (because he does axisCombined = axisY / axisX;). That’s really an ugly and obfuscated solution which I would never want to use.

@tcz8

I’m saying it should just default to Quaternion.Indentity when it sees a Vector3.zero instead of complaining about it.

What exactly makes the identity rotation the right return value? Keep in mind this rotation is used as an absolute rotation. So just using identity could be a solution, but it won’t necessarily fit every problem. Actually it rarely would. As I just said, it wouldn’t even be a solution in the original post.

Errors and warnings are your friends. The compiler / CPU / computer does not know your intention and what you need that value for. However if you give it an impossible task, he should complain about it and not make up some answer as it sees fits.

Note in case of Vector3.Normalize which returns Vector3.zero if the vector is too small to normalize, this makes more sense for two reasons: Checking if an error occured can still be done because properly normalized vectors are never 0. So the “error state” is preserved and proper context specific error handling can be done afterwards. Also in case of normalization, when the input vector is almost 0 and in essence doesn’t have a direction that is to be preserved, it makes sense to just “round” it to 0 because the information is already / or about to get lost.

By returning the identity rotation you could not distinguish between a valid rotation or an error afterwards without looking at the input. When you suddenly return the identity rotation the orientation would most likely snap to a completely different direction unless you happened to look into the identity oritentation by accident. Computers should communicate user errors properly and the user should avoid them. That’s why System.Math.Acos returns an error (NaN) when you pass it a value that is outside the range -1 to 1. You could say it should just clamp the input so it always returns a valid angle, but the function simply is not defined outside the range and such a result would just be wrong.

[AllFatherGray1]

@unity_3KAIcHNkHzTZvw

I think it’s more like ‘2022 and some folk still can’t tell a bug from a feature’. You can’t get a rotation from zero - there is nowhere to face, and nothing for the code to conjure a Quaternion from as the only reference point you give it is the relevant direction - which is somehow where the observer is stood. Try and look in the direction of the focal point of your own eyeball and tell me which way you’re facing; I can’t manage it but something tells me it’s tricky.

Either live with the performance cost of the console error (which is massive, don’t do this), or go through the mild inconvenience of writing a wrapper for LookRotation that includes checking for Vector3.zero and decides what to do about it in a way appropriate to your use-case. Local functions are good for this, as the use-cases are usually highly specific.

The method is in the unity dll so I can’t rewrite it and add a wrapper. Also, no, I don’t mind "mild inconveniences, I do this full-time. It’d just be nice if I could select to disable the logs.

[unity_3KAIcHNkHzTZvw]

@AllFatherGray_1

so I can’t … add a wrapper

An accessible method that takes the same inputs, provides the same outputs, and has a catch for look direction of zero - that’s as difficult as this needs to be; but it does NEED to be that difficult because it is impossible to find any angle between two points when those points are the same.

public static Quaternion LookRotation( Vector3 fwd, Vector3 up ) { return fwd == Vector3.zero ? Quaternion.identity : Quaternion.LookRotation(fwd,up); }

[jitterware]

I have tried to use the following code:

rot = (vectorChange.Equals(Vector3.zero)) ? Quaternion.identity : Quaternion.LookRotation(vectorChange, Vector3.up);

But I still got the error. So I changed the code to the following and the error went away:

rot = (vectorChange.sqrMagnitude < GlobalDef.EPSILON_SQR) ? Quaternion.identity : Quaternion.LookRotation(vectorChange, Vector3.up);

In case you’re wondering, the value GlobalDef.EPSILON_SQR = 0.0001f;

[halley]

@jitterware

vectorChange.Equals(Vector3.zero)

From the docs: https://docs.unity3d.com/ScriptReference/Vector3.Equals.html

Returns true if the given vector is exactly equal to this vector.

Due to floating point inaccuracies, this might return false for vectors which are essentially (but not exactly) equal. Use the == operator to test two vectors for approximate equality.

So using vectorChange == Vector3.zero is closer to your intent than .Equals(). Personally, I find a hidden epsilon to be repugnant and overloading == to gloss over the concept of floating point error to be one of Unity’s most annoying code smells. Your approach to use an explicit epsilon is the right way to go.