Without looking at it very closely, it seems as though the wedge-product approach (to finding the area of convex polygons) is just asking for numerical errors. It's a classic case of finding small differences between large numbers. Most of the positive and negative contributions are supposed to cancel, but with finite-precision arithmetic, surely there'll be problems eventually-- for example, for small polygons far from the origin.
I suppose for application domains like games, you just want ballpark estimates quickly, and numerical errors aren't very important.
Often in games, numeric error is OK as long as the error is completely consistent. It's OK for your character to float half a cm off the ground as long as it's difficult to see. However, if you check edge AB using "A + x(B-A)" then later edge BA using "B + x(A-B)" the floating point non-associativity will cause tiny gaps between polygons even though they reference the same vertices! This can cause your character to intermittently fall through a perfectly water-tight floor mesh --leading to heated arguments between your testers, level artists and AI programmers...
I'm not sure if this is actually done, but you can shift the vertices to be centered at the origin (e.g by subtracting the mean of coordinates from each coordinate for a polygon). The numbers are now close to 0 and will have better precision
Yeah, I thought something similar-- translating to put one vertex at the origin. But at that point, aren't you pretty close to just using the triangles, anyway (since it's a convex polygon)?
Comments
Without looking at it very closely, it seems as though the wedge-product approach (to finding the area of convex polygons) is just asking for numerical errors. It's a classic case of finding small differences between large numbers. Most of the positive and negative contributions are supposed to cancel, but with finite-precision arithmetic, surely there'll be problems eventually-- for example, for small polygons far from the origin.
I suppose for application domains like games, you just want ballpark estimates quickly, and numerical errors aren't very important.
Often in games, numeric error is OK as long as the error is completely consistent. It's OK for your character to float half a cm off the ground as long as it's difficult to see. However, if you check edge AB using "A + x(B-A)" then later edge BA using "B + x(A-B)" the floating point non-associativity will cause tiny gaps between polygons even though they reference the same vertices! This can cause your character to intermittently fall through a perfectly water-tight floor mesh --leading to heated arguments between your testers, level artists and AI programmers...
I'm not sure if this is actually done, but you can shift the vertices to be centered at the origin (e.g by subtracting the mean of coordinates from each coordinate for a polygon). The numbers are now close to 0 and will have better precision
Yeah, I thought something similar-- translating to put one vertex at the origin. But at that point, aren't you pretty close to just using the triangles, anyway (since it's a convex polygon)?
Yes, I think you are right.