CODEWITHSUNDEEP
unity-game-enginecollision-detectioncollisionphysics-engine
rustyBucketBay
rustyBucketBay

Reputation: 4551

Mesh import settings refresh (ctrl + R) influence in raycastHit point calculation

Dont be scared of the question due to its lenght. In fact the problem is quite simple and interesting, and I believe that easy to follow along, but I wanted to explain it properly. Anyhow thanks for reading if you choose to do so :).

For irrelevant reasons I do the following, from a point retrieved from a raycast hit, I go a meter up, and throw another ray downwards, to get the point of the ground. See "Why I do this?" at the end for context, not relevant for the problem. Just to explain why would from a raycasthit point would it be that same point recalculated from another raycast.

For this case the point retrieved should be exactly the same. See in the code why does it makes sense that when throwing a raycast from above the exact same point some distance up, the exact same point should be retrieved, as the orgin point is retrieved with a raycast, the code is actually quite simple:

    if (Physics.Raycast(ray, out RaycastHit result1, maxDistance, mask, triggerInteraction))
    { 
        Debug.LogError($"main camera picked point: {result1.point.x:G9}, {result1.point.y:G9}, {result1.point.z:G9}");
        if (Physics.Raycast(result1.point + Vector3.up * 1, -Vector3.up, out RaycastHit result2, 32, mask))
        { 
            Debug.LogError($"1m up from above raycast point: {result2.point.x:G9}, {result2.point.y:G9}, {result2.point.z:G9}");
        }
        returnValue = true;
    }

First raycast retrives the world position and the second raycast from 1m above, throws a ray downwards. Take into account that it is the exact same point, as the origin is result1.point + Vector3.up * 1. Point with all the decimals is logged, so that is why I stress that it is the exact same point.

The thing is, that there is a surface where this does not happen and the decimals change. Like this:

enter image description here

As said up until I stumbled with the problem, the point retrieved is exactly the same:

enter image description here

Not a big deal reagarding precision, but I wonder why this happens. This surface has a mesh, that has normals, tangents etc. When I remove those in the mesh import settings, the problem is gone, and the retrieved point is the same. See screenshots of the settings.

from state: (how the point difference does produce):

enter image description here

to state (how the point difference does NOT produce):

enter image description here

What is the influence of the mesh normals in the raycasthit calculation?. Any resource where it can be checked how the raycast works under the hood?

Why I do this?

It is not relevant for the problem itself, but explaining it for context and to avoid unneccesary answers/comments. It is to move some points in a space path to the ground. The nodes (reference points where the path is retrieved from) of this path are already there, in the ground (thrown from the main camera to "pick" the world point with the raycast to define the path nodes). So I would not need to find the ground points of the nodes themselves, because they're already in the ground, but doing that needlessly because I was looping through all the path points I stumbled with this issue.

Thanks for reading.

Edit: Normals removed in the mesh import settings, as per unity docs advice : "Optimization tip: If a Mesh Collider only uses a Mesh, you can disable Normals in Import Settings, because the physics system doesn’t need them." However if I start the app with normals to none, and after set the import options + ctrl + R, y get a different point with normals to none, and the exact one after setting the normals import options. So seems it has to do more with the fact of option changing + recompile at runtime and the mesh cooking than specifically with the mesh normals.

Mesh shape image, with raycast from above direction red arrow:

enter image description here

Upvotes: 1

Views: 79

Answers (1)

derHugo
derHugo

Reputation: 90813

In general it is not at all guaranteed to hit at the same point!

Imagine the following (forgive my amazing paint skills ^^)

enter image description here

so in general your check makes little sense except you can always be 100% sure your second ray isn't accidentally being fired from the other side of the mesh.

This gets even worse with a Mesh that is not convex as you could easily being hitting a concave hole the first time and hit it from the outside the second time.

Another important question would be: Does your second raycast even hit the same object?

Debug.Assert(result1.collider == result2.collider, "Oh oh that could explain things");

Another reason in your case might be that the Mesh for the MeshCollider without the normals might be optimized for the physics differently than one with normals. The MeshCollider's shape is not 100% equal with the actual Mesh shape depending on the optimization settings ("cooking options").

Upvotes: 3

Related Questions