Accurate ray-to-plane intersection with floats

This topic is 3167 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Is there a way to calculate the coordinates of a ray-to-plane intersection, and guarantee that subsequent distance tests will count the intersection point as lying on the plane? Is it possible to guarantee that the point-plane distance will be calculated as exactly zero when floating point precision is used? What about methods for improving the accuracy? If I project the intersection points onto the plane they're already supposed to lie on, can I guarantee an increase in accuracy? Are there any ray-to-plane or dist-to-plane equations that can provide these guarantees? The sort of problems I'm dealing with involve splitting a polygon along a plane and then attempting to split the pieces along the exact same plane at a later time. If the newly calculated vertices in the split polygons are not calculated as being on the plane, the algorithm might try to split some of the pieces again, creating degenerate faces.

Share on other sites
A common solution to this sort of problem is to use an epsilon to give the plane a degree of 'thickness'; that is, any point that is within a distance of epsilon from the plane is considered to be on the plane.

Assuming a reasonable epsilon value, this would most likely ensure that vertices resulting from splits would be considered to lie on the splitting plane.

Share on other sites
Taz,

I'm not sure if I can answer your question, but I can provide a couple of little gems I keep around when dealing with precision problems regarding planes.

The first is:

$x(a - b) = {\rm NOT\,\,SO\,\,BAD}$

$xa - xb = {\rm BAD}$

$(w- x)(a - b) -(y- z)(c - d) = {\rm VERY\,\, BAD}$

Floating point subtraction is notoriously bad, and can magnify the error introduced by previous floating point operations. Addition isn't so bad, but adding a negative number is the same as subtraction, and since you may not know the sign of your float you might as well treat addition and subtraction the same.

Many times you obtain the plane normal from a set of three points that lie on the plane. This is usually done by subtracting the verteces to get edge vectors, then taking the cross product of the edge vectors. This results in a lot of terms that are VERY BAD. Most of the precision problems I've had with planes is due to the way I was calculating the plane normal.

I've worked out a method for calculating a normal from three points, which seeks to minimize the badness.

Vector   findPlaneNormal(const Vector& a, const Vector& b, const Vector& c){     Vector n;     n.x = a.y*(b.z - c.z) + b.y*(c.z - a.z) + c.y*(a.z - b.z);     n.y = a.z*(b.x - c.x) + b.z*(c.x - a.x) + c.z*(a.x - b.x);     n.z = a.x*(b.y - c.y) + b.x*(c.y - a.y) + c.x*(a.y - b.y);     n.Normalize();     return n;}

This method seems to perform better than the standard "cross product of edge vector" approach. I'm not sure how much better it is, but it has solved a lot of my precision problems when dealing with planes.

Share on other sites
Quote:
 Many times you obtain the plane normal from a set of three points that lie on the plane. This is usually done by subtracting the verteces to get edge vectors, then taking the cross product of the edge vectors. This results in a lot of terms that are VERY BAD. Most of the precision problems I've had with planes is due to the way I was calculating the plane normal.

There's only one place where I needed to calculate a normal from the cross product of edge vectors, and precision loss introduced a bug. I was calculating the normal of the base of a cone, using vertices 0,1,2. If the cone had many sides, the vertices were too close together, and normalising the cross product produced the zero vector. I fixed that particular problem by creating the normal out of vertices (0, numV/3, numV * 2/3) instead. This ensures they're far enough away to produce a meaningful result for cones with lots of sides.

1. 1
2. 2
Rutin
21
3. 3
4. 4
A4L
15
5. 5
khawk
14

• 13
• 26
• 10
• 11
• 44
• Forum Statistics

• Total Topics
633742
• Total Posts
3013630
×

Important Information

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!