Numerical imprecision in intersection test?

I created a cubic AABB whose center is (-12.095000, 0.381000, 18.917000) and the radius is 1.0. That is, the length of each AABB side is 2. Then I shot a ray whose origin is (-11.210000, -0.563000, 20.452000), tmin is 0, tmax is 1.e-16f, direction is normalize(make_float3(1, 0, 0)). To my surprise, the ray intersects with the AABB, as the IS program is called.

I can’t tell if I am doing something wrong in the code or it’s just really a numerical imprecision issue in intersection test. Does this imprecision look reasonable?

Yes it looks reasonable. Your input AABB is not a primitive, and is not guaranteed to be preserved, so don’t assume that it is stored or used for culling.


Thanks for the confirmation. Is this because AABB intersection is done using low-precision hardware? Is there an error bound for AABB intersection that we can general assume?

There are various proprietary reasons that I can neither confirm nor deny. We reserve the right to change how the acceleration structures work based on the latest research between GPU models, between OptiX releases, and between driver versions. Think of the input AABBs as pure suggestion. They could be turned into spheres, they could be clustered into groups, they could be discarded at will. The only promise we make is that your IS program will be called for would-be hit points that are inside of the AABBs you provide. We do not guarantee that your IS program will not be called outside of those regions. We strive to make the traversal as fast as possible regardless.