# ray collision with rectangle and floating point accuracy

I'm trying to solve a problem with a ray bouncing on a box.

Actually it is a sphere but for simplicity the box dimensions are expanded by the sphere radius when doing the collision test making the sphere a single ray.

It is done by projecting the ray onto all faces of the box and pick the one that is closest. However because I'm using floating point variables I fear that the projected point onto the surface might be interpreted as being below in the next iteration, also I will later allow the sphere to move which might make that scenario more likely. Also the bounce coefficient might be as low as zero, making the sphere continue along the surface.

So my naive solution is to project not only forwards but backwards to catch those cases. That is where I got into problems shown in the figure:

In the first iteration the first black arrow is calculated and we end up at a point on the surface of the box. In the second iteration the "back projection" hits the other surface making the second black arrow bounce on the wrong surface. If there are several boxes close to each other this has further consequences making the sphere fall through them all.

So my main question is how to handle possible floating point accuracy when placing the sphere on the box surface so it does not fall through.

In writing this question I got the idea to have a threshold to only accept back projections a certain amount much smaller than the box but larger than the possible accuracy limitation, this would only cause the "false" back projection when the sphere hit the box on an edge which would appear naturally.

To clarify my original approach, the arrows shown in the image is not only the path the sphere travels but is also representing a single time step in the simulation. In reality the time step is much smaller about 0.05 of the box size. The path traveled is projected onto possible sides to avoid traveling past a thinner object at higher speeds.

In normal situations the floating point accuracy is not an issue but there are two situations where I have the concern.

1. When the new position at the end of the time step is located very close to the surface, very unlikely though.
2. When using a bounce factor of 0, here it happens every time the sphere hit a box.

To add some loss of accuracy, the motivation for my concern, is that the sphere and box are in different coordinate systems and thus the sphere location is transformed for every test. This last one is why I'm not willing to stand on luck that one floating point value lying on top of the box always will be interpreted the same.

I did not know voronoi regions by name, but looking at it I'm not sure how it would be used in a projection scenario that I'm using here.

-
Why are you trying to use this approach? If you just want a sphere to collide with a box, there are much simpler ways to go about it, and floating point accuracy shouldn't be a real concern. You should consider using voronoi regions: find the closest feature of the box to the sphere's center. – Sean Middleditch May 29 '12 at 20:25