Just thinking out loud here,

could it for example treat an engulfed line as if it would be an endpoint, so for example take its midpoint instead of the line? Not quie sure if it makes sense. Other then that seems to work just fine!

Thanks again!

Does this new version fix the bug which results in (seemingly) random mesh vertices to be placed at the origin (i.e., [0,0,0])?

Hi Harrison-

Yes it does...you can find a more detailed explanation of the features here: http://www.grasshopper3d.com/profiles/blogs/exoskeleton-cytoskeleto...

One other issue that has come to my attention is if two struts are at too close an angle to each other, the component may return an "object reference not set to an instance of an object" error. I will try to include a test for this in an upcoming release.

Tudor-

I'm not sure if I know what you mean exactly, but I am open to treating engulfed struts differently. One approach I had thought of would be to simply extract offending struts from the solution and give the component a warning message that would show the indices of the failing elements. Another, more complex approach, would be to collapse the ends of offending struts into a "super node"...but this would make the component run quite a bit heavier, particularly if there were several failures in a try, and one fix could cause another failure, etc.

I'm getting "object reference not set to an instance of an object" when using Exoskeleton 2 on a molecular bond model. None of the curves seem to be at too close an angle. I did a quick test on a triangle to see what kind of close angle might cause a problem.

I was able to make it work with angles smaller than 4 degrees. I'm also finding that if you have very close angles, you need very small radii values to make it work. When I started small like this I stopped getting the "object reference" error.

However, if you increase the radii values you tend to get the error "One or more struts is engulfed by its nodes"

Hi David,

I'm super impressed with the new release, huge thanks to you and daniel for making this work public (and open-source!). This is awesome.

Hi Dave,

The super node was where i was hinting at indeed. I was actually suggesting to get the midpoint of those struts which length deviates from the average length of the struts with a certain degree or maybe a more relyable logic for designating the struts which could result in an error, and treat those as 'simple' or 'super' nodes.

To be honest, i like the current method of showing which lines cause a problem, maybe including indices of offenders would also help.

But if there is some kind of method that deviates from original line geometry then it should be an opt-in action. Like using 'topologizer', maybe a toggle

1. standard

2. remove offending strut

3. collapse points for supernode

I think I like that idea, Nick. Maybe make the strut failure treatments an in-component menu (like the "average, cull all, leave one" options in the Cull Duplicates component). Then the results:

1. Return an error (red component) with offending struts highlighted (and also I'd like to add an index enumeration of the failing struts for an easier search in the error message)

2. Return a warning (yellow component) with an index enumeration of the failing struts in the warning message.

3. Return a runtime message with an index enumeration of the collapsed struts in the warning message

Exactly! As long as the user is aware of assumptions the component is taking everyone is happy.

I'm having a recurring problem of missing nodes when dealing with small, complex geometries. In one application, we generate internal lattice structures within a bone implant, and the resulting mesh has broken nodes at seemingly random locations, with no error reported. I've used Exoskeleton quite a bit, and this only seems to happen in this particular case. The line network is generated by creating point grids on the mesh and populating the region between them with PanelingTools. As I increase the resolution of the point grid, the structure gets more concentrated, and these broken nodes start to appear. I've played with the number of sides, radius and node depth quite a bit, and although it does improve in some configurations, the naked edge problem is never entirely gone at higher pt grid resolutions. What might be the issue here?

Indeed, I hadn't installed the newest gha, you've solved the problem! In the example, the scale of the geometry is on the limit of "manufacturability", so in that sense, a tolerance input shouldn't be necessary. Thanks for the fix!

hi guys

i´m getting this error

any ideas?

Hi Mario-you should be able to get around this by just running your Rhino meshes directly into cytoskeleton rather than passing them through the PlanktonMesh parameter component first. This error has to do with some issues related to the fact that the Plankton.gha and PlanktonGH.dll are both producing the same object type, but somehow they don't work correctly with each other. Daniel knows more about it than I do...but like I said, so long as you feed cytoskeleton a regular mesh, it will convert it to a PlanktonMesh internally, no problem.

Hi David:

Great now it´s working

By the way

why ca´t you join meshes before using Cyto component???

It needs clean meshes to run...so if you join multiple meshes, you have to make sure that you weld all of the vertices together. Weaverbirds "join and weld" component does a good job with this, although sometimes it has a hard time welding everything that should be. [UTO]'s MeshEdit tools have an amazing weld vertices component that runs super fast and clean. I'd recommend that you join and weld your meshes, and then split disjoint meshes after (so this way, if you have discrete geometries, then they will be captured as multiple elements). If you do this, then when you feed them into cytoskeleton they should run well.

I have a line network that Exoskeleton001.gh can generate succesfully, however the new version returns the following error, what might be the problem? Thanks.

Hi Aidan...do you think you could send me the file in question so I can take a look at it?

Yes! Got Rhino5 at last (sold some kites :) ) and Exoskeleton is great!

David, would it be a difficult mod to make exoskeleton work without the struts? i.e. all nodes join to each other instead of having a strut between them? I'm looking to be able to add holes through a solid structure, if this makes sense. This would be great for making structures where you want fat nodes that often cause the lines to become engulfed.

I'd like to look at the code, but I'm a complete beginner... after getting the files off github, what do I do to actually look at the code? :)

Hi Martyn...so you mean just have adjacent nodes attach to each other directly? This should be possible to do. I guess I'd approach it by making an override when the Distance parameter was set to zero. I don't think it would be too tricky to implement, but I don't know when I'll have the time to do it...

