Bulge Free Metaballs And Metalines?

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

http://www.grasshopper3d.com/forum/topics/meshes?commentId=2985220%...

He also included this link about bulging:

http://paulbourke.net/geometry/implicitsurf/

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?

Replies to This Discussion

Permalink Reply by Nik Willmore on July 22, 2015 at 12:18am

My original MeshMachine modeling system included a Boolean difference Rhino layer to do this, but the slow Booleans failed so often in normal addition mode that subtraction was a moot feature.

Permalink Reply by Daniel González Abalde on July 21, 2015 at 12:16pm

I am currently researching the tree structures and the voxels, Rhino has RTree but grasshopper has grasshopper.Kernel.Geometry.SpatialTrees nampespace, with classes as Node3d, Node3dLeaf, node2D... But I have not been able to use them correctly so I can not give an example :/, but I think they are easy ways to make octrees or quadtree with which optimize this kind of process.

Permalink Reply by David Stasiuk on July 21, 2015 at 10:02pm

I have playing a bit more lately with this stuff. I have been looking at Daniel's Æther - which is super elegant - but haven't been able to wrangle it so effectively for negative charges, and haven't really had the time to fix it up to do what I'd like, so have simply instead finished up something much less ideal I started a ways back that uses a more traditional approach. But there are some serious heavy hitting level-set libraries out there that are worth looking into. I have just learned about DreamWorks's OpenVDB which looks incredible: http://www.openvdb.org/. A longer term goal for me (if I ever get time) would be to write a .NET wrapper for portions of this library and try to create an implementation. There's also the jaw-dropping work by Panagiotis Michalatos and Andy Payne (of Millipede and Firefly pedigree, among other things) on their standalone voxel modelling software Monolith if you're interested in checking that out. It's incredibly inspiring.

Permalink Reply by Nik Willmore on July 21, 2015 at 1:17pm

Argh, crucial Geometry Pipeline is broken, causing any slow Grasshopper script to delay twice instead of once, as I now see that when I move a surface in Rhino manually, Pipeline is first re-invoking the old solution again before updating the new one!

A test case of slow Populate Geometry with no VB script does the same damn thing, compared to bringing surfaces into Grasshopper via a normal Surface component (which won't add new surfaces from Rhino automatically):

If I set the number of points from 700 to 1000 to about double the time, the initial delay and preview update to show the old solution again after the initial preview disappears, itself also doubles. I don't see two updates of the Profiler timer indication, only one, which is odd. A menu Recalculate does not have a doubled solution.

Different Grasshopper preview settings or even no preview have little effect on this. I'll post a bug report, since, no, this is not good behavior at all.

I need a script or an alternative to Geometry Pipeline for now, that will live update addition of new surfaces to the Rhino document without such a dual solution wave.

Attachments:

Delay Debugging From Geometry Pipeline.gh, 7 KB

Permalink Reply by Nik Willmore on July 21, 2015 at 1:35pm

Bug report:

http://www.grasshopper3d.com/forum/topics/geometry-pipeline-first-r...

Permalink Reply by Nik Willmore on July 21, 2015 at 2:04pm

Workaround: not needed for points or curves, but for bringing in surfaces using Pipeline's Brep setting, just running in first into a Surface component rids the initial re-calculation of the old solution:

I've updated Nik's Metamodeler thus:Now preview settings are fast enough to just play around with low MeshMachine and marching cubes settings, then you switch to create a final high resolution model:

Attachments:

Nik Metamodeler O FIXED PIPELINE DUAL DELAY BUG.gh, 81 KB

Permalink Reply by martyn hogg on July 21, 2015 at 4:04pm

you think you have problems... i can only add 3 lines and my laptop runs out of memory! At least I just get a red component instead of a complete rhino crash though!

Permalink Reply by Nik Willmore on July 21, 2015 at 4:19pm

Maybe the scale is super huge? I'm using a millimeter Rhino document. You can start with a blank document and initially bake the internalized geometry of the space ship sample parts below the main program group. Here is a simplest case test script with some internalized geometry fed into just the modified bulge-free marching cubes script:

I can get a couple hundred curves to work with only a red warning (not set to an instance of an object) above maybe 400 curves. It takes a few seconds at cube size 10.

Attachments: