I describe the problem on the attached video, in summary it seems the sphereOverlap function is always hitting things and when trying to do multiple Raycasts on the same frame / code block they get overritten.
I Have uploaded the project feature in that video here: GitHub - orlax/Needle-Engine-Scene-Switching at physics-problems
is there something I am doing wrong? how could I help to solve this physics issue? my next steps are to go directly to Three.js level and do my physics checks there instead.
Original Post on Discord
by user 326444095130042368
@Marcel_Wiessler1 
if you can take a look at this, I would super super appreciate it.
by user 326444095130042368
Hey Orlando, I’ll take a look.
For debugging what you could do is drawing some gizmos to see what is actually hit and raycast. There are some methods available in the Gizmos class.
Out of curiousity: do you have a specific reason for testing collisions manually via raycasting instead of using the physics engine callbacks that we expose? (e.g. onCollisionEnter or onTriggerEnter)
The collision argument contains info about the collision which you could use to reset your objects position
Oh and for debugging you could also enable collider rendering using the ?showcolliders url query parameter
Let me know if that is already helpful
so the main reason is to not do things afterwards, so that we would move the player, detect a colission and then move him back. This is just the way I we are accostume to do things coming from game development.
I will check those gizmos classes and see what I find
by user 326444095130042368
well, I added some Gizmos to draw the raycasts and it seems to confirm what we are looking at here:
1 raycast works as expected
sphereOverlap is always returning hits
multipleRaycast behaves odly
by user 326444095130042368
this is a tiny sphereCast, in this case it is floating over the floor and the blue cube is set to ignore raycasts, even then it is always hitting other things and drawing in red. I have uploaded another commit adding this gizmos
by user 326444095130042368
Ah it’s quite possible that the IgnoreLaycast layer is not respected when doing the physics raycasts using rapier (SphereCasts are being handled by rapier). Thanks for the repo. I’ll check it tomorrow
oh, let me try just removing the cube altogether
by user 326444095130042368
FYI empty object, floating in the air, still returning collisions:
by user 326444095130042368
even on an empty scene, with nothing else it will return a collision?
by user 326444095130042368
thank you for the attention! hopefully this images/info help I will keep an eye on this
by user 326444095130042368
what does it render with ?showcolliders ?
nothing different
by user 326444095130042368
Hi @Orlando Almario i think we ran into two issues here
1: the sphere gizmo did draw at a wrong size so your spherecast was actually bigger and did intersect with the floor
2: the gizmos were not set to the correct raycasting layer so we hit those as well 
That being said the sphereCast is not great. It uses the threejs api and it does not give an accurate intersection (maybe fine for your case)
Im looking into exposing more of the rapier api, they have shape overlapping and are very likely faster too
hey, I ran some very extensive testing yesterday and I agree sphere casting is not great haha I ended up trying to create my own sphere to mesh collision my results where:
- by chance I decided to only check agains the “default” layer so I think this save me from the gizmos in the wrong layer problem.
- then I started by copying your implementation a little to check first for collisions agains world aligned bounding boxes.
- if I found a colission I then go into trying to detect sphere vs polygons collisions (building the triangles right from the three.js geo buffer lol)
- I got it kinnnddd of working but it was to convoluted at the end.
Appreciate you took a look. our current solution is to just keep with one single raycast and just add a bunch of transparent world aligned colliders
by user 326444095130042368
