[willend]

Summary

Opt-in mesh reduction in geometry-mesh-lib, enabled per instrument with
DEPENDENCY " -DGMESH_REDUCE_TOL=<m> ". Undefined (default): no change.

• gmesh_reduce() runs inside gmesh_init after welding/triangulation, before normals and BVH build.
• Edge collapse with quadric error metrics (Garland & Heckbert 1997); pass structure after Fast-Quadric-Mesh-Simplification (Forstmann, MIT, credited in the source). C99, init-only, no GPU code paths touched.
• Tolerance in metres (after scaling). 0 = lossless: only exactly flat regions are merged.
• Vertices on open boundaries, non-manifold edges and seams between faces with different per-face properties are pinned; tri_face (file face numbers, properties) is preserved. faceArray then holds the triangles so display matches.
• interoff-lib is not changed (an %include of gmesh there cannot be shielded by the define, since libraries are embedded once per instrument).

Numerical behaviour: with a non-zero tolerance the surface moves, so results change. The largest collapse error is printed at init.

Testing (macOS arm64, clang only)

• Standalone harness with ASan/UBSan on generated meshes: subdivided cube 1728→12 triangles at tol=0 (area, volume, inside-test exact); UV sphere 14160→5132 at 1e-3 (volume −0.05%); open seamed plate keeps boundary and property seam.
• Shipped meshes (knot.stl, socket.off, twisted_guide.off, Guide.off): closed/oriented/Euler unchanged.
• Tests_union/Many_meshes: tol=0 monitors identical to reference; tol=1e-4 742→94 triangles, monitor −1.2%.

Not tested: Linux, Windows/MSVC, GPU (nvc), McXtrace Union instruments.

🤖 Generated with Claude Code

[willend]

@Lomholy polygon-reduction mechanism draft. For now only enabled if -D compiled in by define.

I have in mind to eventually add something like this - but instead a using runtime-handle set on the command-line, think along the lines of mcrun My_instrument.instr -y --mesh_tol=0.5. Default would be to use the incoming mesh as is.

[Lomholy]

@willend Cool stuff! I am wondering since this runs in initialize if we should add a handle for alowing the user to export the simulated mesh, such that many runs over the same mesh (with the same mesh tol) need not perform this edge collapse?

This would then also apply to the face collapse that is currently in the geometry-mesh-lib.

[willend]

Agreed, this is a good idea!

Another interesting option to consider:
Some level of tooling to allow "keeping the full resolution" for the MC / simulation / calculation part but allowing a lighter version for the 3D-rendering. May of course result in unphysical rendering in the limit - anyway, to think about.

Let's let this PR sit for a while before we do anything further? Then the two of us can discuss interesting options next time we meet up? :-)

(I will pull from main once in a while as we go forward to keep the PR relatively updated.)

[willend]

@Lomholy we can also look at either making such a small stand-alone tool ourselves or look for existing open-source implementations? (I am convinced they are out there.)

[Lomholy]

Is this not exactly what the addition in this PR does if you add a few handles and logic flows?

And agreed, lets discuss when next we meet up!

[willend]

@Lomholy what I meant as an alternative was a small, stand-alone tool just for this purpose alone. Commandline-util instead of adding it to the actual instrument/McCode c-base. But let's chat about that when we get a chance. :-)