Migration of DelaunayTriangulate method to increase usage?

[al-fisher]

Some further powerful uses of the DelaunayTriangulate method already in place and also planned - with some immediate use for creation of BH.oM.Graphics.RenderMeshes. #22

As discussed there is potential for wider usage across other disciplines (in structures say with load take down based on a Voronoi dual of the Delaunay)

Would like to get thoughts on inclusion reference to this method in other engines or indeed migrating to avoid dependency on this repo if usage does expand.
We already have a couple of toolkits exploiting and we are planning a couple more.

This repo relies on a single Triangle NuGet

No urgency, in short term happy to continue - but worth a discussion for long term plans as this method has proven to be very useful.

Whether moving this from its own toolkit is a good idea might also be dependant on any further development plans, if there are any, for this toolkit as it stands?

@tg359 @FraserGreenroyd
@rwemay @IsakNaslundBh @alelom
@adecler @pawelbaran

[rwemay]

I think might be worth renaming/purposing the TriangleNet_Toolkit to something more generic like Mesh_Toolkit or Meshing_Toolkit. I think that way it's a more natural fit into other toolkits and will allow better factory patterns. I would probably keep separate from core (don't think that's what you were suggesting).

[IsakNaslundBh]

Would agree with Robs suggestion, renaming it Mesh_Toolkit or Meshing_Toolkit, but still keeping it separate. 👍

[FraserGreenroyd]

Although there are no current development plans for the toolkit, the toolkit is named as such due to a previous decision that the toolkit be named after what it is wrapping (because it is providing the wrapper for the TriangleNet Nuget). This convention was followed on Clipper_Toolkit which wraps the Clipper nuget. So if we are changing that decision for the naming of this toolkit to further expand what occurs within it we might need to also consider Clipper_Toolkit for a similar discussion at some stage.

[rwemay]

Sounds good @FraserGreenroyd - worth considering. I think a neatly organised Mesh_Toolkit (I vote for mesh, not meshing - seems neater/broad) will be a fantastic place to gather a few wrappers as well as explicit code/methods.

[alelom]

Following this conversation and BHoM/BHoM_Engine#1694, we thought with @al-fisher we'd like to prototype as following:

1. The general IToRenderMesh() interface method to be added in the TriangleNet_Toolkit, which will have to reference Graphics_Engine.
   This way, once you reference the TriangleNet_Toolkit in your Toolkit, you can have the dynamic call to ToRenderMesh working for any geometrical type. This in fact allows to have all the range of needed functionality to produce render meshes, lacking in the Graphics_Engine.

2. Initially, some ToRenderMesh() methods will be put in this TriangleNet_Toolkit: specifically, the ones that need triangleMeshes (like for PlanarSurfaces). Others methods, which do not require the dependancy on TriangleNet.dll, can stay in the Graphics_Engine: these are the methods for simple primitives, like Cuboid, Sphere.

2b. We can discuss whether to move the simple ToRenderMesh methods for simple geometry primitives into the TriangleNet_Toolkit, so we have them all in the same place.

3. This means that TriangleNet_Toolkit effectively will end up to be a toolkit that does "meshing", so we could discuss the renaming to "Meshing_Toolkit".

[alelom]

Closing this as the plan has now become even clearer:

• From Add ToRenderMesh infrastructure and methods for basic geometry primitives #27, we treat TriangleNet_Toolkit as the "mesher" toolkit.
• We need to rename the Toolkit to reflect this.
• Representation methods (GeometricalRepresentation() implemented in Add ToRenderMesh infrastructure and methods for basic geometry primitives #27, and any other future/potential Representation method) will have to be moved out of this Toolkit in a more appropriate location within the Framework, to be determined.