I have made an attempt at creating a kinematic character controller using Blockcasts/Shapecasting. The issue is that, in some cases, the sweeps can be wildly incorrect/erroneous:
Context: The green box (collider) was above the blue part, yet the reported hit position (the red cube) is below the blue part and instead collides with the red part, despite the green part intersecting with the blue part
My solution to this problem was to use raycasts to verify a sweep and ensure that the result was valid. I simply fire a ray with a unit vector of 0, -1, 0 based on a clamped position to keep the origin of the ray within the size of the axis-aligned bounding box that I cast via Workspace:Blockcast(CFrame.new(position), size, direction)).
The green square represents the origin, while the red square represents RaycastResult.Position. It should be noted that this ray’s direction has a unit vector of 0, -1, 0. Yet, as seen in the console, the normal reports 0, 0, 1.
This is very easily reproducible:
Have two separate parts next to each other
Cast a ray where the position is directly in-between the two parts
The ray should return a normal where RaycastResult.Normal.Y > 0 (in this case, since the repro is casting onto a flat surface, RaycastResult.Normal == 1), as my ray is traveling with a unit vector of 0 -1, 0.
Thanks for the report! In the repro file you shared, the normal is (0, 0.707, 0.707) because the ray is hitting the edge of one of the blocks instead of the face. Unfortunately the raycast function doesn’t have the ability to tell if two parts are at the same distance and form a flat plane. Ways to fix this could be to join the parts, to use one larger part, or to move the parts slightly so they aren’t perfectly aligned with the ray. If this is a different issue than what’s happening in your video, could you share a new repro?
I will say that, as seen in the video, something as simple as flipping the Z from 0 to -0 suddenly made it work..? That inconsistency and the fact that the parts are just regular parts with all flat faces made me assume that the normals would all be reported as straight via the raycast. Is this really a (literal) edge case that I have to deal with, where hitting the edge directly will result in a diagonal normal?
Anyway, on closer look -
Yes, this is a separate issue. The video I showed in my own game is one where a seam in my carpet (which is composed of multiple parts rather than a union or something of that sort, I really do not like unions), when hit by a ray going down, results in a normal of 0, 0, 1 or 0, 0,- 1.
I have not a single clue what could be causing this one, so I’ve just created a repro where I slapped the carpet down and took some snippets of how I swept this and shoved it into the raycast repro.
Here’s the better repro that actually produces what I’m experiencing:
Sidenote, I still would appreciate some investigation into the other bug report I attached to a hyperlink in the OP. Blockcasts are kind of the bane of my existence at this very minute…
Hello, sorry for the delay. The new repro is still the same issue of rays hitting edges instead of faces. Right now theres no guarantee if this will return the normal of one face, the normal of the other face, or the normal in between. I’ve opened a ticket for looking into making this more deterministic and we’ll let you know when theres any updates. I’ll see if I can bump the status of your other shape casting issue internally.
Thank you for the response nevertheless.
This issue is the most confusing because in no world should I be returned a face with a normal of 0, 0, -1 or 0, 0, 1 when I am casting a ray straight downwards. I can understand the diagonal faces at the very least, but it looked like a separate issue because of that difference
