Slim down GeometryBasics and remove all type complexity

[SimonDanisch]

So... I tried for a very long time to create a Geometry package that serves all use cases and can be used as a foundation for all other Geometry packages without any performance problems for any domain. This never really worked out for a bunch of reasons.
While GeometryBasics was never used that way, all the ideal requirements I aimed for have turned GeometryBasics into a very overengineered package, with long compile times and complex types.
I never really had a lot of time to actually maintain and grow it though, so on top of being overly complex it has been poorly documented. I also tried to integrate lots of types like LineStrings, which I don't know very well and when to use them :D
So, this PR is slimming down GeometryBasics to the very basics that I need in Makie, which should help a lot with compile times and maintainability.

It changes:

• removes all kind of meta infrastructure, only leaving a simple MetaMesh type that can hold e.g. uv and normals
• remove table interface
• less type artistry and instead tries to use the most simple types as possible
• copies more instead of creating horrible types like StructArray{ReinterpretArray{SubArray{Int64, 1, Vector{Int64}, Tuple{UnitRange{Int64}}, true}}} (this is even shortened :D )
• Make Point +/-/* Vec consistent

Fixes:

• Meshing a single triangle sometimes returns an empty mesh #158
• Ambiguous NgonFace constructors #151
• Mesh with tris and quads? #142
• merging an empty vector of meshes / creating an empty mesh #136
• Why are Multi{Polygon,Linestring,...} <: AbstractVector and not <: AbstractGeometry #95
• FaceView docstring example does not work #81
• Long type info #60
• Polygon is sequence of segments, not points? #13

Will not be in the scope of this package anymore:

• Redesigning Metadata processing and creating of meta-geometries  #71
• heterogeneous geometry collection #50
• heterogeneous feature collection #49
• StructArrays interface for points #29
• Static analysis of a Type #31
• Better show methods for triangle faces #26

[evetion]

This is some good cleanup! This is on top of #169 right?

Over at JuliaGeo/GeoInterface.jl#33, we're now (finally) finishing a new Traits based interface. This gets rid of all the required subtyping on GeoInterface.Geometries and I would like to update the GeoInterface implementation in GeometryBasics here as well.

In that context, I see you removed LineString and changed the decomposition in this PR. In GeoInterface we still assume a Polygon decomposes into 1 or multiple LineStrings like instances (exterior ring and any interiors), which themselves decompose into Pointlikes. Do you think we could still make that work in this PR? Would Line be a proper replacement, or is it just two points?

[SimonDanisch]

Yes, I think we can bring it back, if we document a bit better what its supposed to be used for!
I think we should keep them as simple as possible, so maybe something like:

struct LineString{N, T}
   line::Vector{Point{N, T}}
end

struct MultiLineString{N, T}
   lines::Vector{LineString{N, T}}
end

[evetion]

@SimonDanisch Is it ok to revive https://github.com/JuliaGeometry/GeometryBasics.jl/compare/master...visr:rfc?expand=1 on the current master of GeometryBasics? Or would you like me to open a PR, based on the changes in this PR? Also depends on your expected timeline of this PR?

[SimonDanisch]

No, that sounds great :) Looks like it has 0 dependencies, so that makes things a lot easier ;)
I think master is fine... It's such a small diff, that it should be easy enough to rebase in this PR.

[evetion]

No, that sounds great :) Looks like it has 0 dependencies, so that makes things a lot easier ;) I think master is fine... It's such a small diff, that it should be easy enough to rebase in this PR.

Ok 👍🏻 , I've made a first attempt over at #175.

[jeremiahpslewis]

@SimonDanisch Is this PR still active? From its description, it would solve some issues with adding GeoInterface support to GeoMakie.

[SimonDanisch]

Yeah, still planning to merge it!
Need to first make sure that Makie works though, which is a work in progress: MakieOrg/Makie.jl#2220

[termi-official]

I think the changes here are a major improvement of the package! It is really way easier to follow what happens now. However, I still have some questions here.

1. What are the operational and semantic difference between AbstractGeometry and GeometryPrimitive? My understanding on the semantics is that the latter defines "atomic geometry", while the former also includes composites like the meshes. Is this correct or is there more?
2. What is the minimal example to make a new data type interoperable with Makie? Do we even need the types above for this or is it sufficient to provide a fixed set of dispatches?
3. Why do the polygons carry the points (in contrast to the mesh carrying a point vector and the polygons carry indices to this vector)?
4. Is there any documentation on tge interaction between data types from this package and (custom) shaders?

[SimonDanisch]

1. Good question, I think I introduced that so that one can differentiate between primitives in GeometryBasics and outside... It's been a while, but I think I expected other packages to directly inherit from AbstractGeometry, or their own abstract subtype.
2. It depends a lot on the type - there isn't a clear interface. Maybe we should have one though.
3. In OpenGL you almost always have faces + points, so for this refactor I simplified it to always have the indices. For Polygons you shouldn't share points that much... I think a Polygon quickly becomes invalid if you share points?
4. There isn't really any interaction beyond that MatNf + VecNf can be directly used as Uniforms via GLAbstraction.

[rafaqz]

Yes for 3, in most other geometry frameworks points are embedded in the polygon object.

Accessing indexed points is slower due to the indirection, and needs ~50% more memory in the (2d) case that no points are shared. It would only occasionally save ~25% memory when all points are shared between 2 polygons.

[termi-official]

Thanks for the elaborations. I will answer separately.

2. It depends a lot on the type - there isn't a clear interface. Maybe we should have one though.

Should we discuss this here on in a separate issue or here?

3. In OpenGL you almost always have faces + points, so for this refactor I simplified it to always have the indices. For Polygons you shouldn't share points that much... I think a Polygon quickly becomes invalid if you share points?

Why should they become invalid? For grid-based simulation technique this is very common. Think e.g. about the surface of a Hexahedral mesh as in the second figure in https://ferrite-fem.github.io/FerriteViz.jl/dev/atopics.html#High-order-fields . I guess it is assumed in the code that the polygon is strictly planar?

Accessing indexed points is slower due to the indirection, and needs ~50% more memory in the (2d) case that no points are shared. It would only occasionally save ~25% memory when all points are shared between 2 polygons.

Indeed a good point. But this changes drastically if we attach more meta information to the polygons.

From reading the code I get the impression that a mesh is required to be triangulated. I.e. we cant have a mesh with polygonal or polytopal elements, right?

[Kevin-Mattheus-Moerman]

@SimonDanisch @termi-official @rafaqz would it be worth resuming this discussion or has this gone stale? I am a new user but heavily invested now in GeometryBasics so would welcome and improvements like discussed here.

I can add to the discussion on this point by @termi-official:

Why do the polygons carry the points (in contrast to the mesh carrying a point vector and the polygons carry indices to this vector)?

I can see @rafaqz 's point that in some cases not shipping the points is inefficient (indexing takes time). But in computational methods (physics, engineering, finite element analysis) and geometry processing, this is really annoying and makes coding very inefficient. For instance shared nodes should be shared. If each face/element has its own points it may be convenient for rendering/visualisation, but when adjacent entities should share nodes this approach creates an excess of points that are really not needed. And this would also separate the entities that should really be attached (share points). This causes users to have to merge and split points repeatedly which makes every processing step very inefficient. Below I illustrate this problem with the help of a helpless bunny rabbit, left is imported STL (where each face has its own points), on the right after merging points are properly shared).
So it sounds like we have users/requirements for both of these approaches (1) just indices, 2) ship with points) so perhaps GeometryBasics should support both?

mergevertices_anim.mp4

For context, I am the developer for Comodo and just posted this related issue (before finding this PR): #217