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 17, 2015 at 6:41pm

Daniel Piker's Aether package is another type of marching polyhedra that I now remember playing with and commenting about the bulging of, but it had some never debugged surface defects due to how he pulled his initial rough mesh back to the mathematical isosurface that threw me off and I think it just overwhelmed me since it was divided into seven albeit short C# components. It doesn't keep a lookup table of mesh faces filling the polyhedra though like classic marching cubes/tetrahedra, but seems to just union the polyhedra themselves and uses their own triangulated faces to create the initial mesh, albeit an initially convoluted surface one.

http://www.grasshopper3d.com/profiles/blogs/aether-simple-speedy-sp...

If with newfound understanding I try to nuke the spacial field falloff to rid such terrible bulges, in the initial Curve Potential C# component, to change:

double Value = Math.Pow((V.SquareLength), 3 / 2);

to:

double Value = 3 / 2;

I get the exact same badly bulging result (?!), so my hack didn't work yet for Aether, which might be faster than real marching cubes:

Again, if I simply join the outer rectangle lines, the silly corner bulge disappears:

The system also uses the Aether.dll file somehow so maybe the spacial field is hiding in there?

Attachments:

Aether_Examples_NIK_DISTILLED_D.gh, 23 KB

Permalink Reply by David Stasiuk on July 17, 2015 at 7:24pm

The gradient function is the key with Aether. The initial meshing is a super clever type of voxel that eliminates the possibility for topological problems that can occur with cubic voxels.

It is subtly different from the marching polyhedra in that it solves the voxels first and then relocates the vertices along a vector set with a gradient function for each charge, which isn't quite so straightforward. The way it's been set up so far uses an inverse distance function to calculate both...this is definitely unit dependent, and unlike metaballs doesn't cap at set distances (infinite at zero, still has an impact at infinity). I am not sure how to write the evaluation and gradient functions to get them to get the same result.

Permalink Reply by Nik Willmore on July 17, 2015 at 7:58pm

But it's the initial voxels that embody the bulge too, and I could then switch to MeshMachine to just smooth away, quickly ridding convolution, so it's actually just two relatively short C# components in my included GH file, the curve field and the voxel maker. I'd be happy with a mere bulge-free voxel surface mesh.

Permalink Reply by Nik Willmore on July 19, 2015 at 1:16pm

It now works on surfaces too, in addition to points and curves, though I'm relying on rebuilding each surface in Rhino manually to add isocurves to avoid holes between too few of them. So I'm just extracting isocurves in Grasshopper in order to use them as more curves. If I could figure out the thorny use of Grasshopper data trees within Daniel Piker's Geometry Wrapper VB script that is used here, it would be considerably faster than having to include each isocurve in a separate field strength lookup.

The way marching cubes and an isosurface work in the code, is to simply find the distance to the closest point on each curve and run the distance to that point through a slow equation to determine field strength there, usually an r^2 operation, and this causes awful bulging where geometry clusters, so I just hacked it to use no math and instead yes/no values based on a fixed radius value, doubling the speed of the script and removing all bulging effects, so it's not really metaballs any more but after MeshMachine relaxes the mesh under tension, the result is similarly smooth. To build up a full 3D spacial field, it simply adds the field values from each curve (or point) together via a loop over all those geometry objects, so there is no big implicit equation created except such summation.

HOW DO I ADD SURFACE ISOFIELD TO THE SCRIPT ITSELF SO I CAN AVOID THE ISOCURVE KLUDGE?

It's not the VB I'm thrown off by but the lack of a real loop where a data tree is used:

I can likely write my own calculate_surface_field function since it just needs to spit out one of two fixed numbers depending on using Rhinocommon to find the distance of the test point (a corner of a marching cube) to the closest point on the surface. But the above loop doesn't cooperate with my attempt to rewrite it as simple loops going through each point, curve, and surface for each test point. I can barely tell what's looping here, as he has stuffed all geometry into one container and then tests for curves. I'd rather just make loops for separate Points, Curves and Surfaces inputs and get rid of the baffling data tree.

The overall canvas is also rudely updating the preview twice, making it much slower than the two big components actually take so solve, as I believe it may be regenerating a display mesh between VB and MeshMachine solutions?

Attachments:

Geometry Wrapper K SURFACES VIA EXISTING ISOCURVES.gh, 29 KB
Nik's Metamodeler.3dm, 349 KB

Permalink Reply by Nik Willmore on July 19, 2015 at 1:36pm

