Exoskeleton WIP

Developing an updated exoskeleton with variable end thicknesses for each strut and non-convex hulls at each node...hopefully will package it along with the geometry-wrapping isosurface component and a (possibly) exoskeleton for curves...

51 members like this

View Full Size

Tags:

Comment

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

Comment by David Stasiuk on February 7, 2014 at 2:20am

Hi Timo- This is part of a work in progress on updating the exoskeleton plug-in that Daniel Piker and I developed last year. You can read more about the processes here: http://www.grasshopper3d.com/profiles/blogs/introducing-exoskeleton...

There's a link to the paper that the technique is based on. This update I'm now working on allows for some incremental improvements.

The whole thing is based on convex hulls solving the intersections of lines...in the first exoskeleton, each strut going into each node was tested to determine the necessary offsets for correctly calculating a convex hull. This works fine, but what ends up happening is each hull represents the "worst case" scenario, the two struts that have the steepest angle between them. The updated version identifies other struts that, after hulling, can be pulled closer to the node center, resulting in non-convex hull geometries whose topology was solved by a convex hull process.
In the first exoskeleton, each strut was assigned the same radius...this will also be updated, not only so that you can assign each strut its own radius, but it can have a different starting and ending radius.
There are other bugs in the first exoskeleton that I'm trying to fix as well...identifying problem struts so the user knows what needs to be cleaned up...there was a problem when you were building meshes on any of the world planes that prevented identical vertices from welding properly...some other stuff

I am hoping sometime in the next week or two to get it out there...we'll see, I have a lot on my plate!

Comment by Timo on February 6, 2014 at 10:42pm: i love you.

can you please explaine the mechanism pleaseeeeeeeee

Comment by martyn hogg on February 5, 2014 at 5:32am: Ah, I fixed it... On the mesh faces for the struts I was creating half of them in one direction and half in the other direction (although I had thought I was passing the vertices in a clockwise direction) When I reversed the order that I was passing the vertices into the mesh component it fixed the problem!

Thanks again for all your help, its been a really good learning experience!

I think I might just have to upgrade to Rhino5 if you release your exoskeleton versions!

Comment by David Stasiuk on February 5, 2014 at 4:38am: looks great. Have you tried unifying mesh normals? I often have similar issues with seams, and I'm not really sure why it happens. Bake and check for both naked and non-manifold edges...also, try to change the order of things. Often I will use WB's join and weld, other times I find using the regular mesh join and [uto]'s weld to work better...sometimes I join, unify normals and then weld, other times I join, weld and then unify normals...I haven't really found a rhyme or reason to it all...probably a question for one of the true mesh masters, like David Rutten, Thomas Grabner, Daniel Piker or Giulio Piacentino...

Comment by martyn hogg on February 5, 2014 at 4:17am: I'm getting closer, but possibly still having problems welding the meshes. I've tried The UTO weld vertices and the Wb Weld Meshes and Join which seems to work but when I bake the mesh I get strange marks around the corners.

I'm also getting bulges in the middle of the struts where the polygons are.

I even wrote some Infinite Monkey VB in the latest model :)

Comment by Christian Schmidts on February 3, 2014 at 12:05pm: beautiful mesh topology and connection logic! curves as input would be amazing. there already emerging smoothly weaved forms in front of my eyes :)

Comment by David Stasiuk on February 3, 2014 at 11:15am: 1) Well...I'm doing the whole thing with a script, but there isn't any reason you can't do it with native components. You just have to make sure that you are generating an odd number of perpendicular frames between the polygons that define each strut's engagement with the nodes, and then rotate every other one by Pi / S where S = the number of sides in your polygons.

2) Yes...there are different approaches you can use for ensuring that you don't get a flat hull. For the new exoskeleton, I am trying to keep it easy by just passing the node itself into the hulling algorithm. That way you'll always at least have an elbow to your hull whenever you have a collection of either acute angles or a limited number of struts coming into a single node.

Comment by martyn hogg on February 3, 2014 at 10:51am: The Convex Hulls go flat when there is only 2 input lines... I wondered whether it is worth adding an extra polygon to the Hull in the corner to try and beef out the resulting mesh at the corner?

Comment by martyn hogg on February 3, 2014 at 10:43am: ah, ok, interesting. and does rotating the polygons also make passing the mesh vertices data into a mesh component easier? or are you doing this with a script?

Comment by David Stasiuk on February 3, 2014 at 9:01am: the number of segments along each strut is calculated based on an input for desired resolution and a minimum number that is necessary for good triangulation...basically, the polygons get rotated at each segment for clean triangulation:

There are always at least two segments along each strut (and always an even number of segments) so that there is a "middle" rotated polygon.