Hi there, I am so delighted at how well subD is working in Rhino7 WIP, enjoying it even more than T-Splines now that I worked out how to use the filter to select edges, faces and vertices. Its really amazing.
I’m currently still going back to running Rhino 5 with T-Splines however, for the sole use of the T-Splines pipe tool which is now a function inside Fusion360. I would so dearly love such a piping tool to be incorporated into the subD tools so I could finally uninstall Rhino5 and say goodbye to T-Splines entirely.
Any thoughts about adding a subD pipe command that would be capable of similar results? Definitely top of my wish list!
This is definitely something I would get use out of. I am guilty of booting from my old drive with rhino5 and tsplines installed just to use this feature.
I’ve used tsPipe in F360 recently too. A prime utility is (obviously) all the automated intersections.
If something similar were to make it into Rhino, of course we want to improve it over existing! The addition of cross sections to pipe functionality, if feasible, might move the needle, IMO
How to implement the crux perhaps. In the complex web example above, if cross sections where present, does the tool attempt to ‘hold’ the cross section nearest where no others exist, or does it transition from a defined cross section to a defined pipe diameter…either/or…???
The crux is formed simply by reducing the number of segments of each curve when running the tspipe command to a very low number. In T-Splines for Rhino this is a number of 1 or two, in Fusion360 just move the slider to lowest position. The transitions formed using this method are so perfect I use this method frequently with Rhino5 and T-Splines but I have reproduced in Fusion360 but it is slower and I agree with you ec2638 Rhino can do better I reckon!
Thanks for your suggestion. Found a great work around which may become my preferred method for doing this at the moment. Using the fatten command inside grasshopper, reducing the number of segments to 0 o, 1 or 2 depending on geometry in question I can then convert to subD and I’m very pleased with the results. Thanks so much for your suggestion. Awesome!
Yeh this command does an ok job for a quick result but doesn’t allow much control over the degree of transitions between curves that Grasshopper fatten command allows.
Hi @Mikie2,
There is also a Grasshopper version of the command on the way, which will expose all the sorts of settings that the old Fatten Gh component did.
That’s wonderful to hear. I just so admire all the development you guys are doing and how amazing Rhino is and always has been. Seems I wish for something and it comes true time and time again. So stoked!
Is it just me or does “SubDThickenCurves” seem like a strange name for this command? SubDPipe seems a lot more intuitive and discoverable. I’m sure I’ll get used to it, but it seems like an odd name to me.
So the Pipe command allows SubD output that will use the curve control point count to influence edge loops. This is totally separate from what SubDThickenCurves does by the way and is I bet not compatible to merge together with it. Should we remove SubD output as an option from Pipe and then rename SubDThickenCurves to SubDPipe in your opinions?
Another option might be ‘MultiPipe’
Since although it was primarily made with SubD output in mind, at some point the comand will also have the option to output meshes. In my mind the defining feature is that it handles junctions.
@BrianJ, thanks for clarifying. I was not aware that regular Pipe had a SubD output. That may be even more confusing.
I believe you should keep SubD output for Pipe since I imagine it will serve a different purpose. Can’t think of a specific use case at the moment, but since all these tools are so new, there’s a lot of learning/discovering left.
@DanielPiker, ‘Multipipe’ is not a bad suggestion. I believe it’s more intuitive and it automatically blends multiple curves into a Y-Branch style pipe structure.
From a commandline perspective, I believe it would be great if the command had the word ‘Pipe’ in it for Autocomplete and discoverability.
Hmm… I didn’t realize that the _Pipe command has a SubD output option. This complicates the naming logic but it does make me less perturbed by calling pipe with junctions “_SubDThickenCurve”.
@Mark_Landsaat has a point about having the word pipe in the name for commandline autocomplete and discoverability.
I’d be satisfied with _MultiPipe.
The only other option I can think of would be _BlendPipe or _SubDPipeBlend. This would draw a parallel to the _BlendCrv/_BlendSrf commands as they are all “stretchy”.
, it does seem way more logical doesn’t it.