CORRECTION: Geometry Wrapper is by David Stasiuk, who is happily already following this thread.

Permalink Reply by Nik Willmore on July 19, 2015 at 2:22pm

It's quite fast to wrap point clouds, giving an overall outer shell and then lots of separate inner artifacts:

All made possible by the anti-bulging hack, that also gives it twice the speed, since all those nearby points in the middle would blow it up with normal metaballs.

If points are so fast, perhaps the optimum is to just populate both curves with dozens and surfaces with hundreds of points? Is the finding of closest points on curves slowing it all down? Alas, populating surfaces with random points is itself slow.

Permalink Reply by martyn hogg on July 19, 2015 at 4:34pm

Could any of this be applied to create a 3dHull?
It's a bit different in that 3dHull retains the input points on the output mesh and this seems to cover input geometry with a sort of mesh blanket.
The sl3dHull is great but it almost always causes weird things to happen and I always wonder how I could create my own version

Permalink Reply by Nik Willmore on July 19, 2015 at 5:17pm

Starling sl3dHull is subtitled "incremental 3d convex shell" so won't handle concavities even after you necessarily Boolean union a couple of spheres:

I had high hopes for Starling slFastMesh, but repeated testing shows that it's just doing a Rhino Boolean Union internally, first, and thus fails whenever a normal Boolean fails, which is all the time if you have dozens or hundreds of bodies:

It's exactly the deal killer of failed Booleans that is driving my quest here, since using them ruined my original MeshMachine tension membrane relaxed modeling system, every time a casual user of it point edited a surface or a single sphere object until two faces nearly coincided and then the Boolean failed and it was hard to know where. This is totally robust, I believe.

$13K Materialise Magics has real Shrink Wrap which will wrap things nicely, and tightly, even perforated solids so it retains the holes, while closing off small gaps you can control the sensitivity to.

Microsoft has a rolling ball algorithm that does exactly what it sounds like it does, along the outside surface.

Once you have a fine mesh from my system, one offset by a fixed distance from each point, you could just offset the mesh inwards by that distance (after isolating it from the inner artifacts you can see on the left in green) and thus have a real hull, the need to smooth it to remove marching cube anti-aliasing affording some transition smoothing:

You could ramp up the number of points vastly, and set the radius of influence way down, to get a tighter initial result that would sharpen up even the transition, but this is pretty fast the way it is (1 second).

Permalink Reply by Nik Willmore on July 19, 2015 at 5:35pm

CORRECTION: the rolling ("pivoting") ball algorithm is from IBM:

https://www.google.com/patents/US6968299?dq=6,968,299&hl=en&...You an see why it needs a uniform cloud to work well.

See:

http://n-e-r-v-o-u-s.com/blog/?p=3093

The link to a Grasshopper script is missing, here, for this:

http://www.grasshopper3d.com/photo/ball-pivoting-01?xgi=&test-l...

Permalink Reply by ng5 Alex on July 19, 2015 at 5:50pm

you can find it here

Permalink Reply by Nik Willmore on July 19, 2015 at 5:59pm

A new toy! Here's the IBM publication instead of just a patent:

http://www.research.ibm.com/vistechnology/pdf/bpa_tvcg.pdf

Permalink Reply by Nik Willmore on July 19, 2015 at 7:37pm

Source code for a Grasshopper ball pivot component is pointed to here, in a C# script component rather than a binary Grasshopper addon:

http://www.grasshopper3d.com/group/milkbox/forum/topics/ballpivot-m...

The addon and the C# script behave identically and take the same amount of time.

Ball pivoting does not seem to handle intersecting point clouds of populated surfaces:

It's very tweaky, and the bigger you set the ball, the more likely it is to bridge deep into the interior instead of stick to the surface. It simply is not robust, since no, it does not really roll along the surface, but searches locally, assuming it is dealing with a single shell, which here it is not. A Boolean union of course saves it, but then Rhino can quickly mesh a polysurface anyway. Pivoting ball surfacing is just another triangulation method for uniform single surface point clouds, not a way to find an outer surface of a 3D point cloud. Occasionally it works when your ball size and point cloud happen to relate to one another so that outer points in the intersection area happen to be the closest ones, but tweaking it to achieve that quickly blows up the script and you have to quit Rhino.

When it does occasionally work, it too creates an inner mesh artifact of the intersection area, like my system still does since I don't know how to filter those out yet.