algorithmic modeling for Rhino
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.
Any advice?
Tags:
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.
Added by Parametric House 0 Comments 1 Like
Added by Gert Köhler 0 Comments 0 Likes
Added by Gert Köhler 0 Comments 0 Likes
© 2019 Created by Scott Davidson. Powered by