5 ms·
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.
by dmlorenzetti 15y ago
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.
- corysama 15y agoOften 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...
- pm90 15y agoI'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
- dmlorenzetti 15y agoYeah, 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)?
- pm90 15y agoYes, I think you are right.