I could contribute Marching Tetrahedra on Tetmeshes.

[j-fu]

Hi, I have this method for extracting plane cuts and isosurfaces from general tetmeshes:

https://github.com/j-fu/GridVisualize.jl/blob/698fb552e250e32a2a5e9a69ff46b0dd28f32db8/src/common.jl#L413

The output can also creates a GeometryBasics.Mesh which can be used with Makie:

https://github.com/j-fu/GridVisualize.jl/blob/698fb552e250e32a2a5e9a69ff46b0dd28f32db8/src/makie.jl#L873

There is also "marching_triangles" for isoline calculation.

In the moment, these are not exported, but they are used by other packages (PlutoVista.jl) or projects (@jlchan). Logically, they should reside outside of GridVisualize.jl, and I have the impression that Meshing.jl could be the right place (though I find the package name a bit misleading...). So before creating another package I would like to discuss to move these into Meshing.jl and export them.

A couple of points:

• I would like to keep the current mostly array based API and internal coding, a wrapper taking GeometryBasics.Mesh appears to be not too hard to create. The main reason for this is that I consider the current state of GeometryBasics.jl / Meshes.jl etc not settled.
• I think I already have commit access as a member of JuliaGeometry (maintaining Triangulate.jl a and co-maintaining TetGen.jl) and I would care about maintaining the corresponding part of the code.

How do you look at this ?

[sjkelly]

I would like to keep the current mostly array based API and internal coding, a wrapper taking GeometryBasics.Mesh appears to be not too hard to create. The main reason for this is that I consider the current state of GeometryBasics.jl / Meshes.jl etc not settled.

My goal for this package going forward is to remove any high level APIs and just return Vectors. E.g. be a generic package that other can then wrap for GeometryBasics/GeometryTypes/Meshes/FutureGeometryPackage.

Effectively this will just export a generic isosurface function and it should only depend on StaticArrays. This is a similar API and package design to Contour.jl, but in 3D. I would also like to rename this to Isosurfaces I think for clarity.

GridVisualize seems like it overlaps here with both Meshing and Contour packages. If we can add functionality only depending on StaticArrays and not have to add dependencies, I am all for it.

[j-fu]

My goal for this package going forward is to remove any high level APIs and just return Vectors. E.g. be a generic package that other can then wrap for GeometryBasics/GeometryTypes/Meshes/FutureGeometryPackage.

Effectively this will just export a generic isosurface function and it should only depend on StaticArrays.

Nice to hear this. This IMHO makes quite a lot of sense, and I have chosen this very approach to keep the marching_tetrahedra as generic as possible.

This is a similar API and package design to Contour.jl, but in 3D. I would also like to rename this to Isosurfaces I think for clarity.

In practice, calculating isosurfaces and calculating cut planes (both are important for visualization) can be done by very much the same code, so "isosurfaces" IMHO would narrow the possible usage.

GridVisualize seems like it overlaps here with both Meshing and Contour packages. If we can add functionality only depending on StaticArrays and not have to add dependencies, I am all for it.

Ah I only barely noticed Contours.jl.

IMHO there are two possible ways to proceed:

• a) try to keep the number of related packages low in order to avoid confusion. So marching_tetrahedra would go into Meshes.jl and marching_triangles into Contours.jl
• b) Embrace JuliaPkg and freely explore what is possible which would mean that I would create something like "MarchingSimplices.jl" taking in the generic parts of my code and just informing potential users in the respective README files.

After thinking about this more clearly, my gut feeling is a bit in favor of b) How do you see this ?

[j-fu]

So may be we go for b... ?

[sjkelly]

I wanted to show some basic ideas before reporting back. I have a WIP branch for the simpler API: https://github.com/JuliaGeometry/Meshing.jl/tree/sjk/mindep1

The tests were written with the GeometryBasics and GeometryTypes API, so it will take some care to re-write them.

I realize too this package now has very poor load times, so I would like to investigate that as well. I suspect it is the lookup tables. With that branch the times go from 2.6 to 1.8 seconds or so.

Again, the goal here is to just have the isosurface as the only exported function here, so if we can make it work somehow with this API and get a reasonable amount of precompiles without invalidations, I am all for it.

[j-fu]

GridVisualize has small load time (for this purpose I pass the different possible backend packages - GLMakie, PlutoVista etc - as modules to the visualization routines).

Let me formulate my goals a bit more precisely. I am thinking most about visualization on simplicial grids. I also tend to think code for all space dimensions together.

• iso surface + cut planes for tetmeshes. This is the current code. I takes in coordinates, tets and a P1 function on the mesh. In addition a vector of isolevels and a vector of plane equations. It creates a mesh of isosurfaces and cut planes, with an additonal vector of function values on the mesh nodes. This allows to plot isosurfaces and color code cutplanes.
• Isoline extraction for trimeshes
• Another candidate is this function; https://github.com/j-fu/GridVisualize.jl/blob/3af864a4f30dd63749af88eb8c301d0821ef1751/src/common.jl#L742 which samples vectors from tri/tetmeshes onto regular grids and which is generic in the sense that it is independent of a particular visualization package, so it might be useful for others.

Extensions I have in mind

• Optionally pass another vector of function values for plotting isosurfaces of one function color coded with the values of another one ( i will do this for sure as it is not hard)
• (if needed ): in the moment, the output mesh points are not "linked", i.e. if I get an edge intersection of the isosurface from two neigboring triangles, this ends up with two different points in the point list of the output mesh which could be identified. I have an idea how to do this at least for a start: https://j-fu.github.io/SimplexGridFactory.jl/dev/internals/ , this probably would mean to move that code in here, too.
• (not sure if I will ever have time for it) is a purely iterator based API for accessing a simplex grid on input

For being able to maintain this efficiently I think all this should go into one package. If it would go here, the focus would become broader than isosurface.