RFC: only triangulate surface based on `TrianglulationCriteria`, or triangluate_aabb

[h3mosphere]

Hello,

I am using this for reconstruction of a volume of water, however I am only interested in the top surface of the volume, not the sides or the bottom. I thought passing domain_aabb in Parameters to reconstruct_surface might work, but alas this is not the right thing.

I see the internals of the marching cubes allows TriangulationCriteria. However this is not exposed.

It would be very nice to have either:
an Optional parameter on the Parameters struct, i.e. triangulation_aabb: Option<AxisAlignedBoundingBox>
or expose the TriangulationCriteria on the crate, and allow for passing in an implementor via the Parameters
struct.

Having both would be nice for a) ease of usage of AABB based TriangulationCriteria, b) maximum flexibility going forward.

I'm willing to have a look at this, but any thoughts on changes to the public interface would be welcome.

Also there might be some trickery regarding a global TriangulationCriteria, and merging the results of subdomain TriangulationCriteria. AFAICT TriangulationCriteria is used for stitching subdomains together generated in parallel..?

[h3mosphere]

I have a very rough (only works single threaded I think) branch, it appears to work on my data. Tests need to be added, and running in parallel as well.

https://github.com/h3mosphere/splashsurf/tree/triangulation-aabb

[w1th0utnam3]

Hi, thanks for your interest in the library. It's nice to hear from people using it.

While I'm generally open to such a feature, can you describe a bit more what your use case is? Depending on the simulations that you run (e.g. by changing parameters or number of particles), I could imagine that if you prescribe an AABB for the mesh (i.e. essentially just cutting away parts of the mesh) that you can get big holes in the mesh e.g. if a wave (or the valley before a wave) extends above/below this AABB. Is this ok for you or does this not happen in your use case? Or how would you identify the "top surface" of the fluid? In more complex simulations, the water surface is not just a height field (i.e. mapping x and y coordinates to a height) but you can have "caves"/bubbles in the water due to waves breaking etc. So to me it's not obvious how you would detect the "top surface" except in some special cases. And if you just use an AABB you could have the aforementioned effect of the surface being clipping by the AABB.

In general, the goal of the library is currently to reconstruct a surface without holes that encloses all particles. In this context domain_aabb parameter is used at first to filter out particles that are outside of this domain to reconstruct a surface that is inside of the domain and still closed. Maybe I should clarify the documentation on this.

The TriangulationCriterion was indeed mostly intended for stitching purposes internally for the octree based domain decomposition to run the reconstruction in parallel. At the moment I'm switching to a new approach for the domain decomposition, which just uses a regular grid of subdomains instead of an octree. It doesn't need this implementation detail at all anymore and should be faster, especially for small marching cubes sizes. As a side note: you can try out this new approach by using the current git main branch of the library (e.g. using splashsurf_lib = { git = "https://github.com/InteractiveComputerGraphics/splashsurf" } in your Cargo.toml) and specifying a value for the subdomain_num_cubes_per_dim parameter in the Parameters struct instead of specifying the spatial_decomposition parameter. The subdomain_num_cubes_per_dim parameter can be set to something like Some(64) in most cases and specifies how big each subdomain (i.e. a reconstruction "task" that is run in parallel) should be in terms of marching cubes cells in each direction (so for subdomain_num_cubes_per_dim = Some(n) each subdomain will have n^3 cells).

That being said, in this reconstruction process the generation of the triangles themselves is actually quite cheap in comparison to the other parts (e.g. evaluating the fluid density / level-set function for each grid point). So for now you could also try to just generate the full mesh, and then filter out all triangles that are outside of your domain.

We can discuss other solutions if you can clarify the points I mentioned in the beginning.

[w1th0utnam3]

In general, the goal of the library is currently to reconstruct a surface without holes that encloses all particles. In this context domain_aabb parameter is used at first to filter out particles that are outside of this domain to reconstruct a surface that is inside of the domain and still closed. Maybe I should clarify the documentation on this.

At least it was intended this way, but it looks like it currently doesn't work at all like this. I might have to fix this. But this is unrelated to your issue at the moment.

[h3mosphere]

Hi,

For my use case, the bottom, & sides are largely irrelevant for my purposes, and also alot of unused data to the mesh files that are output. As my meshes are going to be in the order of 100MB+ for a full mesh, being able to ignore 3/4 of the triangles helps alot for file size and performance.

I know the domain AABB when running my simulation, and can easily manufacture an AABB that will cover my use cases, i.e an AABB that is:
slightly smaller in the X & Z dimensions ( to remove the sides), just slightly above the domain minimum Y, and somewhere above the surface of the domain simulation (i.e. domain.aabb.max.y + 10.0).

So yes, the simulation output I have does indeed have cavities (3d dfsph), and no clear/easy way to define the 'top' surface. That being said, I can trivially know what the x & z dimension domain boundaries, and also the bottom, or bathymetry height of the simulation.

Having an AABB aware TriangulationCriteria works well enough for my use case, but I can also see having an arbitrary TriangulationCriteria could be a more general solution to this problem.

[h3mosphere]

Previously I was using the tri_mesh crate for this, but this has some problems with loading meshes & hanging indefinately. Seeing that you already had TriangluationCriterion, made me hopeful that I could just avoid genrating the mesh at all.

[h3mosphere]

In general, the goal of the library is currently to reconstruct a surface without holes that encloses all particles. In this context domain_aabb parameter is used at first to filter out particles that are outside of this domain to reconstruct a surface that is inside of the domain and still closed. Maybe I should clarify the documentation on this.

This was fairly obvious, and I just tried it in the off chance.

Understood that the intended goal of splashsurf is to generate manifold meshes. The branch I posted just recently, does output non-manifold meshes, and I'm not sure if this will cause problems in the future (for me).

Having manifold meshes makes sense for small/bounded domains (i.e a cup of water, or a container), but I am working with larger domains, that will probably need to be stitched with a larger plane mesh representing the ocean, otherwise the results look.. contrived. Making the domains significantly larger is impractical due the the already large size of the simulations (50GB RAM currently. which increases exponentially)