Raycasting on the client does not acknowledge that parts may not actually be getting rendered where their CFrame is, and therefore the result isn’t accurate.
This is a problem, because the Camera’s PopperCam module uses raycasting to figure out if it needs to be pushed forward or not, and as @Shedletsky was able to reproduce, this may cause it to jitter when in a moving car that you don’t have network ownership over, if there is something that the PopperCam can hit behind your head.
I made a place that demonstrates this problem in action:
The yellow dot represents the origin of the raycast that I’m doing.
The green line represents the raycast itself.
The red dot represents what result I’m getting from FindPartOnRay.
It should be landing directly on the surface of the torso, but instead its acting very jittery.
(Note, the adornee used for the wireframe visualization of the torso’s CFrame is not parented to the workspace, so thats not what the raycast is hitting)
FindPartOnRay must not be changed, as it will then mess up physics and scripting related uses if it doesnt return where the part is in the actual simulation.
While a render-aware alternative would probably solve it, I feel like the data structure(s) FindPartOnRay relies on doesnt know about the render position of stuff. So theyd need to duplicate the whole data structure, doesnt seem worth it.
Best course of action seems like just updating the camera code to work around.
Raycasting doesn’t consider rendering. It only considers physics bodies, which is also why collisions with unions and meshes will land on the physics hulls instead of the mesh geometry.
Sounds like your problem could be fixed with a better ignore list.
