add area and volume calculations

[BeastyBlacksmith]

Implement calculation of area and volume
This is one of my first PRs so I'm not sure, if it meets the specifics of this package entirely.
The area function may or may not be a substitute for

GeometryTypes.jl/src/polygons.jl

Line 16 in 649fe6f

function area(contour::AbstractVector{Point{N, T}}) where {N, T}

, which is either wrong or I didn't fully understand its purpose.

[CarpeNecopinum]

It's not a replacement for the area method of polygons.jl (which e.g. handles non-convex polygons without having to triangulate them first). But what you're suggesting looks like a valuable addition to me.

Adding that gts parser and a relatively large mesh with it for testing is a bit overkill though, imho. I would suggest to just build a small mesh (e.g. a cube, has the advantage that it's obvious how large the volume/area should be) directly in the code and use that for testing.

[SimonDanisch]

Sorry for completely ignoring this! @CarpeNecopinum probably has a better idea ;) I basically just copy & pasted the area code for a single purpose usage -.-

[BeastyBlacksmith]

how do i get a properly oriented cube?
I tried

    cube = HyperRectangle(Vec3f0(-0.5), Vec3f0(1))
    cube_faces = decompose(Face{3,Int32}, cube)
    cube_vertices = decompose(Point{3,Float32}, cube) |> Array

but the volume computes to zero...

[BeastyBlacksmith]

why do I get the comments, if I rebase?

[CarpeNecopinum]

When you rebase against master, it makes new commits that have the same messages, but different hashes. You should have merged master instead.

Happened to me earlier today, too. 😅

[BeastyBlacksmith]

that indeed does look better

[CarpeNecopinum]

I just found out that the faces of a 3d HyperRectangle are inconsistently oriented, so you getting a volume of zero is actually the "correct" result (i.e. your algorithm does nothing wrong here).

You should be able to test your algorithm with the branch in #183, there I fixed the orientation so all faces point outwards (with counter-clockwise winding order).

[BeastyBlacksmith]

Thanks! This is fine now

[SimonDanisch]

Is this mergable then?

[CarpeNecopinum]

Wouldn't call this normal, as the actual normal is the normalized version of this.

[BeastyBlacksmith]

too much of a pun, if I name it unnormal?

[CarpeNecopinum]

edge_cross_product maybe? Personally I'd probably just keep it as a local function inside the other ones. Even though you'd have the same code twice then...

[CarpeNecopinum]

Re: Silly names. What about normal_times_twice_the_area? 🤓

[SimonDanisch]

maybe something like orthogonal_vector?

[BeastyBlacksmith]

orthogonal_vector then. This is ready to merge.

[SimonDanisch]

Thanks!