Mesh simplification, openVDBs adaptivity value

[soigniert]

Dear Josefine and Lin,
First of all, I would like to thank you for your outstanding work in computational engineering, and for keeping it open and accessible. PicoGK is slowly pulling my attention away from intensifying my knowledge of design engineering with grasshopper, which I have done for the past six years, as the benefits of object-oriented computational engineering become more visible and unavoidable to me.

I have now used PicoGK for some recent projects to handle the "heavy work" of Boolean operations and voxelisation, and it has performed well. I have also recognised the limitations of .vdb (Paraview) and .stl processing when working with small voxel sizes.
Mesh: In Parview and MeshLab, one can apply the "QuadraticDecimation" filter to reduce the mesh size. MeshLab points out that this was developed by M. Garland and P. Heckbert in Surface Simplification Using Quadric Error Metrics (pdf) in Proceedings of SIGGRAPH 97, and has many well-known and widely used implementations. (I found the "best" to be this.).
VDB: To avoid large meshes, I use Paraview to process .vdb files. However, this fails for me with ~1 GB .vdb files. Paraview then only loads a portion of PicoGK.Voxels with values. At a certain height all the values become -3, but this is definitely a Paraview issue since the same file can be loaded back into PicoGK without any problems.
I'm also aware, that openVDBs volumeToMesh() takes in an "adaptivity" value, which can also reduce the face count by combining neighbours. See an exaple attached. The following table indicates the mesh face count depending on voxel bandwith (in PicoGK it set to 3? - maybe this could also get a user defined value as voxel size?) and adaptivity:

Adaptivity	0.0	0.1	0.3	0.5	0.8	1
5 vox bandwidth	661712	70455	31098	25865	18074	17240
3 vox bandwidth	676416	71783	33661	26824	20348	17631

Since I'm not familar with cpp, I would try to build a PicoGK-FQMS bridge app for now, with some coding agent, but as far as I see a native implementation or using openVDB's method would be better.

So my request is all about the possibility to implement one, both methods or your own method, in order to process the geometry with high resolution but then outputting a reduced mesh, making storage and slicing more convenient.

Best
Alex

(tagging @eflehder1 , since he also raised the question about file sizes )

[LinKayser]

Thank you @soigniert — I will look into this. It should not be hard to add that to the Voxel to Mesh functions. Also the mesh simplification algorithm looks like something that I could add the the C++ code.

I am working on the 2.x kernel anyway these days, so I'll probably just go ahead.

Best,
Lin

[LinKayser]

@soigniert — so I experimented with an adaptivity value other than 0 and always got quite coarse meshes, even with 0.001. So not entirely sure what the Adaptivity does. If I have some inspiration, I'll check out the other method you posted and give it a go.

Best,
Lin

[soigniert]

Hey @LinKayser, thank you for checking on the Adaptivity value. Perhaps you could explain what you mean by ‘quite coarse’? How bad is it?
The "adaptive method" should definitely be the more robust one, and one might ask why not simply work with a lower resolution and then live with the interpolation when slicing? I would like to say that I have come to appreciate the simplification in order to maintain topologies, e.g. as a result of internal channels or implicit functions, despite the coarser mesh.

Last Friday, I sliced my components created with PicoGK, which I had post-processed using the "quadraticDecimation" method, and some components caused problems with some slicers. I currently suspect that this happens when the triangles are "too pointy" and the curves between the triangle edges become too short. This can be changed by adjusting the algorithm settings in order to balance out the decimation, but I found that these settings increased the calculation time and led to less robust (manifold) results.

For openVDBs adaptivity I can only contribute the following additional things:
I used Dendro for the example above. Dendro is a openVDB bridge for grasshopper and as far as I can see when searching the code for the adaptivity or volumeToMesh function, directly uses the double value without any changes. The larger values I used seem to result in similar results in the openVDB implementation in Houdini.

I now created another study on the value with grasshopper and PicoGK which should be easy to replicate, Maybe you could benchmark your implementation too, so that we can compare how coarse the result of you really is?

PicoGK Pyramide Benchmark Code

public static void PyramideTest()
{
  Mesh mshPyramide = new Mesh();
  mshPyramide = GeneratePyramide(new Vector3(0, 0, 0), new Vector3(10, 0, 0), new Vector3(0, 0, -10));
  Voxels voxPyramide = new Voxels(mshPyramide);
  Lattice latEdges = new Lattice();
  float fThickness = 1f;
  for (int i = 0; i < mshPyramide.nTriangleCount(); i++)
      {
          mshPyramide.GetTriangle(i, out Vector3 vecA, out Vector3 vecB, out Vector3 vecC);
          latEdges.AddBeam(vecA, fThickness, vecB, fThickness);
          latEdges.AddBeam(vecB, fThickness, vecC, fThickness);
          latEdges.AddBeam(vecC, fThickness, vecA, fThickness);
      }

  Voxels voxBody = new Voxels(new Voxels(latEdges) + voxPyramide);
  Mesh mshBody = new Mesh(voxBody);
  Library.oViewer().RemoveAllObjects();
  Library.oViewer().SetGroupMaterial(0, Cp.clrGray, 0.4f, 0.9f);
  Library.oViewer().Add(voxBody, 0);
  int intFaceCount = mshBody.nTriangleCount();
  Library.Log($"Whole Body triangle count:{ intFaceCount}");
}
private static Mesh GeneratePyramide(Vector3 vecCenter, Vector3 vecCorner, Vector3 apex)
{    
  Vector3 vecB = vecCenter + Vector3.Transform(vecCorner - vecCenter, Matrix4x4.CreateRotationZ(MathF.PI * 2 / 3));
  Vector3 vecC = vecCenter + Vector3.Transform(vecCorner - vecCenter, Matrix4x4.CreateRotationZ(-MathF.PI * 2 / 3));
  Mesh mshPyramide = new Mesh();
  mshPyramide.nAddTriangle(vecCorner, vecB, vecC); 
  mshPyramide.nAddTriangle(vecCorner, apex, vecB); 
  mshPyramide.nAddTriangle(vecB, apex, vecC);       
  mshPyramide.nAddTriangle(vecC, apex, vecCorner); 
  return mshPyramide;
}

Results of the grasshopper benchmark for voxel size 0.5 mm, iso-value 0.0 )

I obtained the following values for the number of faces in the mesh from volumeToMesh(). It seems to me that the adaptivity value has a logarithmic influence, with the increase remaining roughly constant between 0.0 and 0.1 and 0.1 to 1. The progression seems to be independent of the bandwidth setting.
Please note that Dendro and grasshopper work with quad faces

20250804_Dendro-Adaptivity-Study.csv

For adaptivity of 0 the face count is quite close to the PicoGK value, if we consider PicoGK result is on a triangle mesh, while dendro works on quad faced meshes. Which face type did you use?

Best
Alex

[LinKayser]

I will come back to this at a later time. The mesh results were unusable compared to not using adaptivity, even with the lowest numbers, otherwise I'd gone into this more deeply.

PicoGK uses the quad mesh from openvdb, but then subdivides them into triangles to be useful for export or display. openvdb internally uses quads whenever possible and the adaptivity works on the openvdb quad level.

Best,
Lin

[soigniert]

Sure, no worries.
Enjoy yourself with PicoGK 2.0. Looking forward to it.
Best
Alex