#178195 - Rajveer - Fri Jun 27, 2014 3:04 pm
I have a question about mitigating floating point accuracy and an example to help discuss it. I have an AABB class which defines the volume with a centre vector and an extents vector
I set an AABB for a group of vertices using the min and max of the group with this method:
The rounding/truncation of these floating point operations causes extents to be slightly smaller than what it's supposed to be containing. This in turn causes an issue in my octree partitioning code when I have an axis-aligned polygon on the edge of the scene to be split and I'm testing if the triangle and AABB intersect, as it would test to be slightly outside of it's AABB when it's actually on it.
How would you go about accounting for the inaccuracies caused in this situation? Is there any way to force the rounding used when performing floating point arithmetic operations (e.g. to infinity, to zero e.t.c)? I see that std::numeric_limits has a range of information (epsilon(), round_error() e.t.c), I've never used this but should I be?
| Code: |
| //Vector3 has just 3 floating-point values, x y and z
class AABB { Vector3 centre; Vector3 extents; } |
I set an AABB for a group of vertices using the min and max of the group with this method:
| Code: |
| void AABB::setFromMinMax(const Vector3& min, const Vector3& max)
{ extents.x = (max.x - min.x) / 2.0f; extents.y = (max.y - min.y) / 2.0f; extents.z = (max.z - min.z) / 2.0f; centre.x = min.x + extents.x; centre.y = min.y + extents.y; centre.z = min.z + extents.z; } |
The rounding/truncation of these floating point operations causes extents to be slightly smaller than what it's supposed to be containing. This in turn causes an issue in my octree partitioning code when I have an axis-aligned polygon on the edge of the scene to be split and I'm testing if the triangle and AABB intersect, as it would test to be slightly outside of it's AABB when it's actually on it.
How would you go about accounting for the inaccuracies caused in this situation? Is there any way to force the rounding used when performing floating point arithmetic operations (e.g. to infinity, to zero e.t.c)? I see that std::numeric_limits has a range of information (epsilon(), round_error() e.t.c), I've never used this but should I be?