I use Microsoft Visual Studio Express (here it's with C#)...it's probably easiest to also install github, and then to clone the repository on your machine. Both are free!

Hi David,

I'd be really interested in trying a version which implements the 'super nodes' you've been talking about. How close are you to a release? Is there a branch of the repository that includes it?

Thanks, great work!

Could someone please confirm:

1. Plankton and Cytoskeleton are now packaged with Exoskeleton.
2. The same plankton.dll and planktonGh.dll are used by Kangaroo.
3. Turtle is still a separate download.

Thanks!

Hi Brian- yes, that's right. The Plankton libraries are used for Kangaroo's Mesh Machine as well as Cytoskeleton, so it's redundant, and Turtle is its own thing.

Hi Aidan- thanks...yes I'm trying to find the time to do the supernode thing, but I am really trying to build an integrated wireframe and curve-driven exoskeleton component, which is proving tricky to do...basically, I'd like to make all of the features available in the one component if I can, so it may take a bit. Supernodes are tough, because they can cascade (one supernode can then have to engulf another strut, etc) and there's a real risk for it slowing everything down quite a bit, so I'm trying to develop  a strategy to limit that.

Hi Ewa,

I am also getting this error occasionally, in my case, the older Exoskeleton version (without variable radius) can generate the mesh correctly, is it the same for you? I believe David has isolated the problem, but hasn't had time to fix it yet.

Hi Aidan and Ewa-

Yes...I haven't had the chance to get this working correctly, as I've had a number of other obligations. It's hard to find the time! Ewa, would it be possible for you to post the file that's giving you trouble?

thanks,

Dave

Hi Dave, thank you very much for your interest. Ironically, I somehow cannot encourage him to crash right this way right now :) But as soon as I do, I will be grateful for your help.

Thanks,

Ewa

Hi all, I downloaded the plugin the other day and am having fun with it!!  Great job!! .... I was wondering if someone could explain why I am getting a certain "kink" in this simple file.  The opposing corners don't seem to be getting them.Exoskeleton%20Practice.gh

Hi all,

I tried this plugin giving simple inputs but it seems it doesn't work.. What do I have to do?

Thank you

Hi Simone...Exoskeleton uses a list of lines as input, and it works better with a flat list rather than data structure. So you should explode your curves and use a flattened list of lines. However, it also looks like your polylines don't intersect at start and end points...exoskeleton at this time relies on a network of lines where the start and end points match up.

David, 

I recently started tinkering with Exoskeleton, and it works . . . somewhat. I am getting what seems to be a selective cooperation from it. I have attached the file to this message . . . I even cited some of your "code" from your complex example and I get nada . . . do you know what the issue might be as to why I am getting only some cooperation from Exoskeleton??

vasi.gh

P.S.
I have Weaverbird and Kangaroo

Hi Bradley-

I think the main problem you're having with your def (the one you've attached) is that you some combination of several very small lines and very tight angles. That's why you're getting the error "1. One or more struts is engulfed by its nodes". What's happening is the convex hull being solved on either side of your curves is bigger than the curve itself, so the mesh breaks. Probably the fastest way of working through this is to use Daniel Pikers "Topologizer" (http://www.grasshopper3d.com/profiles/blogs/topologizer-network-cle...) which allows for you to combine and clean line networks according to a preset tolerance. A lot of these conditions are resulting from the voronoi solution you're using, which can make for very small intersection faces between cells.

David, 

THANK YOU for that insight . . . but like all things one step forward is new territory. So! Now that I have it sorted and the lines are "webbing" nicely, my mesh output is creating individual "mesh-modules" when I bake the final mesh output. I attempted to run a MeshUnion, and then attempted to run Cytoskeleton's thicken (bad idea). 

I also baked the final meshes and attempted a MeshBoolean within Rhino . . . that operation failed. Is there a reason that these mesh aren't uniting? They all share the same origin lines . . . is this confusing or is it just me?

vasi.gh

Cheers, 

Hi Bradley,

Try flattening the input line network (right-click, 'Flatten'). That should fix it.

Aidan, 

When I Flatten the lines going into Exoskeleton, it returns an error of "Index was outside the bounds of the array" . . . The odd part is the preview for the mesh is all unified, grouping seems to occur when I bake it . . . Any insights as to what I am overlooking??

So . . . update . . . vasi_2.gh

I made some adjustments to the way I was obtaining my lines; Voronoi was giving me, as David mentioned, some tight angle to strut ratios. With this simpler and similar scenario I get a solid mesh at the end of it all . . . I will attempt to resolve the Voronoi version also . . . Never Give Up. Never Surrender!!!

I had the error "index outside bounds of array" before and I think it was due to having duplicate lines... Use Kangaroos "Remove Duplicate Lines"

BRANCHING%20THICKNESS_2.gh

branches.3dm

I dont seem to be able to get a hull in the joints! Does anyone have any idea why?I have tried playing with the tolerances but I am not able to get any sort of joint fillet!

It looks like a number of things are going on here.

1) your "trunk" comes into the midpoint of a curve...for it to work, each curve end points needs to match another curve's end points...it has to be a network

2) you're using curves instead of lines, at best, Exoskeleton will simplify your curves to lines, but at worst this will break it

3) you're not passing a flat list of values to exoskeleton. it should work with data structure okay, but in this example, you want all of your curves to be in the same data path

4) you have duplicate curves in your network...these won't get solved properly

5) that "t" curve at the top of your trunk is really short, and it is going to have a hard time hulling around it

The good news is, much of this can be quickly fixed using Daniel Piker's Topologizer (http://www.grasshopper3d.com/profiles/blogs/topologizer-network-cle...) You're going to want to have it eliminate short curves for sure, or else you're going to want to figure out some way to change the geometry around that "t".

Hope this helps!

Hey David! That worked beautifully! Thanks a tonne!