SphereCastAll returns hits with incorrect positions

I'm doing SphereCastAll() against some mesh colliders, and in addition to getting strange collision normals some times, the RaycastHit.point of the hit info is 0,0,0 even though that is not where the collision actually occurred.

Any ideas why the "point" where the hit occurred would be set to 0,0,0 when that isn't even close to the actual location of the collision?

 

CastAlls seem buggy at the moment.

For example, when I start my cast inside a collider, it for some reason remembers its previous hit. This is in version 5.0 and still have in 5.2.1

Spoiler: Click for video

The code used in that video was just this...

Spoiler: Click for code

Code (CSharp):

1. using UnityEngine;
2.  
3. public class DoCast : MonoBehaviour
4. {
5.     public Transform target;
6.  
7.     void Update()
8.     {
9.         RaycastHit[] hitInfos = Physics.SphereCastAll(transform.position, .5f, target.position - transform.position, 100f);
10.         Debug.Log(hitInfos.Length);
11.  
12.         if(hitInfos.Length > 0)
13.         {
14.             for(int i = 0; i < hitInfos.Length; i++)
15.             {
16.                 Debug.DrawLine(transform.position, hitInfos[i].point);
17.             }
18.         }
19.     }
20. }

I posted a bug report in 5.0, but I guess they didnt get to it yet or maybe they saw someone else report it. Or maybe I am doing something wrong.

As for the normals, spherecasts normals give a different normal. You can see it here http://forum.unity3d.com/threads/fo...erpolate-normals-when-hitting-an-edge.326217/

 

Thanks. Yeah, there definitely appear to be some bugs. The normals described on the page you linked, however, would be correct in my case. What I'm seeing doesn't merely appear to be interpolated normals between two faces, but rather normals which appear at odds with the faces in question. For example, I may have a shallow, glancing collision right in the middle of a face, and the normal of the collision points back in the direction from which the sphere came, as if the face were perfectly perpendicular to the sphere, which it most certainly is not.

 

See 5.3 latest release notes for how this will be handled from 5.3 onward.

 

Hi,

The fix for "(689159) - Physics: Fixed Sphere-cast error against scaled non-convex meshes" recently got backported to 5.2.2p2

 

Thanks, guys. Between these two things, that might answer both of my questions. I'm going to try p2 and see if it resolves the bad normals issue I was experiencing.

 

I am not sure if this was in reply to the bug I was talking about in my reply above, but I just downloaded 5.2.2p3 and the bug I was having is still happening, just as shown in the video above with the code above.

I posted the bug report a while ago before I really understood what was going on.

It seems the castAlls are remembering their previous hit position possibly due to the array of hits being stored on the c++ side and not being cleared properly. Even if I stop playing and press play again, it still remembers the previous position it hit as long as I am starting the castAll inside a collider (in this case, a box collider).

Here is the project that I used to make the video above in my previous post.
Just press play and move the sphere. You will notice there are 2 rays being drawn. If you disable the box object, there will be only 1 ray drawn. You can also look at the debug logs to see the amount of hits being detected.
The sphere is the target, and inside the box is the start of the cast.

This bug makes castAlls useless since they are now unreliable. It doesnt seem to happen with raycastalls though, just sphere and capsule castAlls.

Edit - also, it seems mesh colliders (and possibly other colliders) on uniformly scaled objects seem to cause problems with sphere casts (and possibly other casts / collision detect methods), at least when the scale is very large, such as 2k. I spent a lot of time trying to debug something, only to realize that when I just created the giant object in blender and exported with a uniform scale of 1, my issues were gone. This is in 5.2.2p3 as well.
Ive read about non uniform scaled objects causing issues, but I didnt know about uniformly scaled as well.
Live n learn =), thats the last time I touch the scale on objects with colliders ;/

 

@HiddenMonk thanks! I'll relay it to QA.

 

I am using unity 5.2.2p3, and I am noticing that my SphereCast against a non scaled convex mesh collider placed on a model I built in blender is causing wrong hit points.
(It seems fine on a primitive cube. Also, I think rotating my mesh model also causes some changes in the hit detection)

Here is a video showing what I mean.

Spoiler: Click for video

Ill paste the package here. The code used was just this...

Spoiler: Click for code

Code (CSharp):

1. using System;
2. using UnityEngine;
3.  
4. public class TestSphereCastConvexCollider : MonoBehaviour
5. {
6.     public float sphereCastRadius = .01f;
7.  
8.     void Update()
9.     {
10.         transform.localScale = Vector3.one * (sphereCastRadius * 2f);
11.  
12.         Debug.DrawRay(transform.position, transform.forward * 100);
13.  
14.         RaycastHit hitInfo;
15.         if(Physics.SphereCast(transform.position, sphereCastRadius, transform.forward, out hitInfo, 100))
16.         {
17.             Debug.Log("Hit found at - " + hitInfo.point + " - Normal - " + hitInfo.normal);
18.             Debug.DrawRay(hitInfo.point, Vector3.up, Color.red);
19.             Debug.DrawRay(hitInfo.point, hitInfo.normal, Color.blue);
20.         }else{
21.             Debug.Log("No Hit Found");
22.         }
23.     }
24. }

Should I make a bug report, or would it be better/faster for you @MortenSkaaning to let the guys that were working on this to try and fix it before 5.3? I noticed in the 5.3 bug fixes it said you guys fixed that previous bug I stated above in a previous post, which is pretty dam fast compared to when I posted a bug report for it a few months ago. I'm assuming it getting fixed that fast was your doing ^_^

This bug is causing me lots of issues. I didnt notice it at first since I was just working with non convex, but then realized my collision system wasnt working because overlapsphere doesnt detect a non convex collider if its fully inside, but it does detect convex. So I turned on convex and then I got other issues which lead me to finding this bug. I am using small spherecasts very close to colliders, so this inaccuracy causes major problems. I might be able to use multiple raycasts instead (and probably will have to in the meantime), but fingers crossed this gets fixed and released within the week =)

 

@HiddenMonk, please file a bug. We would need dedicated for for it.

 

I issued the bug report

 

thanks

 

Any updates on this bug? I seem to be getting it on 5.3.4p1! This is a massive issue for us.

 

Still getting it on 5.3.4p6 :< My whole combat system relied on castAll, guess I'll have to find a dirty workaround.

 

For those claiming the bug is still there, there were a few bugs talked about in this thread so its unclear as to what your issue might be. If its related to a bug I posted in regards to the cast starting within a collider, I think the fix unity decided to do was if it starts in a collider, it would still return a raycasthit, but the hitpoint would be vector3.zero.
I think they do this now for all castalls that had this issue (boxcastall, capsulecastall, spherecastall).
If you look at the docs linked below, you will see them talking about that.

"For colliders that overlap the sphere at the start of the sweep, the output direction is set opposite to the direction of the sweep, distance is set to zero as well as zero vector gets returned in the position field of the RaycastHit structure. You might want to check whether this is the case in your particular query and perform additional queries to refine the result."

http://docs.unity3d.com/ScriptReference/Physics.SphereCastAll.html