Time consumption of marching cubes algorithm

[Megidd]

I tested the marching cubes algorithm with a 245.8 MiB input STL file.

myTris := wrapper.Tris(/* Load my STL file of 245.8 MiB */)
mySDF := obj.ImportTriMesh(myTris, 20, 3, 5)
myMesh := wrapper.Mesh(mySDF, render.NewMarchingCubesUniform(resolution))

Resolution is number of cells on the longest axis of b-box for uniform marching cubes.

resolution	Time consumed by marching cubes sec
30	29s
60	46.15s
90	69.19s
120	127.65s
150	228.27s
180	355.89s

Question

Could a relationship be inferred between time consumption and resolution?

Cubic relationship?

I suspected that the time consumed by uniform marching cubes algorithm may be increased by the cubic power of resolution. But above observations don't approve it.

Time ~ Resolution ^ 3

[deadsy]

The marching cubes is one component of the total time taken.

In general:

1) setup time (typically negligible) 2) sampling the distance field 3) marching cubes 4) channel time (inter go routines) 5) file io

The time taken to do evaluations is very dependent on the model. Your particular choice (big stl) is pretty horrible. If you just want to think about marching cubes time you'd be better off with a simple sdf (E.g. a sphere).

For marching cubes itself, uniform sampling vs quadtree sampling makes a big difference, it's still marching cubes but the number of samples required is reduced.

Once the samples are evaluated the marching cubes itself is quite simple.

The channel time is a go thing. I was trying to avoid a big memory allocation for the whole mesh by streaming them to a file writer, but go channels can be a choke point if you push them too hard. I suspect we'd be better off by batching more triangles in a single channel write.

But yes- in general higher resolution means more work, and a rough magnitude can be determined by the volume of the bounding box for the object (at the resolution size). Quadtree evaluation gives a log2 reduction to that number.