Grasshopper

algorithmic modeling for Rhino

# PolygonArea orientation and accuracy

Does PolygonArea require the polygon to lie on a plane parallel to WorldXY? As far as I can tell, any other orientation causes an inaccurate result, and a plane lined up directly with Z causes it to cease working at all.

The python script here is calculating an area by dividing into triangles from the center of the polygon and summing their individual areas. Rhino's AreaMoments command agrees with its result. The goal's target area and final calculated areas are identical if I set the plane to WorldXY.

I've looked over the PolygonArea.cs source and I admit I find the use of a Vector3d.CrossProduct's .Z for an areadoubled to be some kind of voodoo. If I modify the algorithm to use the .X or .Y I can change which plane works and which fails, but my current use case involves computing multiple polygons with arbitrary orientations.

Views: 68

### Replies to This Discussion

The out-of-plane component of the cross-product is equal to the area of the parallelogram created from the two vectors (i.e. twice the area of the triangle). If the code is using .Z as being double the area of the triangle, then it must be assuming that the two vectors are in the global XY plane. (Or did I misunderstand your question?)

https://mathinsight.org/cross_product

Thanks, I think I have a better grasp of the math involved now. I wrote a modified version of the goal in python which uses Plane.FitPlaneToPoints and maps the points over before computing in order to get accurate results for any polygon orientation. A non-planar polygon will still be an approximation, of course, but combined with a CoPlanar goal this always seems to produce correct areas.

I'm not sure how much of a performance hit it incurs, but it would need to be ported back to c# to make a good comparison to the stock code to find out.

My above script was doing some silly things to try to keep the plane from flipping between iterations, and was causing some cases to fail. I think this works better: assure the measured area is positive (we can't really have negative polygon areas, anyway), and if a *=-1 is necessary compute an inverted ZAxis as well when applying pressures. Also input now requires a polyline rather than a list of points.

planefit PolygonArea v2

• View All