algorithmic modeling for Rhino
I've been casually searching for a "normal" metaballs routine for Rhino for years, but what I find are force field based calculations of an isosurface that are spread out in space too much beyond their ideal surface so they add up where lots of points or lines cluster and create rather unintuitive bulges form a 3D modeler's perspective, here done with Millipede's Geometry Wrapper:
I've learned to do marching tetrahedra or cubes in Python to create the surface as needed from a implicit ( f(x,y,z) = 0 ) mathematical equation based on raw trigonometry but am not yet sure how to define an equation for Rhino user created input items like this or find a way to make marching cubes accept such input let alone one that doesn't treat each geometry item as an electric charge with so little decay.
This would afford an old school "organic" modeling paradigm that T-Splines replaced, but the T-Spines pipe command can't do nearby lines right either, which just makes overlapping junk. Metaballs and lines are not as elegant in that there is a real "dumb clay" aspect to the result that affords little natural structure beyond just smoothing, but still, if it works at all that beats T-Splines, and then I can feed the crude mesh result into Kangaroo MeshMachine to afford surface tension relaxation that will add elegant form to it.
I need both quick hacks and some help on how to deeply approach the mathematics of the required isosurface, now that I can think in Python better than ever.
I got a hint the other day here, about using a different power of fall-off but am not sure how to do the overall task mathematically:
"and just as with point based potentials, one can use different power laws for the distance, function, resulting it different amounts of rounding at the junctions. Below is with a 1/d^3 law for comparision with the above 1/d" - Daniel Piker
He also included this link about bulging:
Am I supposed to create an actual implicit equation for my assigned points and lines and use that with marching cubes to surface it? If so, how do I define that equation, at all, and then how to control bulging too?
Cocoon gives very well defined "free" Boolean-like intersections and differences along with the outer shell union:
I also find that with just enough MeshMachine relaxation, that instead of having to offset the baked mesh, I can have it match the original objects nearly perfectly and reliably as I edit, due to smoothing contraction, even with the super fast Pull (to the original mesh) setting of 0 so it's a free fall contraction under tension. The number of internal iterations (Iter input) controls how far it goes, and MeshMachine is triggered to do those automatically using its allied Frames component. However, due to physics, holes also contract, making them even further from the original surface:
I do have to explode any polysurfaces in Rhino, since Cocoon won't accept them, but especially since I can't feed them from Geometry Pipeline into Surface, the only way so far to avoid the dual re-calculation Pipeline bug since Brep won't work, nor Deconstruct Brep.
I did a line driven node GH model a while ago that David helped me with. I had a similar problem with the tube sections (that I intended to push circular rods into) in that the diameter was unpredictable and so not great for engineering a part to any dimensional accuracy.
The solution (That David came up with) was to create cylinders where the holes were, find the closest points on the mesh to the cylinders and then pull the mesh to those closest points.
Maybe, if certain hole features require an exact size, you could have a layer piped that pulls the mesh back on to the original input geometry?
Awesome David!! :D :D :D
The refine is great. I think there should have a Mesh Charge too, if you continue working on this... I was looking for how to do boolean differences using a isosurface with positive and negative charges. Although my intention is to learn how, this is a surprise that tastes great. Thanks :)
Thanks Daniel! Glad you're having a play with it too. So the Brep wrapper actually breaks down any brep/surface into individual elements and wraps each of them...so if you feed it a solid brep, it'll behave more like an offset shell than a solid volume in its own right:
Since I was originally using Boolean unions based on solids, to feed geometry into MeshMachine, the lack of point editing ability of polysurfaces made me start to develop a library of single surface primitive shapes, based on point editing a sphere or a torus into the shape of cylinders, boxes, etc.
Regarding the mesh charges...I have thought about it, and simply haven't developed a good strategy for it. The whole key to keeping it running (relatively) quickly is by only creating and calculating those positions in the sample grid that are affected by any charge. It's easiest to do with point charges, which simply have a radius of influence. The way it works with curves and breps (not elegant) is it discretises them into individual points which activate potential grid locations. It's relatively easy to break down both nurbs and splines into individual points at predefined distances, but trickier with meshes. I have set up the library though that charges work through an interface (copying Mr. Piker's strategy for implementing Goals in Kangaroo2). Again, like all else, the script isn't ideal, but if you can pass a set of sample positions to activate discrete parts of the grid for an input, then it's pretty easy to make any interface.
Cocoon release announcement:
It's an update of David's above MarchingCubes.gha that lacked icons, and it includes several example Grasshopper programs.
This is great fun!
This has been a really enjoyable and educational forum post.
Amazing Grace, how sweet the sound, that saved a wretch like me; once was lost, but now am found...was blind, but now I see.