[rmodels] Fix GetRayCollisionSphere() hitting spheres behind the ray

[Ne0nWinds]

GetRayCollisionSphere() would set hit to true, even if the sphere is behind the ray.

Simple test case that would fail:

Ray ray;
ray.position = (Vector3){ 0, 0, 0 };

// point ray in positive x-direction
ray.direction = (Vector3){ 1, 0, 0 };

// place sphere behind ray
Vector3 spherePosition = { -10, 0, 0 };
float sphereRadius = 1.0f;

RayCollision rc = GetRayCollisionSphere(ray, spherePosition, sphereRadius);
// rc.hit is true, but it should be false
// rc.distance is -11

hit was set based on the discriminant (d >= 0.0f), which only tells us whether the line the ray sits on intersects the sphere. It doesn't determine if it's in front of or behind the ray.

The fix is to check if the signed distance from the ray origin is greater than or equal to zero. This checks that the collision point with the sphere is in front of ray and not behind it.

[Ne0nWinds]

I discovered something while testing my PR a bit: if the ray's line completely misses the sphere, the distance, point, and normal fields of the RayCollision struct get filled with NaNs. This comes from passing a negative value into sqrtf.

This is not an issue for my PR, as it still sets the hit field correctly, and the user can still check hit before reading the other fields.

However, my question to @raysan5, should I add a fix for this? The fix is simple: I could return early if d is less than zero. Does NaN make sense as a no collision value, or should I early return a zeroed out RayCollision struct?

Looking at GetRayCollisionTriangle, I believe it also early returns with a zeroed out struct on miss.

[raysan5]

@Ne0nWinds good catch, thanks for the review

Definitely returning a zeeroed struct will be desirable but please, avoid an early return if possible.

[Ne0nWinds]

Okay, pushed up a new commit. I restructured the conditionals so that it always returns a zeroed struct when the ray misses the sphere

The diff looks more confusing, but I kept all the arithmetic the same. Only the error handling is different.

[raysan5]

@Ne0nWinds thanks!