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.