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:
As said up until I stumbled with the problem, the point retrieved is exactly the same:
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):
to state (how the point difference does NOT produce):
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:
