As per the title, if it hasn’t already been asked for, a Tube component to work like Rhino’s native Tube command might be nice as a shortcut to making two circles, a boundary surface, extruding and capping.
The component could have a base plane input, two radii, a height which might accept either an interval or a single number (with 0 as the interval start), and a cap option perhaps…
Anyway, just thought I’d throw it out there if it hasn’t been asked for already. To be honest, I don’t have time to follow all the developments/requests in this category, so if it has, just ignore this.
No, it doesn’t do the same thing as Tube. Pipes are simple one-wall objects with a cap or not but can follow a curve. Tubes have an outer and inner wall and a wall thickness (i.e. they are solid but hollow objects) and are based on straight cylinders. (although if one could “tube” curves like one can with pipes, that would be cool…)
I would like the same for a Helix component. There is a Helix command in Rhino.
Honestly, I feel most Rhino commands should be wrapped into a GH component. Having to resort to Python or C# components just to call the command from Rhino seems like lazy development. Delete all GH components and just force users to use C# and Python component.
Honestly, I feel most Rhino command should be wrapped into a GH component.
AFAIK the dev team for GH is small and focused on GH2
GH doesnt update as fast as Rhinocommon
Rhino command are often compound methods not just single things from Rhinocommon. For instance recently we learned that Rhinocommon has unroll, but Rhino itself first does Shrink Trimmed Surfaces, then Unrolls. etc. Rhino commands consist of multiple things together, much like Grasshopper components.
Some things are not directly translatable form one to the other for multiple reasons, a main one being mouse clicks, and mid command prompts.
That being said, the only reason I could see tube not being there isn’t from any limitation but time and resources / priorities.
Also, I am not taking about new commands being available in GH as soon as they are in Rhino. I am talking about long existing commands that have never been translated into GH. I feel this issue is also connected to the recent threads about users, who are looking for basic functionality, being forced to use plug-ins because of GH lackings.
I know that, I just hope more and more people are put into GH’s team and not fall behind Rhino…
I feel this issue is also connected to the recent threads about users, who are looking for basic functionality, being forced to use plug-ins because of GH lackings.
Whether you, I, or anyone agrees or disagrees, I believe this is why Rhino and GH API were left so open so third parties can fill in the gaps. Again, not saying I’m for or against (I personally am ok with it, but wouldn’t mind more native functionality). It was just the decision made.
I am OK with people adding functionality. I am not OK depending on third parties to fill in the gaps for something I paid for. There should be no gaps. Period. Or at least, it is McNeel’s responsability to close those gaps over time, not leave it to chance and third party development.
For example here is a hack which emulates a possible tube component. It incorporates logic to prevent the inner rad from being more than the inner rad (but not the same, that should also be included) plus the default to an XY plane if nothing is connected… Still doesn’t have switches for cap or not or both sides…
I believe McnNeel’s response would be that you can code your own component.
I think it just depends on what time is available (and if the right person sees the request) and how much effort it takes, for instance recently there was smaller components added to RH6 like Curve Middle Point. In the WIP there was SubD and Quad Remesher components added.