Marching Cube in Grasshopper (GH & C# Libraries)

Basically just me noodling around trying to learn how to make c# libs talk to GH (thanks to Dave R for the 5 mins tute some months back!!!). This is a simple implementation of a marching cube algorithm I had previously developed for Processing (Java coded in Eclipse). I have also recently ported this to python in Rhino5 to avoid GH, but I am still to implement OpenGL pipeline for comparable redraw performance (& sliders goodness!!!). GH struggles a little with voxels resolutions over 60*60*60 (compared with previous Processing -- and on a super old laptop!) but it is surprisingly OK thanks to the OpenGL drawing in rhino i guess - although i am yet to really throw a lot of input points at the system. I am sure it would benefit from some oct-tree spatial partitioning or other when these numbers get big. there is always another job...

If anyone is interested, marching cube look-up tables sourced from the treasure trove that is: see http://paulbourke.net/geometry/polygonise/).

Comment

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

Comment by Jack munro on February 3, 2012 at 10:06am: Hi Max

Would you be happy to share your Python Rhino 5 version of this? I am just starting to learn basic voxel based stuff and this would be really useful!

Comment by max on October 25, 2011 at 5:30pm: PD hows life? the python node in gh is indeed a nice addition. i am writing a bunch of stuff in it right now as a matter of fact -- well in both gh & editPythonScript. i hope to maybe get along to the shape2fab conference next month and chat with the developers. ut definitely so far so good and much cleaner than the c# and vbnet nodes which were a bit cluttered. kAgent...gee that was a long time ago i ported that stuff - where did you find that? that was originally done for python in maya and blender. too much string concatenation or - mel-a-fying - python in maya i recall. thankfully the rhino team is doing a nicer job

Comment by David Reeves on August 19, 2011 at 7:43am: Yeah I've been fussing about with non-linear interpolation on the edges in order to keep voxel count lower without sacrificing too much resolution. The trick seems to be making the interpolation sympathetic with how the edge sits within the field function. It's working better in my head than it is in my machine. The contouring approach is a cleanly alternative but it gives my computer a hernia at higher resolutions since it relies on physical intersections of surfaces. The bonus is that it gives you silky smooth nurbs interpolation though.

Comment by max on August 18, 2011 at 12:21pm: Hi Dave. The perennial 1/d2 ;) the real trick is applying these as weightings to the MC edge tables so the voxel edge / implicit surface intersections can slide around a bit ensuring smoother geometries. the problem with any of these isosurfaces is that the resultant meshes are not regularly ordered -- ie quad meshes. so in many ways a bit useless for post production / operations. i think the implicit surfaces via contouring you have previously demonstrated seem a little superior in this regard.