Skeleton fattener + mesh cage morph

Hi Gustavo and Matt,

Thank you for giving such detailed feedback - it is really helpful to see all these files and comparisons.

Sorry it has taken me a while to respond - I’ve been thinking for a while now about a number of different approaches to this, each with different trade-offs…

  1. What we have now - radial connections of struts. This gives simple all quad meshes, and works well for things like wireframes coming from surfaces, and pretty well for things like animals or humans that can be seen topologically as collections of tubes branching off each other. It is badly suited for things like volumetric lattice structures or space-frames, where you often need connections from all directions.

  2. The fully implicit surfacing approach - the mesh is created by taking a contour of some scalar field around the struts, using marching cubes or similar. This can be robust, and handle all spatial node configurations, but the down side is that the resulting mesh will be an unstructured and dense triangulation, especially for structures with slender struts, meaning processing large structures can get heavy, and there’s no conversion to subd.

  3. Placing polygons for the ends of each strut and taking their convex hull. This is the approach me and Dave Stasiuk used when we made Exoskeleton, which was roughly based on this paper . This gives a triangular mesh around the node, often with quite badly shaped triangles, so it generally needs some remeshing and can’t convert nicely to subd. At least the tubes are simple though, you can choose how many sides they have, and the face count is much lower than with implicit surfaces. It is also not always obvious how to choose a good orientation for the section polygon about each strut’s axis.

  4. Taking the Voronoi on a sphere of the intersections of all the connecting edges, then extruding these polygons outwards. This gives a mesh of all quads around the node, but one issue is that the connections can then each have different numbers of sides. So when it comes to adding the tubes between nodes, you sometimes have to connect a 4 sided tube at one end to a 5 sided one at the other. There’s no way topologically to do this with all quads without T-junctions - you can increase or decrease by 2 sides, but not by 1. So you have to either accept the occasional triangle, or double the number of divisions so it is always steps of 2.

  5. Orienting a cube to somehow best fit the connecting edges, then extruding those faces (something like this paper or this one and it looks like T-Splines approach works along these lines). This works nicely when you have structures which have up to 6 connecting edges, each of which can be fit to one of sides of the cube. It gives simple quad meshes that convert nicely to subd. It gets tricky though when you have more connections, or several edges want to share one side of the cube, since splits then need to propagate through the rest of the mesh. I think also always sticking to 4 sided tubes can sometimes miss some simpler solutions - for example, in the file you posted, if we use triangular sections we don’t need the extra quads on the nodes that the T-splines solution gives.

  6. Segmenting a sphere with 3 of the edges, then adding each of the other edges one at a time, splitting whatever face they intersect (as described in this relatively recent paper: This can handle spatial configurations, and gives simple all quad meshes with no extra faces on the nodes. I like a lot about this method, but not that it depends on the order the edges are added in. I’ve been thinking about whether there is any way to avoid this.

I think it would also be good to switch between these options in certain cases. For instance, if the arrangement of edges is close to lying in a plane but not exactly, the Voronoi in option 4 could have some very short edges, and it could be cleaner to revert to option 1. You might also want to detect cubic-like arrangements and use option 5 for these, but option 4 or 6 otherwise.

While they are obviously linked, I see generating the mesh topology and shaping the geometry as separate issues, with the first being the much harder problem that needs to be solved first, though to make it more useful as a tool I can see there need to be better ways of controlling the size of nodes and struts, and the amount of webbing.

Once you have the topology, it should be possible to pull vertices in or out to get them onto a chosen target surface. It could also be helpful here to apply at least one subdivision step first to have more vertices to work with to control the shape.

These target surfaces could come from summed distance potentials (like Dendro uses). One nice thing about these is that by varying the power you raise the distance to you can choose between something with a lot of smoothing to what is essentially a Boolean union of cylinders in the limit.

Thanks again for the feedback. I realise this post doesn’t solve your current issues, but I thought I’d share some of my current thinking on this. As you say, it’s a hard problem - it’s very closely linked to general quad meshing of surfaces, which still has a lot of open questions. Hopefully I can get to something more useful for spatial cases like your example soon (probably using some development or combination of options 4/5/6 described above).


Hi @DanielPiker,

Thanks for your detailed reply. We have been thinking about these optioned and we are trying some things out. Some comments in the meantime…

I see, yeah this is not good for us, for neither lattices or any other controlled thickening in product design.

That seems ugly and brute force, kind of like what voxels in Dendro are doing. We want smooth and controlled SubDs.

This looks promising and maybe you can come up with a way to merge some triangles into ngons for SubD smoothing? or will it be too messy?

This looks promising too. We’ll accept triangles.

This #5 is my favorite approach. I don’t see (yet) a problem with the limitation of no more than 6 connecting edges. I have to explore more, but my initial thinking is that anything more than 6 edges meeting at a node it’s going to be a rat’s nest regardless. We’d love to have this option soon!

I’d love to also see a secondary process here of splitting the 4-sided tubes into 8-sided along their lengths and ‘inflate’ them into more circular shapes. a 4 sided tube is always ‘meatballish’ rather than circular.

I can’t quite follow how this works. It seems to me from that paper that there could be a lot of twisting, and is this SubD friendly?

We look forward to see what you come up with. Are you still thinking of adding these options on Fattener command? or make something different?


Thanks @gustojunk ,

Regarding no. 5, I’m curious what T-splines gives for something like this (as the default without any additional user input for the section orientations):

node_test.3dm (8.1 KB)

hahaha! We were actually looking at that exact problem with @mattgaydon yesterday. Not pretty what they do:

tspipe_nodes_gf_190226.3dm (148.0 KB)

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