But, since I don’t trust myself enough if I get more than let say… 4 up-votes on this answer, and no “good reason” is provided, I WILL submit it as a bug. I have yet to get a good reason for this choice. (see Eric’s answer for the actual unity code.) Apparently, this is not a bug, it’s “by design”. Unity decided to change this universally accepted formula, such that arbitrarily “small” vectors return Vector3.zero when normalized. It is clearly defined, the same way, in all fields of math. Normalizing a Vector is a universally standard mathematical operation. (Never would have seen this without Owen’s help.)Īdditional FP computation details, and my moaning, remain, below. So, in order to be consistent with the unity definition of vector3 equality, but avoid extra operations, the normalize function checks the magnitude directly against the defined equality range. Though one CAN check the magnitude against the value 0.0f, we could equivalently express the conditional, as checking to see if the input vector is EQUAL to Vector3.zero. As an example, the normal operation will always need to check if the vector we are normalizing has a magnitude of zero, because Vector3.zero is the only invalid vector we can input, (and in order to avoid a divide by zero error). In order to maintain the consistency of this definition, it is necessary to specifically check against it, during some operations. Regardless of the purpose (optimization, help beginners, whatever…), this is now a mathematical definition. Unity defines Vector3 equality/equivilence using this class operator, Unity - Scripting API: Vector3.operator =, which states two vectors are equal if they fall within a certain range of each other. Unity Normalized Vector: vxN: 0 vyN: 0 vzN: 0 Vector (sanity check) vx: 5E-16 vy: 1E-16 vz: 0 Unity Normalized Vector: vxN: " + vecNorm.x.ToString() + " vyN: " + vecNorm.y.ToString() + " vzN: " + vecNorm.z.ToString()) Vector (sanity check) vx: " + vec.x.ToString() + " vy: " + vec.y.ToString() + " vz: " + vec.z.ToString()) My normalized vector xn: " + an.ToString() + " yn: " + bn.ToString() + " zn: " + cn.ToString() ) Xyz.magsqd: " + magsqd.ToString() + " xyz.mag: " + mag.ToString() ) I do see in the docs it explicitly states: “If this vector is too small to be normalized it will be set to zero.” but I really don’t know what “too small” is, nor why this should be the case. Do I really need to roll my own Vector3 TrulyNormalized(this Vector3 v) extension function? Should I submit this as a bug? OR - What am I misunderstanding / incorrectly-assuming? I could understand some loss of precision for the sake of performance, but this result is just plain wrong. At first I thought it was a precision issue, but when I tested it myself, as shown in the code below my normalized values are computed just fine, but Vector3.Normalize just returns Vector3.zero. I ran into this issue when trying to normalize a small vector.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |