Hi there
I have a character that is walking around and I need to implement robust wall collisions.
The character should hit walls and slide along them.
To do this, I am using spherecast, but I have found a large problem.
It seems that spherecast ignores collisions that lie within the origin sphere. I have performed tests and it definitely is the case.
There is another function, CheckSphere which I thought I could use, but it does not give any detailed collision information and even if it did, why perform two costly collision functions when spherecast should already give me that info. Grrr!
Is it a bug/oversight? Or is there some reason for this strange behaviour?
Cheers
P.S. On a nitpicky note, why does SphereCast and CapsuleCast have capital Cs whereas Raycast and Linecast do not?
There are a number of ways to get around such limitations. Don’t be super shy about using additional physics checks (raycasts) when you need precision, it’s sometimes the only way. It’s unrelated here, but do note that you can affect precision by changing rigidbody interpolate and collision detection methods, and by changing the physics timestep or solver iterations.
When I need additional precision like this, I start breaking out additional checks. When performance is critical, it can be tough to optimize when and where additional checks are needed, but code yourself a working prototype before you worry about that too much. You can try having a smaller spherecast radius which is much less likely to lie within an existing collision, for one thing. If that’s not affecting your results, you should use raycasts of meaningful lengths and directions to increase your likelihood of catching collisions. Keep in mind that if you correct your player’s position and orientation before leaving Update(), they’ll be none the wiser that you did all sorts of meddling with their avatar.
And to answer your question, I don’t think that spherecast issue is a bug, but I agree it’d be neat to have an override that would achieve the behavior you expected. (I expected it too!) 
Hi AlwaysSunny
Thanks for the reply. The problem is that I am working on a huge game (near deadline) and I am trying to optimise sombody else’s code. We are CPU bound so I don’t want to add more expensive raycasts.
If it’s not a bug, then it was a very poor design decision. I can’t see the point of returning collisions in a CAPSULE-SPHERE shape only. I have since seen various other people complaining about this behaviour. I kinda understand the thinking in a theoretical sense, but pragmatically, it is of little use.
I also looked into Physics.OverlapSphere, but just like Physics.CheckSphere, it doesnt return collision data. I guess the desired functionality will make it in someday, but it will be too late for my current project.
I kinda got my stuff working by first subtracting velocity from position and then multiplying velocity by 2 (to avoid false negatives due to floating point precision).
This by itself worked in most situations, but there were cases like crevices where it would fail.
Finally I have to do another raycast from actual position to position+modified velocity to see if there is another intersection, and simply dont move if there is. This causes stickiness and slight flickering in some situations, but it is the best workaround I could come up with. If only spherecast returned all intersections, the code would be really simple, clean, precise and fast.
It’s frustrating to have to jump through code hoops to get something as simple and ubiquitous as wall sliding working.
Grrr!