Skeleton fattener + mesh cage morph

I really like the new Fatten command. Having worked with T-Splines extensively, I have missed this functionality for a while now… Also in conjunction with SubD in RhinoWIP… so stoked! Thank YOU!

Does it only work with straight curves? Because I can’t seem to make it work on curved curves. Amazing plugin though!

Yes, for curves you’d need to approximate them with polylines

Use the Curve to Polyline component.

hi @DanielPiker,

I’m trying to use Fatten component in the way I was using TsPipe from T-splines, and it’s not working for me.

Let me show you some examples:

  1. This is what fatten does to this simple lattice structure:


    GH file with internalised data here:
    fattener_pipes_flow_issues_01_gf_190210.gh (34.1 KB)
    here’s a video showing the poly flow/thickness/artifacts issues with it:
    https://www.dropbox.com/s/n5xytq1hy7mzjw8/inconsistent_pipes_fattener_01_gf_190210.mp4?dl=0

  2. This is a more uniform/desired output of pipe thicknesses using Dendro (I culled duplicates in my example so Dendro doesn’t get pissed, I know Fatten will ignore duplicates.


    GH file for that: dendro_pipes_01_gf_190210.gh (38.6 KB)
    and video: https://aws1.discourse-cdn.com/mcneel/uploads/default/original/3X/b/4/b45ea16507f5401a789a068abbf00edab5e8eabd.mp4

  3. And here’s the best result, using TsPipe in V5, what I had asked originally, when Bob mentioned I should check this work:


    GH file with the low-poly that Tsplines built: ts_pipe_mesh_01_gf_190210.gh (227.5 KB)
    and video of that old tool in Rhino V5 when it’s being setup (this includes a few pauses because it’s very slow, not interactive).
    https://www.dropbox.com/s/axcopypc5jew14s/Tspipe_pipes_01_gf_190210.mp4?dl=0
    You will notice in the mesh internalized .gh file here that they also have some mesh twisting, but it seems to still work ok for some reason.

I know in the documentation you mention that this has trouble with <4 curves coming together:

…but here the max is 4 at any convergence.

Also I think that the logic that I need to choose either pipe diameter OR sphere does not make a lot of sense for design flexibility.

I think pipe diameter is about what’s the minimum /nominal diameter at each curve’s midpoint. And the spheres should only dictate how large is the webbing between each curve. Does that make sense?

We’d really love to use this tool for a lot of controlled design structures and lattices. We don’t really like any of the lattice tool/plugins for GH, they are too constrictive and limited. But for us to build our own we need a good fatten tool. What you have is so close, but not quite there. Do you think this can improve some more?

Here’s some screenshots of fatten (blue) vs ts-pipe (green), notice how besides the thickness inconsistencies, there are also some weird normals/tears in the fatten mesh:


Happy to give you more examples of what works/doesn’t. I know it’s a hard problem.

Thanks,

Gustavo

1 Like

Hi @DanielPiker,
I am working with @gustojunk on these tests and have been able to understand some of the issues in more detail.

Firstly the twisted meshes that create the inverted normals on the struts. I have been able to use the line input and planes to create spheres with better alignment but they midpoint ones still don’t seem to match the line controls or the plane. Is it possible to get more control over this alignment?


Secondary, Gustavo all ready mentioned it above briefly but the way the node connections are defined if one line in aligned through the centre of the other 3 the strut connects the side the line has gone through and does not build from the centre.

Clean Junctions

Broken Junctions

Will it be possible to make it so when a strut connecting to nodes together like in a lattice between the top and bottom layer is added the junction is subdivided down like with TsPipe and thus connecting thought the junction instead of sticking to one side. I can model up what I am thinking it would look like as a mesh if that helps.

Cheers
Matt

GH File used: 140219_fattener_pipes_flow_issues_RH-Forum.gh (42.6 KB)

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 http://people.tamu.edu/~ergun/research/topology/papers/caadfutures05a.pdf . 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 https://www.ece.lsu.edu/xinli/Research/LLWQ13TVCG.pdf or this one http://vcg.isti.cnr.it/Publications/2015/ULPTS15/- 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: https://hal.inria.fr/hal-01532765v2/document). 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).

4 Likes

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?

Gustavo

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:

9 Likes

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

crvsplit.gh (11.9 KB)


like this

1 Like

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

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

cbe3c99ed1e728b9f6733e113291eb7592fcaf0d

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.

Thanks,

Gustavo

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: https://youtu.be/Zg6-liJVl48?t=193

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: https://youtu.be/Zg6-liJVl48?t=1486

2 Likes