Perhaps we can improve so options are intuitive (f.e. the dimensions of the box) and adding balls is simple. Right now, adding a ball requires writing some sort of formula, which is not intuitive:
Probably no one knows how to come up with strength and subtract unless they are a math wiz that fully understands the internals of MarchingCubes, for example.
We could also separate the animation of the positions, maybe even just make the balls be Object3D instances that can be animated in any regular way that people would animate objects.
I don’t think the metaballs example was really designed to be a general purpose metaballs isosurface generator/modeller. You’re gonna max out pretty quickly with > 10 or so metaballs since each ball is evaluated for every cells vertices/edges. There also isn’t any vertex sharing between neighboring cells… and isovalues are redundantly calculated for all edges of the voxel. It’s a rad demo, but to take it further probably requires some major refactoring/optimization.
Yeah, I know it is costly, but for some scenarios, for example this demo that runs great on my Pixel 6 Pro phone,
I want to change the vertical height just a tad, instead of scaling it vertically, to avoid stretching the balls.
I just have no idea what the math is doing yet, the organization is not set up for easy learning (my opinion), not well commented, variable names are cryptic, etc, and I just haven’t spent the time yet to understand it.
(Why do many shader/graphics algo programmers like cryptic code?)