Skeleton fattener + mesh cage morph

Interesting, that does seem to confirm the cube fitting approach, as it is treating it as just a sort of squashed version of what you’d expect from 6 orthogonal lines.
What happens if you throw in one more connection like this?
node_test2.3dm (10.9 KB)

ooh ooh…

node_test2_tspiped.3dm (180.3 KB)

…reminds me of this:


Hie Daniel,
I have a basic doubt can we crate quad mesh with equal divisions throughout y shape geometry

I think the easiest way to achieve this would be to split the longer lines before passing them into the fatten component (11.9 KB)

like this


Thankyou for the reply sir,
But i am still facing same issue of subdivision , kindly have a look at the file

y shape (15.8 KB)
y shape.3dm (22.0 KB)


Yes, I figured out .
Thank-you so much :slightly_smiling_face:

Hi @DanielPiker, we are wondering if you had a chance to work a bit on this.

We are working on some cool GH-drivable footwear lattices that we want to show next month and we would like to see if a new solver with less twisting helps us. An any other improvements you might be creating.

We can share the project with you in our Basecamp if that’s useful.



I don’t think I ever wrote up exactly what tsPipe is doing, but there is a webinar where I went into a fair bit of detail:

It is based on deformed joint templates, and the default joint templates are from a cube, but you can create custom joint sets. There is only one type of joint (in the rhino plugin) that is computed at runtime, called the autojoint, which is basically an n-gon, extruded, connecting at each of the n quads around the border. It works well for the top of a sphere, but not if you’ve got curves coming in from a variety of different directions. I believe there is a better version available in Fusion now, that handles what we used to call the koosh-ball case.

For more complex joint topologies, the joint faces are constrained to align to the curve, and other faces in the template are deformed to minimize bending, which is how the bendy joint set worked:


Most of this stuff is beyond me. However, it seems like implicit is currently being used by at least some of the folks that specialize in lattice/infill work for 3D printing. This could be worth a look (nTopology also has some really neat tools as well):

From using their trial a few months back, the mesh output was certainly not as ugly as the mesh created by OpenVDB with Dendro.

We may however be looking at two different problem groups though:

  1. Fairly simple structures where nice quad for SubD is needed for subsequent editing/production
  2. Complex lattice like structures where there could be hundreds of potential joints. Going to NURBS on these might not make sense as the file would become too heavy and the manufacturing methods don’t actually need NURBS.

Having Grasshopper tools that can solve both problem sets would be awesome though!

@gustojunk - I’m still working on it, but if you want to send me some bits of sample lattice linework it would be great to have that to test it on.

Thanks @tomfinnigan for sharing those videos - it’s nice to understand more about the logic used there

@Louis_Leblanc - I think implicit approaches such as OpenVDB will always have a place, as they make easy lots of things that are difficult or impossible with explicit surfaces.
For complex lattice structures with thousands of slender members I think they always get pretty heavy computationally, since setting the grid density high enough not to miss the thin struts results in many divisions along their length, where a more structured mesh would use a simpler cylindrical topology, but I guess there’s always scope for remeshing.
I guess when you don’t need quad structure other hybrid approaches are possible too, like solving the nodes implicitly but connecting them with simpler struts.

Hi @DanielPiker, I’ll email you some examples and a Basecamp invite n case you want to see more progress, or have more questions for the team.

We also have been looking at making the strut thickness (T) variable by feeding variable numbers to an exploded polyline, but it does not seem to like it. We’ll switch to spheres and and try to drive gradients to drive the spheres’ diameter change.


Hi @DanielPiker

Any chance you will be supporting curves anytime soon, it lists them on the input but I get no meshes or an invalid mesh when I input curves.

If I convert curves to polylines

Fatten (19.2 KB)


can some one help me,

how can i resolve this error of connection using fatten command ?

rads (20.7 KB)

how to solve this connection error… i tried all means… nothing is helping,…please help!!!

1 Like

how did you achieve this node connections?

Hello guys,

I’m facing the same issue as @radhika.agrawal.mod1 … it appears then when we have more then 3 lines connecting at a node, their is some issues.

How you solved it ? @gustojunk, @mattgaydon, @DanielPiker ? (10.9 KB)


This is not something I or @gustojunk have solved as yet. I had a look at your code @billytalent.exe to see if the misalignment was based on the order of the curves at the junction but this did not seem to fix it either.

Even tried to make a simple perfect example but this still breaks as you can see. It seems that there is a misalignment between the top of the side of the column junction and the input curves. I tried this with and without the spheres, but get the same output so it seems it’s not using the sphere to order the connection lines and edges based on UV intersections points on the surface of the sphere.

Rhino File is only for the box outlines

Misaligned Node Connection Fattener.3dm (309.6 KB)
Misaligned Node Connection (23.4 KB)

thank you i will test it