Add control number segments for new [_SubDThickenCurves] command in Rhino7

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

4 Likes

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:

  • Better handling of non straight curves
  • Options for number of divisions along each strut, including an option for none. This could also include an option where the number of divisions depends on the length of the strut.
  • Checking for duplicate segments in the input
  • Better handling of nodes with large numbers of connections to also make this more suitable for eg. lattice structures.
  • Option for larger numbers of sides per strut (probably just multiples of 4 for now).
  • Remembering settings between command calls
  • History support

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:


(I think maybe it makes sense to always have these radius values be mirrored along each strut, so that the direction of the input lines doesn’t matter)

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.

9 Likes

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.

1 Like

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… ).

1 Like

How’s Thicken Curves any more acceptable than ‘Gordita’ in Rhino Español? :crazy_face:

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 … :grin:

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?

Hi @davide76,
Can you share a file where it is not giving the desired result?

Nodes are not generated at the intersection points (the pipe portions are untied).
The command should generate this kind of pipes:


In addition, the command does not remember the diameter of the pipe entered: it always returns to 1.
Not nodes SubdThickenCrurves.3dm (113.2 KB)

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.


In fact, it would be great if the number of output subd segments was equal to the number of reference line contorlpoints
2 Likes

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!