Grasshopper

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: http://www.grasshopper3d.com/group/plankton/forum/topics/cytoskeleton

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 node...it 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 started...it 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: 38689

Comment

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

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...

Comment by Nick Tyrer on May 11, 2014 at 6:08am

Also, thanks for introducing me to the term Fubar

Comment by Nick Tyrer on May 11, 2014 at 5:45am

David/Daniel thanks for this! greatly appreciated.

I am experiencing some unusual behaviour, that hopefully you will be able to explain. 

I have a set of lines (no duplicates), going into exoskeleton. They result in a bad mesh, but by re-sorting the input lines i get varying results of bad mesh. (no changes to exo inputs).

Original = 62 non-manifold, 8 naked edges....

Sort lines by Z =  56 non manifold, 15 naked edges

Sort lines by X = 1 manifold edge, 0 naked edges

Sort lines by Y = 54 non manifold, 19 naked edges

From your point of view, knowing how Exo actually goes about constructing the mesh, do you think there could perhaps be a certain technique for sorting the lines that would aid creating cleaner meshes. Or is it totally dependent on each mesh in question? Or would i just drive myself crazy trying to find logic where there isn't any?

Thanks

Comment by Will Pearson on May 10, 2014 at 12:42pm

Horst, I think you're experiencing that problem because the Plankton assemblies here have been built against the version of RhinoCommon that ships with Rhino SR8 (5.1.30000.12), whereas you appear to be running SR7 (5.1.30000.11) [1]. Upgrading Rhino should fix the issue, otherwise you could compile Plankton yourself [2].

[1]: https://github.com/mcneel/rhinocommon/blob/master/dotnet/Properties...

[2]: https://github.com/dan-piker/plankton#building-from-source

Comment by Luca Breseghello on May 8, 2014 at 5:23pm

Thank you so much..Always amazing!

Comment by martyn hogg on May 8, 2014 at 6:43am

Looks amazing and every 3d printer's dream! I am on a mission to sell my relatives to get Rhino5 now :)

Comment by horst Becker on May 8, 2014 at 3:36am

after installing the new Plankton files a have some Problems with older c# scripts written by Daniel Piker. It creats that error:

1. Error (CS1705): Die Assembly 'PlanktonGh, Version=0.3.0.0, Culture=neutral, PublicKeyToken=null' verwendet 'RhinoCommon, Version=5.1.30000.12, Culture=neutral, PublicKeyToken=552281e97c755530' mit einer höheren Versionsnummer als die Assembly 'RhinoCommon, Version=5.1.30000.11, Culture=neutral, PublicKeyToken=552281e97c755530', auf die verwiesen wird.

 

the script gives me the connected Vertices to each Vertices...

what can I do?

 

Comment by Tudor Cosmatu on May 8, 2014 at 2:24am

Thanks for sharing!

About

Translate

Search

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service