Problem with physics.raycast

I’m building a very simple top down 2D track which is a plain image with a track cut out of it. I have built a series of physics edge lines that follow the inner and outer edges of the track, and I wanted to use raycast to look ahead to see where the track is going, using these edges.

The problem, as this little video shows https://www.youtube.com/watch?v=GtscyFQd_Yg (red track boundary shows physics edges, rays are shown in green) is that it works fine for a while, then suddenly the raycast seems to skip the closest track wall and see the one beyond it, or maybe a further one. I thought maybe it was seeing though the joins in the edges, so I overlapped them, but it doesn’t make any difference.

Perhaps I shouldn’t be using raycast, but I thought it was a nice way to get to grips with it.

Hmm that’s an odd issue. physics.raycast is supposed to return the closest rigid body it hits. Perhaps try physics.raycastAll to see all the raycast results (these are also supposed to be ordered from closest to furthest).

I used queryAABB and testOverlap for my collisions, works like a charm you should check it out, unless you use the raycast specifically for the direction you point in?

Is sorting of bodies according to distance implemented in Codea? Box2D itself states that you cannot make assumptions about the order of the callbacks, and raycast (the single one) is just raycastAll that returns the first valid result.

Ignatz, please follow Simeons advice, run both raycast and raycastAll and try to figure out the result (in a manual debugging fashion, I mean).

Thanks for that advice, I’ll try out those suggestions. I am looking forward in specific directions, from -80 to +80 degrees, in 5 degree increments, to find the furthest object.

I’ve made a quick test in the physics lab and it seems that Simeon is right (why shouldn’t he be right anyway?) and raycast always delivers the closest hit. So, unless you are sure that you found a bug (still possible), you should examine your own logic.