Should g/IArea always return absolute value of area?

[dgtized]

Triangles like (g/area (t/triangle2 [0 0] [0 10] [10 10])) returns -50.0 for area, which seems somewhat counter-intuitive. This behavior is the same for polygons like (g/area (p/polygon2 [0 0] [0 10] [10 0])). This is used to test the clockwise/counterclockwise ordering of points for certain polygon operations like extrude, and extrude-shell, so it does appear to be expected behavior. However, I also notice that g/IVolume has both a volume and signed-volume method.

My proposal is that g/IArea should be split the same way as the volume interface into area and signed-area, with signed-area returning the current implementations and area returning the absolute value of signed area. This seems more intuitive, but appreciate it would be a breaking change for any code dependent on this behavior.

I can also find a few places this is already accounted for, as example area for tetrahedron is implemented as: (transduce (map #(m/abs* (apply gu/tri-area3 %))) + (g/faces _))), ensuring it's area is not signed. There is similar code leftover in the org file for mesh2 (which didn't appear to translate into the no-org branch), and in the private area-xf in geom/utils.

Happy to submit a pull request if others are interested in this change in behavior, and welcome any feedback on this approach.