Marching Cubes: Curve Wrapping & More Metaballs

UPDATE: 30-Jan-2014

I have added breps as an input for wrapping geometry (it also can take lines now), as in the above definition. It has been updated for some efficiencies...now you can taper a curve at both ends if you choose, you only need to feed one radius, although you can feed as many as you like (it acts like the longest list component). The definition uses kangaroo, weaverbird and nudibranch, although I ahve also included some internalized geometry...but I highly recommend playing with those! Kangaroo and weaverbird are better-known essentials, but nudibranch is really fantastic too. Enjoy!

Some of the work posted lately by Nick Tyrer has gotten me thinking about marching cubes again...I had done some stuff with marching tetrahedra and cubes a ways back, and with some new inspiration (and a little time I could carve out today) I figured I'd take a stab at trying to make it more flexible and robust. There was a lot of room for improvement...certainly there still is. This is really a work in progress, so all caveats apply to the script...it can probably break, hasn't been thoroughly tested, etc. But I probably won't be able to do too much more with it for a bit, so I figured I'd put it out there if anyone wants to play with it.

The short of it is that the inputs can take any combination of points and curves, along with variable radii of influence for each geometry object. Also, if you're using curves, and want to "taper" the effect of it over its length (from start to finish) you can do so. For example, an untapered curve versus a tapered curve:

The marching cube stuff is derived from the amazing Paul Bourke's work. I'm calculating fields around points and curves using a standard metaball fall-off function. The trick to its (relative) quickness is in using rTrees to determine which sample points should have their fields updated by various geometry objects, and also in ensuring that points aren't sampled more often than they need to be. The use of the rTree has some up-front computational expense, but with larger geometry sets it saves a ton of time.

The definition has some examples in it, as well as a description of the inputs...but here there are again anyway:

G = A list of base Geometry, which can be any combination of curves or points

R = Radius...this is a list of the radius of influence for each geometry object. The number of elements in this HAS TO BE EQUAL to the number of elements in the geometry list

res = resolution...the edge length of each sampling cube, so smaller numbers reflect higher resolutions. Watch out...the lower this number is, it exponentially increases the calculation time!

iso = iso value for cutting the surface...the lower the number, the bigger the mesh will be

smooth = an integer equal to the number of smoothing passes you want to do on the mesh(es) after they've been created

taper = a boolean...if you're using curves, and want the mesh that wraps around the end of the curve to be tapered smaller, then set this equal to true

ratio = the taper ratio, a double between 0 and 1...this is how much of your base radius you want your tapered edge to be...so if your taper = 1, then your tapered edge should have the same radius as the beginning, 0.5 then it'll be half, etc.

run = a boolean to execute the code...it still can be pretty slow with a lot of geometry, so you can toggle this off to adjust your settings

Anyway, I hope you enjoy!

140120_marching_cubes.gh

Comment

You need to be a member of Grasshopper to add comments!

Comment by Pieter Segeren on March 5, 2014 at 3:24am: Awesome work David! Love it. And thank you for sharing it.

Comment by jozze on January 31, 2014 at 2:04am: wicked!

Comment by Tudor Cosmatu on January 30, 2014 at 8:17am: Sweet!

Comment by Thomas J. Mrokon on January 29, 2014 at 6:08am: really nice - thanks for sharing....

Comment by Christian Schmidts on January 24, 2014 at 12:56pm: Hello David, great to hear that you will look into..

I think that it could lead to interesting forms especially because the algorithm is capable to handle a quite big amount of points. I imagine things like impressioning forms to others or even define a kind of boundaries which could limit the isosurf locally.

I hope it will happen with the gha - both really great tools!

Comment by Atsuo Nakajima on January 23, 2014 at 9:12pm: Amazing! What a beautiful program!

Thank you for sharing.

Comment by David Stasiuk on January 22, 2014 at 2:44pm: Thanks Christian...interesting idea on the negative points/curves. Intuitively, it seems like it could work...they would just adjust the iso value in the other direction. There may be some funny stuff with the threshold, but I'll try to look into it. I'm hoping sometime over the next weeks to package it as a GHA along with an Exoskeleton reboot, but we'll see.

Glad you saw the genepool bit in there :)

Comment by Christian Schmidts on January 22, 2014 at 1:02pm: definitely the fastest and cleanest marching cube implementation so far here on the gh community

also nice approach to script the genepool..

one suggestion for further development would be to able to have also negative values for the radii - these points /curves could act like a kind of voids which are pushing away the isosrf with variable strength. I have no idea how complicated it would be to achieve with the marching cube or if its possible but I think this could lead to quite interesting forms..

anyway great work and thank you for sharing!

Comment by Daniel González Abalde on January 21, 2014 at 9:50am: Cool, thanks David!

Comment by Nick Tyrer on January 21, 2014 at 9:21am: Hey David

Really Cool work! And thanks for the credit.

I also have been thinking about the 'taper' but i haven't spent much time on it. haven't got much further than globally affecting the field values.