#collision detection on corners
1 messages · Page 1 of 1 (latest)
for example even if I hit the edge exactly like this, I am clearly hitting the blue side of this corner
You are hitting the corner
that circle is STILL clearly more on the blue side
Why does that matter at all, it's the corner that is being hit
it could be close to another object but it's not hitting it is it
you may need to do some manual checking using the center of the circle then
I also do not believe I am even hitting that vertex at all because that would have to be very precise and this behavior is way too easy to replicate for it to be hitting the exact edge every time
Show an actual shot of it in the game with rays drawn
I mean I don't see why unity would calculate physics in terms of "edges" which aren't even physically real instead of faces
edges are just as real as faces
They are both constructed out of vertices and indices
here is an example from earlier today, my velocity is yellow and it gives me the green as the normal even though it should be hte light green
and as you can see it knows im not hitting the corner perfectly evenly
it is very heavily biased towards the actual face
not just the pure edge
and I think this is just how this particualr method calculates it I guess
I just want to know if normal unity physics does this too, or if it can actually tell me a FACE that I hit, a triangle, whenever I contact something
because if there are multiple answers to "which triangle did I contact first" then like... I have no idea how I'm supposed to work with that
I mean maybe if you hit an inverted corner with a perfect angle but that's not what is happening here
if this is the same method that normal physics uses, I basically have no reason to mess with rigidbodies
it would be simpler to fix this in my existing code rather than add rigidbodies and then have the exact same issue
edges don't have a normal though so I don't understand how you could actually "contact" one in any logical way
Either it's the average of the normals involved in the collision, it's the inverse of the face normal that contacted the other surface, or something similar. I would have to test to see what it actually is, I can't find docs easily
https://docs.unity3d.com/ScriptReference/ControllerColliderHit-normal.html
Note: When the CharacterController is colliding with an edge or a corner rather than a flat surface, the reported normal may be different when colliding with BoxColliders than when colliding with MeshColliders. This is due to a limitation in how PhysX handles Capsule/BoxCollider collisions.
that is the issue im having there
and what im asking is
is this universal to any collision detection in PhysX
or is this just this method
because if it's universal, I don't really have a reason to do anything with rigidbodies
I imagine it's universal, but different shapes may report things differently
this is ECS Physics
PhysX may work the same way, but I have no idea
weird, because the docs say its due to a PhysX thing
that this method works like this
If you are hitting box collider it should be relatively easy to deduce what dominant face you are closer to to choose face normal.
that's what I was thinking and why I don't understand how Unity can get the normal wrong
I mean technically it's not a box collider it's a mesh collider
but it's still just two faces at a right angle
and I COULD potentially determine it like this
but that method doesn't GIVE me the faces, or the edge
it gives me a point, and a normal which isn't accurate
why not perform some raycasts around the point
which point?
the contact point
where would I raycast to?
are you syaing like
compare the angle of a cast from contact to center of capsule to the normals of each face
because that would work, except the method does not give me the faces involved
just raycasting from center of your object to box collider will get you your normal
I need the normal of the face I contacted
and I'm defining which face I contacted, since it doesn't know I guess, as which side of the orange line the centerpoint falls on
from contact + normal * distance in Quaternion.AngleAxis(+-1, Vector3.up) * -normal or something 🤷
which I probably COULD get from the normals of the faces and a ray from the center of the capsule to the contact point, IF I had the normals to compare it to
I don't understand the math going on here
contact is the point, what is normal
the contact normal.
it doesn't give me that information
or well, it gives a "normal" but it isn't accurate
Hence why you are raycasting, to find the faces next to it
If these are primitives, just raycasting from one to another should be quite sufficient I think
I think that would have issues if the corner itself was particularly thin
hence why you offset the rays by a very small amount
and you can perform checks to see if the rays didn't hit where you might expect
some basic validation
if the sharpness of the corner is as sharp as the angle of the casts it could hit something else instead
I feel like there should be a proper way to get the triangles
because if you are hitting the edge, there is a finite set of triangles in the mesh that correspond to that edge
I could try reversing the normal and using that to raycast...
Do you have a mix of box colliders and mesh colliders?
the player is a capsule collider and the level is a mesh collider
And it's mesh collider returning "normal" of the edge?
it's returning a very weird vector
You don't even have to rotate it, you could also just offset it by Vector3.Cross(Vector3.up, normal) and the negative of that, by a very small amount
I think I have something I can try though
I can try using the normal times -1 as a raycast
to get a triangle
and just hope it consistently returns the triangle of the dominant face
like it would still be going into the edge, but I have usually had pretty good results with raycasting
If you want a visualisation on what the normals look like when an object hits something else, it does look like on the edges it's a similar approach to Unity Physics (ECS physics)
(these are similar to the normals returned by a straightup SphereCast, which isn't unexpected)
so I used the reverse normal method, but it's hitting the wrong triangle...