algorithmic modeling for Rhino
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:
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:
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.
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!
Comment
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?
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.
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...
Also, thanks for introducing me to the term Fubar
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
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
Thank you so much..Always amazing!
Looks amazing and every 3d printer's dream! I am on a mission to sell my relatives to get Rhino5 now :)
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?
Thanks for sharing!
Welcome to
Grasshopper
© 2024 Created by Scott Davidson. Powered by
You need to be a member of Grasshopper to add comments!