Difficulties producing example similar to demos

[LawG4]

Hello,

I saw your presentation at siggraph 2024, and really enjoyed the talk, so I wanted to explore it in more depth! But I'm having some difficulties getting a demo mesh working. Pictured below is my attempt at running this on the Stanford bunny

Screenshot of marching cubes output


I'm assuming that this is user error on my part, I did try fiddling with the parameters a bit? Setting a=1, b=1 actually produces no vertices! Maybe my resolution is too low?

I'm running via WSL, so maybe the obj file from blender has some non unix line endings causing some issues. I've attached it just in case bunny.zip along with the signed distance field output. I'm not sure what file format this f3d is, or which application I should use to double check it?

I've attached the build commands and the logs which resulted. Hopefully you might be able to point me where I'm going wrong!

Thanks for your time, All the best, Lawrence

1. Generating sdf

   $ ./bin/sdfGen bunny.obj 1000 bunny.f3d 100

   Reading data.
   Warning: 5 lines were ignored since they did not contain faces or vertices.
   Read in 35947 vertices and 69451 faces.
   main.cpp:155 (main)     | Bounds from mesh:
   main.cpp:156 (main)     | min_box={-3.64e-01, -2.99e-01, -3.64e-01};
   main.cpp:157 (main)     | max_box={3.00e-01, 3.59e-01, 1.51e-01};
   dx: 0.00664447
   Computing signed distance field.
   Initializing distances near mesh: 100.00% [============================================================] Took: 00:00:03
   Filling in distances not near mesh using fast sweeping: 100.00% [============================================================] Elapsed: 00:00:40
   Filling in distances not near mesh using fast sweeping: 100.00% [============================================================] Took: 00:00:40
   Setting signs: 99.00% [============================================================] Elapsed: 00:00:00, ETA: 00:00:00
   Writing results to: bunny.f3d
   Writing field3d file with center: -0.0318665 0.030084 -0.106559 lengths: 0.677736 0.677736 0.677736
   Writing 100x100x100 field to bunny.f3d: 100.00% [============================================================] Took: 00:00:01
   Processing complete.

2. Generating marching cubes representation

   $ ./bin/run bunny.f3d RANDOM 100 0 0 0 0 0 julia.obj

   
   main.cpp:233 (main)     | Got distance field with res 100x100x100
   main.cpp:239 (main)     | NOTE: Setting simulation bounds to hard-coded values (not from distance field)
   main.cpp:247 (main)     | Generating random polynomial...
   main.cpp:266 (main)     | Wrote polynomial to temp/p.poly4d
   main.cpp:305 (main)     | Computing Julia set with resolution 100, a=0.000000, b=0.000000, offset=(0.000000, 0.000000, 0.000000)
   ../../src/field.h:672 (VirtualGrid3DLimitedCache)       | functionMin={-5.00e-01, -5.00e-01, -5.00e-01};
   ../../src/field.h:673 (VirtualGrid3DLimitedCache)       | functionMax={5.00e-01, 5.00e-01, 5.00e-01};
   Marching cubes with res 100x100x100: 100.00% [============================================================] Took: 00:00:40

Wrote 1356077 vertices and 2547383 faces to julia.obj

[alexaschor]

Hi @LawG4,

I'm so glad to hear you enjoyed the talk, and it's great to see that people are trying out the code! Thanks for attaching your data -- I believe I was able to reproduce the behavior you're describing with the SDF you provided.

Reproduction screenshot, $\alpha=0, \beta=0$


I apologize for my lengthy response here, I've tried to keep things concise and to organize it into sections for clarity.

Parameters

One downside of the shape modulus formulation is that the control parameters alpha and beta are target-shape dependent and not entirely intuitive -- I know it's typical for these sorts of parameters to range from zero to one, but unfortunately for these parameters that's not the case.

In this case, with $\alpha=0$, $\beta=0$, this dense, chaotic structure is expected behavior. The control parameters control the "fractal shell" around the surface of the target shape, and we call the alpha parameter the "thinness" parameter, as a high value of alpha yields a very thin shell, and a lower value of alpha yields a very thick shell. In this case, with $\alpha=0$, you get an infinitely thick shell, which encompasses the entire domain.

It's hard to give a general heuristic for parameters as it depends on the scale and shape of the target surface, but when trying new shapes I like to start with a very high value of alpha, say, $\alpha=300$, and then slowly bring it down until I get a shell thickness that I like. From there, you can dilate or erode the surface by varying beta.

Trying this out with your attached SDF, I get more reasonable-looking results:

Results screenshot, $\alpha=300, \beta=0$


Input mesh

Even with these adjusted parameters, there are some strange-looking artifacts down at the bunny's base -- I believe these are due to the fact that your input mesh is not watertight, and so then the sdfGen program produces a wonky SDF:

Holes in bunny.obj


Filling holes in the mesh with Meshlab's Screened Poisson implementation, re-generating the SDF and re-computing yields the following:

Results with watertight bunny, $\alpha=100, \beta=0.025$


I really should add a check for watertight-ness to sdfGen (or even better, switch to e.g. the exciting [Feng and Crane 2024] to generate the SDFs).

I'm not sure why the parameters change so much for the watertight version to produce similar aesthetics -- my only guess is that the holes throw the scale of the SDF out of wack? I'll have to investigate that further.

SDF format

You're correct that the *.f3d format is not a common format -- this is, as far as I'm aware, a custom file format that this project inherited from the QUIJIBO code at theodorekim/QUIJIBO.

Dr. Kim did release a tool to visualize and inspect these fields, which is included in projects/fieldViewer3D in the HOBAK repository (which uses the same *.f3d format) at theodorekim/HOBAKv1, and which I believe builds independently from the rest of the HOBAK code.

WSL support

I did try running a version of this code on WSL about a year ago and I believe it worked, but I should double-check to make sure everything works well in that setting -- hopefully I can spin up a Windows machine and confirm that in the next few days. It's encouraging that we seem to get the same results for the $\alpha=0$ case, though, so it seems that it might be working okay.

Please let me know if this helps, or if you have any further questions or concerns.

Thank you again, Alexa Schor

[alexaschor]

I should also add, just in case and so as to be clear -- this is the implementation of our 2023 paper "A Shape Modulus for Fractal Geometry Generation". I also have alexaschor/IntoThePortal, which is the implementation of our 2024 paper I presented this summer.

That repo is essentially forked from this repo (though not in the GitHub sense), and can also be used to generate fractals even without portals. It's not just a straight upgrade, though -- the main difference is that this repo conducts iteration on the quaternions and uses normalized quaternion polynomials to form the versor field, while the 2024 repo uses Perlin gradient noise to form the versor field and conducts iteration on $\mathbb R^3$.

Aesthetically speaking, this forms a difference in the style of fractal textures that appear on the surface -- quaternion polynomials have interesting large-scale structures (swirls, spikes emanating from a point, etc) that aren't produced by the Perlin noise for the 2024 paper.

[alexaschor]

I'll close this now just to keep things organized, but please feel free to reopen it or to open a new issue if you have any additional questions!