quaternion validation

[ecosky]

Hi Norbo,

I recently encountered a problem where an orientation quaternion had valid numbers and wasn't failing validation, but the range they used were enough to cause problems later downstream. For instance, I had this: {X:-3.273159E+17 Y:-4.664622E+34 Z:1.334513E-40 W:1}, causing the LengthSquared() to return float.Infinity causing other problems later when the quaternion is used or normalized. I was wondering if perhaps it you would agree that the Quaternion.Validate() should also check the .LengthSquared() for Infinity, NaN and Zero? Or perhaps an epsilon test? Both seem to be invalid states for a quaternion.

This is what I did, for instance,

Code: Select all

        [Conditional("CHECKMATH")]
        public static void Validate(this Quaternion q)
        {
			if (IsInvalid(q.W) || IsInvalid(q.X) || IsInvalid(q.Y) || IsInvalid(q.Z))
            {
                throw new NotFiniteNumberException("Invalid value.");
            }
	        var len = q.LengthSquared();
			if (float.IsInfinity(len) || float.IsNaN(len) || len < 0.00001f)
			{
				throw new NotFiniteNumberException("Invalid value.");
			}
        }

Thanks,

[ecosky]

Just a quick follow up, I wound up adding the following checkers and used ValidateAngular for the angular vector3's in Entity and it helped to identify my code error.

Code: Select all

        [Conditional("CHECKMATH")]
        public static void ValidateRange(this Vector3 v, float range)
        {
			v.Validate();

			// Also check for sane range limits
			if (v.X < -range || v.X > range || v.Y < -range || v.Y > range || v.Z < -range || v.Z > range)
			{
				throw new ArithmeticException("Invalid value.");
			}
        }

	    private static float _angularVelocityValidationLimit = 10000;

        [Conditional("CHECKMATH")]
        public static void ValidateAngular(this Vector3 v)
        {
			v.ValidateRange(_angularVelocityValidationLimit);
        }

[Norbo]

The latest development fork now checks squared length for both vectors and quaternions. However, I am hesitant to add any additional fundamental behavior modifications to the already in-use Validate methods or to add built-in finite limits to inputs. For example, a quaternion with zero length (or any other non unit length) is technically still a valid quaternion, it just doesn't represent a simple orientation. Such quaternions are used within the context of the engine here and there.

[ecosky]

Thanks Norbo

I understand what you are saying about changing behavior. I expect the squared length solves the basic problem of values that will push things beyond limits of precision, however I do think it may be useful to have the max values be a tunable setting (default float.MaxValue) so people can dial down the range to something they know is legal for their use cases. Using a range check definitely helped me find some bugs today.