Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] non-SDF Meshing #25

Merged
merged 5 commits into from
Jun 23, 2019
Merged

[WIP] non-SDF Meshing #25

merged 5 commits into from
Jun 23, 2019

Conversation

sjkelly
Copy link
Member

@sjkelly sjkelly commented Jun 15, 2019

This removes the requirement of a SignedDistanceField from the meshing process and allows direct sampling of a function over a specified bound. See below:

torus_fn(v) = (sqrt(v[1]^2+v[2]^2)-0.5)^2 + v[3]^2 - 0.25 # torus
marching_cubes(torus_fn, HyperRectangle(Vec(-2,-2,-2.),Vec(4,4,4.)), (80,80,80))

I noticed that the current approach is bottlenecked by cache-misses when constructing the voxels. I originally was attempting a caching approach, but suspected this would be faster.

Benchmarking Meshing.jl...https://github.com/JuliaGeometry/Meshing.jl/issues/24
  242.589 ms (3188657 allocations: 68.93 MiB) # sdf generation time (precompiled)

function MC
BenchmarkTools.Trial: 
  memory estimate:  1.17 MiB
  allocs estimate:  37
  --------------
  minimum time:     10.651 ms (0.00% GC)
  median time:      11.157 ms (0.00% GC)
  mean time:        11.921 ms (1.30% GC)
  maximum time:     272.196 ms (4.89% GC)
  --------------
  samples:          417
  evals/sample:     1

sdf MarchingCubes{Float64}
BenchmarkTools.Trial: 
  memory estimate:  3.75 MiB
  allocs estimate:  59
  --------------
  minimum time:     8.653 ms (0.00% GC)
  median time:      9.392 ms (0.00% GC)
  mean time:        9.974 ms (1.76% GC)
  maximum time:     220.567 ms (0.00% GC)
  --------------
  samples:          501
  evals/sample:     1

If we include the construction of the SDF in the timings, the non-SDF approach is ~25x faster and allocates orders of magnitude less memory.

This is currently just implemented for Marching Cubes, but I will take a similar approach to the other algorithms as well. Once I clean up the API this should allow me to bring in my Dual Contours examples from Descartes since it requires the function to determine the normals.

TODO:

  • MarchingCubes
  • NaiveSurfaceNets
  • MarchingTetrahedra
  • Finalize API

@sjkelly
Copy link
Member Author

sjkelly commented Jun 15, 2019

I forgot to add that as consequence of having the function available we can find the true iso-level of the surface, albeit with a performance penalty. This is important for my solid modeling applications since the mesh needs to be accurate. For visualization the standard interpolation approach should be acceptable.

@sjkelly sjkelly merged commit f1412a4 into master Jun 23, 2019
@sjkelly sjkelly deleted the sjk/perf branch June 23, 2019 20:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant