algorithmic modeling for Rhino

Exoskeleton + Cytoskeleton Components

Daniel Piker and I are excited to repackage an updated Exoskeleton with his new Plankton-based mesh wireframe thickening tool Cytoskeleton into a single GHA.

Although both components have been tested and improved upon from their original setups, this GHA is still a work in progress, and hopefully in the upcoming months you'll find further upgrades to these in addition to new mesh thickening components.

For now, Cytoskeleton relies on Plankton for its functionality. You can read more about Cytoskeleton here:

The new exoskeleton has several fundamental changes to it, and therefore when you add it to your library folder, it won't overwrite the old one.

New features and changes:

  • One of the first major changes is in regards to strut radii. In the earlier version all struts were of uniform radius. In the new Exoskeleton, strut radii are variable not only on a per-strut basis, but they also can have different radii from their start to their end. So the new component takes lists of Rs (Radius Start) and Re (Radius End) values. If these lists are shorter than the total number of elements entering the component, then struts of greater number than values in these lists will simply take on the last value in the list.
  • The next major change is related to how the beginning of each strut is offset from each node. Before, all node offsets were determined by the "worst-case" offset required for generating a convex hull...So if you had one really acute angle going into a node, then all other struts (even those not affected) would be offset the same amount. This made for some really big nodes. Now, once the script has solved the convex hull, it allows for struts to "shrink" toward the center into non-convex hulls based on the targeted node offset and per-strut calculations of minimum offsets. This allows for only the most acute angles in a node to have significant offsets, and all others to remain relatively tight to the node center.
  • The "knuckle" solving has been changed as well. The knuckle basically accounts for when you have all acute angles coming out of a maintains depth for the hull. Before, a polygon was offset from the node in a vector negative of the average of all outgoing struts, and used for hulling. Now, each outgoing strut contributes only a single vertex, set at a negative of its own vector at a distance based on the minimum strut radius of a node, which has led to the removal of the "knuckle bumpiness" parameter, and also makes (I think) for a  better solution, in most cases. However, I am not fully satisfied yet with the knuckle treatment for all cases, and in the future, I may try to add back in different options for how the knuckle is solved. We'll see.
  • One of the chief complaints related to the first Exoskeleton had to do with how the mesh fubared when struts were too short...a bunch of vertices would move to the origin, and the mesh would look terrible. So now, if any strut is engulfed by its nodes (if the final node offsets for its ends > strut length) an error message is generated, and a simple cylinder mesh around any offending struts is output.
  • Lastly, because of a conversion problem going from Point3d to Point3f, any vertices that fell on any of the world planes wouldn't combine properly. This has also been fixed.

To install, take all of the files from the attached zipped folder (check their properties and make sure they are unblocked) and add them to your special folders -> components folder. If you have the most recent Plankton files, then you probably don't need to add the Plankton files, but if you haven't updated recently, then you will want to replace them with these, as they have been compiled from the most current version.

Here is a quick example file to get you uses Weaverbird:

simple example

If you're interested in more complex examples, you can take a look at these. One is inspired by Daniel's radiolarian. Here I've made a definition that takes advantage of Exoskeleton's new variable strut radius functionality. I've also included another quick look at Cytoskeleton, used in conjunction with an isosurface geometry wrapper script I've put out there already (and which I will tighten up and compile as a component in a future release of Exoskeleton). These files rely on both Weaverbird and Kangaroo (which you really must have anyway). Also, a couple of them use the excellent Human plug-in for its great shader component, but it isn't necessary for it to run. The Exoskeleton Vase definition and Cytoskeleton Phyllotaxis definition both run lighter than the others.

complex examples

Many, many thanks to Will Pearson, whose work on Plankton is amazing, and who also has given some invaluable contributions to Exoskeleton in terms of project organisation. I'd also like to thank Giulio Piacentino for Weaverbird, and for general knowledge and support, and Mateusz Zwierzycki for the same, as well as for sharing his code for convex hulls, which although not used explicitly here, was very helpful in many regards for the development of Exoskeleton. Of course I also have to thank Daniel for bringing me on board to this project and for the countless insights, resources, ideas and inspiration he's shared so generously.

Lastly, I'd like to just say that I am really, really keen to get a curve-based Exoskeleton component added to this component group. I think many people were hoping to have this sooner, and I apologize for not getting it out...some of the bugs have proven to be very tricky (for me at least!) to resolve, and a number of other projects got to me before I could put my time back on these tools, but if you hang in there, I promise that I'll get it out as soon as I can! And hopefully, these improvements to Exoskeleton can tide you over until then :)

Exoskeleton2 is open-source on Github, so if you'd like to see the code, please have a look around!

Views: 7875

Tags: Cytoskeleton, Exoskeleton, Mesh, Weaverbird


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

Join Grasshopper

Comment by Harrison on May 13, 2014 at 7:37pm

oh excellent work!! I can't wait to put it through its paces

Comment by Rasmus Petersen on May 13, 2014 at 5:11am

This looks great! Thanks for sharing with us all!

Comment by David Stasiuk on May 13, 2014 at 3:57am

Hey everyone...I have created a new group for Exoskeleton. In it is an updated version of Exoskeleton that should address the issues that have been described below. Basically, it was a tolerance issue that was causing some hulls to fail. This should be fixed now. In the group, please let me know of any other issues you may experience! Thanks...

Comment by Tudor Cosmatu on May 13, 2014 at 1:50am

Hello David,

Also have some issues here:

Different nodes within the same system. All lines are hand drawn (therefore excluding the possibility of having geometry errors. Lines are drawn in xy plane

PS: didn t forget about sending you the files ;)

Comment by panhao on May 12, 2014 at 10:28am

Comment by panhao on May 12, 2014 at 10:07am

Thanks for sharing.I find the program breaks down in some usual case.

Then I find your method to solve the hull radius in github:

   if (Vector3d.VectorAngle(ExoStruts[HullNode.StrutIndices[0]].Normal, ExoStruts[HullNode.StrutIndices[1]].Normal) - Math.PI /span> RhinoDoc.ActiveDoc.ModelAbsoluteTolerance)
                    { HullNode.HullOffset = HullNode.MaxRadius * 0.5; }

Comment by Ángel Linares on May 11, 2014 at 1:03pm

Thanks guys!

Comment by Nick Tyrer on May 11, 2014 at 10:03am

I will check it out. Off subject a bit, but would it be possible to incorporate rhino's 'check' command into grasshopper?  Even if it requires a button to execute it?

Comment by David Stasiuk on May 11, 2014 at 9:10am

Nick, it also occurs to me that you might try to adjust your tolerances in Rhino...smaller tolerances may make it run a bit slower (the script relies on the Rhino model's absolute tolerance) but it also could help the hull operation.

Comment by David Stasiuk on May 11, 2014 at 7:20am

Hi Nick-

It does make sense that different orders of curves could result in different results. By far the most brittle process in the script is the execution of the hull. It is solved incrementally, basically point by point, building up the mesh as it goes, and it is most susceptible to breaking when an incremental point is either coplanar or close to coplanar with a face already solved. Changing the order of the curves will alter this on node-by-node basis, so yes, it does make sense that it's happening, but I don't think that there is any easy-to-decipher strategy for ordering your inputs to avoid it happening. Is there any chance you could send me the file you're working with that's breaking? I'd be curious to see it, as it may help me to fix it moving forward. I am already thinking about alternate approaches to hulling...


Search Grasshopper


  • Add Photos
  • View All

© 2015   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service