algorithmic modeling for Rhino

This is the script of Daniel Abalde's Peacock tapered offset post, here:

Views: 82667

Replies to This Discussion

Wow, that blobby first image is GORGEOUS Nik!

Looks almost alive :-)

Here is before/after MeshMachine treatment of the outermost (big) Cocoon mesh of variable pipe NURBS surfaces (with round ends).

Because of marching cubes, Cocoon outputs a very uniform but somewhat bizarre mesh.


Hey, seems I replied not directly to your Post.... using Grasshopper quite a time now but never used the Forum ;-)

However, Thanks a LOT for your suggestions. I managed to get everything set up (using tetgen to directly create the 3D Delaunay) until it comes to the pipe variable. It just throws out empty parameters.  If I have one pipe and set the radii manually, it works tough. I have no idea what could be wrong there. I'll attach the def, maybe its an issue with my GH Installation?

(Attention: Used regular Pipe instead, solution may freeze your PC some 30 seconds or so.)


Heh, I'm having the same problem. Grabbing a wireframe from a brep using Rhinocommon creates "line-like curves" instead of lines, and that seems to screw up variable pipe. Details are killing my time. I'm onto a newer version of my Python script too.

I had to brute force build lines now by getting endpoints and building new lines, in code. Variable pipe still failed! I merely trial-and-error found a t input that worked, but now I learn that the Variable Pipe t "parameter" is meant to be specifically the same t output of the simple divide curve component ( ). Kind of a relief to know how simple it is. Such information is often lacking in the help text for components.

I finally have a Voronoi instead of just tetrahedral truss now. There are well behaved cells but still some short lines and often little triangles and squares from small faces. That seems to be a topology fact of life unlike the 2D Voronoi case in which hexagons can be the perfect result of relaxed points, but there is no 3D regular form equivalent, and nor do regular tetrahedrons pack 3D space like 2D equilateral triangles do.

So the file here is new, and slower but gives superior Grasshopper Voronoi versus the old Tetgen ones and outputs real lines not obscure line-like NURBS curves. I still have to cull duplicates in Grasshopper, for lack of programming R&D time.

There's another easily solved problem: overly short lines blow up the variable pipe round ends into big sphere, so I cull the short lines below a threshold length.

By the way, you CANNOT just feed the output of Cocoon into MeshMachine due to all the inner mesh parts from the interior. There can be many hundreds to thousands of inner parts. So bake and select, or look at the output to find the huge outermost mesh and grab it as a list item.


This forum is quite dead. Use discourse instead

WOW! Nik I am speechless. THANK YOU! You have no idea how this helped me. I was fiddling aroud with gene pool sliders as an input for the charge radius, but it only gave me trumpet-like pipes.

I must go through all your suggestions right now, but the pipe variable thing with sphere ends looks super-promising to me. A bit like using multiple curves on a single curve charge component (the Blobs at the end)- a thing I tried as well, but I couldnt find appropriate MM settings for it...

Will post my result later tonight- Hoping to come up with some cool stuff. Maybe I'll open another thread later so I wont spam my stuff in your shortest walk thead.


This version of the Grasshopper Tetgen parser now only gives only unique Voronoi lines.

No more need to input the mesh via wire too, the only mesh input is now from the ASCII format STL file, automatically from Python.

The inner Voronoi cells are separately output from the border/clipped ones.


Here is the unavoidably blunt reason I couldn't rely on the built-in Tetgen Voronoi output after so much work to tease it out of myriad output files:

 The alleged Tetgen Voronoi cell bug seems confirmed by a frustrated Wings3D user in a video:


Question: Would it make sense and be possible to make this a bit more streamlined and versatile by having a mesh or brep input on the script and export the stl automatically to a user definable tetgen folder through the script? That is the last point IMO that makes it a bit fiddly ATM.

I also found the direct python integration of tetgen via meshpy quite an interesting idea to further reduce the intermediate steps needed. Maybe just put it in the same folder as the python plugin and see if you can import it? Or ask on the forum where it would have to go?

Just a thought though... ;-)







© 2022   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service