I think the title says it all.
If I feed Arc a domain larger than 2 * Pi, Grasshopper is like, “So, I heard you wanted a circle.”
Can I make a degree 2 nurbs curve that is like a helix flattened down?
I think the title says it all.
If I feed Arc a domain larger than 2 * Pi, Grasshopper is like, “So, I heard you wanted a circle.”
Can I make a degree 2 nurbs curve that is like a helix flattened down?
I’m not sure if this is what you wanted.
HelixCrv.gh (7.0 KB)
Thanks. No. Flattened. I am not sure if Interpolate gives a clean helix at the start and end.
Edit: It does not.
How about this one?
HelixCrv.gh (12.1 KB)
Yay! Success!
:
Now just to clean it up to make it pretty.
Edit: Okay, so it doesn’t do negative domains, but that’s not the worst.
@jessesn Why does the regular Arc component produce 1 span up to 90 degress, 2 spans up to 180 degrees, and 4 spans up to 360 (without 3 spans between 180 and 270)?
Hi @Volker_Rakow,
I think your very short an precise German-Like written answers contrast with using hidden wires, which make it difficult to read your code and let a lot of room for interpretation and possible confusion.
I follow a rather strict convention when it comes to wires and my scripting layout:
There is a hierarchy of importance. The wire display follows this.
Still unclear code to me.
My convention saves me thinking. In a larger context it serves me well.
Select the two sliders and all wires are visible. If that still does not help and you cannot follow two hidden wires… ![]()
Just my opinion. Difficult to select sliders in the picture.
That’s what the file is there for.
“Arc Domain” is attached to Radians, “Arc Radius” to Division So much logic is hidden in the expressions that even with the all wires shown you couldn’t make sense of the picture.
Unfortunately can’t open the file with the phone (yet).
Usually I write the expression in the input, but this surely has disadvantages.
Are you doing this vertical layout for the forum picture, or do you work like this?
I know that when definitions get bigger, it is difficult to organise them. It may be always a trade between clean and clear. Anyways - not trying to convince you to do or not do something. Thanks for explaining your logic.
I know that many people use the Expression component itself to be explicit. I remember @inno recommending it. For readability, it is unquestionably better.
I do do it for the forum picture, but I also do it for myself. In the middle of working, the canvas is a mess. As soon as I have a block of logic that is complete, however, I group it off and order it vertically. The final adjustment of components and picture perfect alignment of groups comes in a last pass.
Thanks for explaining. I get your point.
I meant writing the expression in the input, not using the expression component. Like changing the B in the division component to /2. This surely just helps, if the expression is short.
Yes. Not for something like “cos(x/Ceiling(2*Abs(x)/Pi)/2)” ![]()
I did at some point add the expressions as tiny scribbles beneath components. I could have done that here * = cos(x/Ceiling(2 * Abs(x)/Pi)/2)
No:) Maybe something like a method name could work? In c# you would probably call it arcWeight or so? I barely use so long expressions.
You know…
what bothers me about the Expression component is the real estate it gobbles up in comparison to nick-name components. However, you could do the expression on a container (number or otherwise) and then write the expression into the name of the container and set the container to “always draw name”. At least the text is smaller this way.
Personally, I would prefer:
Obviously, I’ve only done the one container here. Either way, it’s a lot of extra work. Guess that’s why programmers fail to comment their code. Or provide user documentation for their plug-ins.