Misleading Raycast Results: How to know for sure the object will collide with another?

Unity Engine
1

Hey everyone.

I’ve been breaking my head trying to solve this problem for a while now, without any good.
I’m developing a 3D pool game where, before the cue hits the white ball, I’m supposed to show a prediction of where the ball is heading to, which is the first impact and where each object will go after the collision (the white ball and the other ball. If its a wall, I just show the white ball’s direction).
Should be simple, right?

Well. With spherecast, the resulting normal vector sometimes ends up wrong, since Spherecast creates a somehow weird polygon that contains the sphere. If the spherecast is on the same size as the sphere, it contains the sphere completely, but has some extra volume. If the spherecast is 91% of the original sphere size, it’s completely contained in the sphere, but part of the sphere won’t be taken in the collision check, thus misleading information that it won’t hit when it actually does.

As spherecast wasn’t working well for me, I decided to move to raycast. Since all spheres are in the same height, I should be able to consider them circles. Thus, I take three points in the surface of that circle by rotating the radius vector: the point with the same angle as the direction vector (the forward point) and the two extremes (opposite 90º points from the direction vector, right point and left point). From those three points, I raycast towards the movement direction. That way I should be able to know for sure if there is going to be a collision and which side will hit first. I take the side that has the smaller distance towards the collision point and, together with the forward point, calculate a new point between them. Then I compare those three raycasts and reiterate. I set up an angle precision limit of 0.1. Should work, right? Theoretically I would be 100% sure if the object would hit something along the way, which would be the first hit and a close enough collision point (by a 0.1º error margin).
Guess what?

In an ambient surrounded by colliders (walls), even when pointing towards other spheres, the raycasts return nothing. Some of them do. Some of them don’t. Some of them even collided with the white ball itself (even though they were cast from inside the collider, or was supposed to, at least). I used the Gizmos ray draw feature to check on the raycast on the 3D environment and it was CLEARLY going through couple colliders and it was still accusing no collision (distance = 0, collision point : (0,0,0) collider = null).
I’m really not sure how to deal with this. The prediction line is supposed to be updated every frame and should be light enough to work on mobile.

Any thoughts?
Any way to solve the raycast problem? Or to try getting more accuracy from spherecast?

(This problem happens in both Unity 5.6.0f1 and Unity 2017.4, where I tested.)

2

Hey everyone.
Its time for an update.

I’m now using Unity 2018.1.0f2 and the problem is still around. I’ve optimized the basic raycast solution (now it works without recursivity). Although, it shows the same error as the spherecast. It says that the white ball will hit, shows me a collision point and yet… the white ball shows no sign of caring about the ball it was supposed to hit.

[Video showing the collision line, with a preview of where the white ball will be when its supposed to hit, using Spherecast]
[The spherecast used here is at scale 1 not 0.91]

I’ve also tried lowering the fixed timestep as much as I could in order to make the physics simulation more accurate (accurate enough to not be able to run on a mobile device), but even so the white ball keeps missing the point.


[Time Configuration]


[Physics Configuration]

1159×160 16.2 KB

[Code used for debugging the Spherecast]

If anyone could try giving me a light here, it would be really appreciated.

TL;DR - Spherecast keeps saying the spheres will collide and (<>) they don’t. Trying to make the prediction accurate without overwriting PhysX. Help please. It’s been two months. I have cookies.

Thanks for reading,
Shiaku

3

Do you use a continuous collision detection on the rigidbodies?

4

I use Continuous Dynamic, but I’ve tried swapping over to Discrete and Continuous. As expected, no changes.

5

The null collider is just a collision with self, you need to skip that one.
But you could also compute intersection by yourself, a ray / sphere intersection is trivial.

hj.

6

I am doing it, but apparently the reason it does not collide is that the ball never reaches the the exact position where it should collide (resulting in angles different than the calculated ones or no collision at all). PhysX only considers a collision when there’s overlapping, and if the ball speed is high enough to make the collision point be in the gap between two frames (what is very likely since its a very specific point), the collision won’t happen or will happen in a different point than predicted (specially if you are targeting a very small tangent), making the guide “imprecise”.

TL;DR - PhysX is trolling a lot.