please add control number segments(option) for new{ _SubDThickenCurves}*** command in Rhino7*
So that we can get organic or simple results
Also add the ability to change the radius (thickness) in different parts of a line(variable thickness _SubDThickenCurves )*
And please add this command to grasshopper sooner[Are you going to add this important and useful feature to grasshopper at all]?
Thanks for adding this wonderful recipe
@BrianJ
@DavidRutten
@DanielPiker
suggestions
It was a good request
Historical support
It does not currently support
Thanks
Hi @architect.civil5 and @mehran09197306634me ,
Thanks - yes, these are all good requests. Iām working on some updates now, including:
When it comes to variable thickness along each strut - one option Iām thinking of is to allow the user to set a radius value corresponding to each division:
For the Grasshopper component (which is also coming) it will be a bit easier to set up inputs to allow different radii per node or per strut.
I havenāt figured out exactly how this should work in the Rhino command though, since it would require inputting many values, more than practical just through the command line.
Thanks for your complete answer
Ability to insert multiple handles in order to define different rays (variable pipes). I donāt know if itās possible and if youāve already said itā¦
Hereās a very simple grasshopper definition using fatten I made a while ago that helps regulate the size of nodes in relation to number of connections at a node.
Obviously itās nowhere near as useful as what youāre currently cooking up, but for producing stuff to CNC carve with the GH and Rhino WIP tools available now, Iāve found it handy. I use it with very subtle settings, but thereās no reason one couldnāt do otherwise.
Fatten Relative to Intersections.gh (29.3 KB)
I expect for most people, multiples of 4 sides will be more than adequate. 8 sides gets a subD pipe so close to perfectly circular that nobody can see the difference, and 12 probably gets you close enough to circular for fancy engineering that I donāt even understand.
Question: in some of the examples for fatten when you released it, you used planar surfaces within the curve networks to create broader āfinā like results. Is that part of the new features youāre cooking up?
The name doesnāt have to stay as this. It started out as Fatten, but apparently the direct translation of that into Spanish doesnāt sound good, so there was a long discussion about naming, avoiding confusion with any existing command names, and this was the one landed on just before the last WIP went out. I agree itās not exactly catchy and can be reconsidered though.
Iām not sure I understand exactly āmultiple handles in order to define different rays (variable pipes)ā. Different radii along the pipe? then yes, as shown in my previous post, there can be an option for how many rings of vertices to add along each strut, and optionally to also provide different radii for each of these rings.
@Max3 Thatās a nice example, and I imagine it will often make sense to use the tool like this - moving the vertices around after output. There are so many ways people might want the sizing and shape of the different struts and nodes to be controlled, and rather than try and make inputs for every possibility, it could be better for the component to focus on generating good topology, and then structuring it in a way that makes it easy to modify the geometry further downstream (and maybe including an output of the graph structure it uses internally as a way of navigating what connects to what).
Yes, the hope is to later bring back the option of including not just curves but faces and maybe even solids in the input.This is a bit more complicated now, since nodes donāt always have a single axis like they did with the old version, but Iāll figure something out.
The name makes little sense, in my opinion.
You should remove the SubD output from the āPipeā command because there is this new command (it would be redundant to keep both) and simply call this new āSubDPipeā command (overall of all the various options that will be added little by little).
It all seems more logical ā¦ as it was for the āloftā command.
āSubDTickenCurvesā is really ugly as a name (the sense of this command is to make pipes, tubes, do not give thickness to curvesā¦ itās misleadingā¦ ).
Howās Thicken Curves any more acceptable than āGorditaā in Rhino EspaƱol? 
ok, now we reach 12 yo level. @davide76. Iām deleting my last two posts here (this and the Gordita one). You go next!
We are adults, an innocent joke, I have not offended anything or anyone. We are not nuns in the convent ā¦ 
I am informed that in the latest build of Rhino 7 wip (16/06/2020) this command does not work well: the intersection (the node) between two or more intersecting curves is not performed. Possible?
Nodes are not generated at the intersection points (the pipe portions are untied).
The command should generate this kind of pipes:
I see. Yes, in the current release input curves are not automatically split at intersections, so if you want to create nodes there you will need to split the curves yourself first.
This should be fixed for the next release though, along with remembering the diameter input.
Perfect! The command, from what I still see in some demonstration video, is still immature ā¦ but I hope it will improve soon ā¦
hi @DanielPiker It seems that the lines that are without knot or middle point do not follow the command of this command. If this possibility is provided in the next update, it will seem awful.
This command is still very immature, what you say is missing, the possibility of setting various diameters, a preview, the generation of the intersection nodes ā¦ Still very, very incomplete!
