Grasshopper

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

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?

Views: 12153

Replies to This Discussion

David Stasiuk released a VB script called Geometry Wrapper that worked on curves and points, but he had to introduce a kludge to taper the field at the ends, to avoid bulges, which won't work for close parallel lines:

http://www.grasshopper3d.com/profiles/blogs/marching-cubes-curve-wr...

It's at least real code I could translate to my native Python, but I still don't know if it's even possible to solve the math to make things not bulge, as his gives the same result at Millipede:

If I join the four corners of the main box, those four bulges nicely disappear.

His field calculation code is pretty simple, just returning a single field value for a 3D test point input, for a single point or curve being considered, but I don't yet see how they add together to form an overall isosurface:

Attachments:

Various old and new modeling systems have "normal" metaballs that just smoothed together to give one mesh, going back to my memory of the Metareyes plugin for 3D Studio Max:

There is also contemporary Curve Spheres in the voxel 3D pixel modeler Geomagic Freeform and ZSpheres in Zbrush, which suffer none of the bulging effect:

Different math? Not really isosurfaces? Impossible in Grasshopper? Obviously a Boolean Union and mild smoothing would work, but Boolean Unions like this always fail in Rhino, after very slow churning away.

I have reduced the bulging considerably by changing the exponent in David Stasiuk's VB script from 2 to 10, as per Daniel Piker's suggestion for a 2D case:

    If test_dist > 0 And test_dist < radius / 3 Then
      field_value += 1 * (1 - 3 * test_dist ^ 2 / radius ^ 10)
    ElseIf test_dist >= radius / 3 And test_dist < radius Then
      field_value += (3 / 2) * (1 - test_dist / radius) ^ 10

Not sure yet how to reduce the new angled beam artifacts.

The question remains whether there is a superior function that avoids bulge completely so I can start rationally designing bulk objects with mere lines.

Actually, if I move a parentheses to make both powers into divisors and tweak the sliders, I get rid of nearly all bulge, while improving the corners:

    If test_dist > 0 And test_dist < radius / 3 Then
      field_value += 1 * (1 - 3 * test_dist ^ 2 / radius ^ 10)
    ElseIf test_dist >= radius / 3 And test_dist < radius Then
      field_value += (3 / 2) * (1 - test_dist / radius ^ 10)

That I can work with!

MeshMachine indeed, with the Pull setting (to the original input mesh) set to zero to vastly speed things up and just let it start to collapse under tension on its own, but only so far using the Kangaroo Sequence controller, in about one second I get a nice "Meta-lines" mesh with no major bulges and also elegant transitions akin to T-Splines:

This represents a new modeling paradigm in Rhino minus any silly bulges, since Grasshopper can watch for lines in a given Rhino layer, using the Geometry Pipeline component, and thus convert them to a solid, as you work, even as you add brand new lines to that layer:

The VB script also accepts points into the G input.

I had done something similar using MeshMachine, just doing Boolean unions of solid primitives pulled in from Rhino via Geometry Pipeline, but complex edited forms in assemblies so often ruined the Boolean union.

To use it as a Rhino modeler, menu option disable the Grasshopper solver and trigger a single solution using the Recalculate menu item, so you can work without Grasshopper kicking in every move you make.

Attachments:

ExtractWireframe on solids or meshes in Rhino immediately feeds into Grasshopper via Geometry Pipeline to give bulge-free single surface meshes:

OK how does this David and Daniel inspired system compare to the existing David and Daniel created plugin Exoskeleton?:

http://www.grasshopper3d.com/profiles/blogs/introducing-exoskeleton...

Exoskeleton only accepts lines, not curves, though it will work on very fine polylines so that's not a real difference, but it won't merge nearby parallel lines, so it only gives overlapping cylinders with some mesh topology magic where lines join at the same point, whereas Nik's Metamodeler is a general organic modeler that combines hotdogs into a smooth thickened plane volume without any of the former ridiculous bulging in the middle of planes compared to their edges:

How easier to model that thing on the right?!

Now I need the math to also accept surfaces! Since that in fact would certainly be easier for the model on the right. Well, we already have that, actually, by simply extracting wireframe after rebuilding the surfaces to add more isocurves:

I still want the code to accept surfaces directly though. How do I do that? Then I will have a meta-surface modeler. I guess it could just automate the creation of undisplayed construction lines from any surfaces input to it.

Realizing that changing a power of 2 to a power of 10 effectively drove the field spread to zero, I just deleted the equation in favor of a constant, namely distances from the test point input to the closest point on each line:

Before MeshMachine smooths it:

It's no faster this way though, but it clarifies now, that I've hacked metaballs to give a simple fixed distance field that still works as a surfacer of geometry just fine, but now of more interest to engineers perhaps than something with bulging joints? There is now seemingly no difference between connected lines and merely crossing ones in that if I mutually split the rectangle and the line, it looks the same with only a very slight bulge that MeshMachine smooths away anyway.

Now I can emulate T-Splines by merely drawing a few nearly touching or nearly touching lines:

Attachments:

Nice work, I like how this swallows lines (& nodes?) that are close together. That was sometimes a frustration with exoskeleton.

Can you apply this to solids to create bone-like cellular structures? All the rage now in 3d printing!

The mesh line length target input to MeshMachine can afford a crude enough mesh for Exoskeleton thickening at least.

Trying to run my Grasshopper program on each extracted mesh line with tiny little hot dogs blows up the VB script, but I can do 1000 lines well enough (along with wbLaplace smoothing on the right) which shows Exoskeleton to be more elegant for mesh thickening, since it doesn't rely on smoothing which collapses the beam diameters:

For getting the wireframe driven skeleton, you may want to use Cytoskeleton instead. Daniel developed it specifically for this purpose, and it's way faster than Exoskeleton (Exoskeleton relies on solving convex hulls at each node to sort out edge-to-edge relationships, whereas Cytoskeleton uses the face organisation for this).

Cytoskeleton is indeed quite efficient, and using its dual mode lets me use a fine mesh to retain smoothness while still opening up the result to become a real truss, especially after subdividing the sharp initial cytoskeleton:

To get such a rough mesh out of MeshMachine intact, I have to stop using super fast 0 for Pull (to the original unsmoothed mesh), and at least give it 0.001 so it doesn't loose too much volume under tension collapse. To get much relaxation to happen then requires a higher number of sequence frames or just internal iterations via the Iter input, which is probably faster so I should have been using that all along and only doing the minimum 2 frames to activate it.

Pretty complex somewhat aesthetically ordered result for only eight straight curves of an original model. The quad mesh cytoskeleton can then be (slowly) converted to a T-Spline:

...which could then be converted into smooth NURBS.

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2020   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service