How Do I Create an Arc Larger Than 360 Degrees?

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)

Sorry, no:

You can see the problem with Interpolate at both the start and the end. I am currently doing the math to describe the curve via Nurbs Curve PWK. I had success doing full quarter turns. I am amending it to do arbitrary angle domains now.

Yay! Success! :tada: :


Arc Larger Than 360 Degrees VR 1.gh (21.8 KB)

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)?

Now for negative domains aswell:


Arc Larger Than 360 Degrees VR 2.gh (23.2 KB)

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:

  • Global inputs come on the left side and are the only wires that are allowed to be hidden.
  • Blocks of logic come vertically ontop of each other and are made no longer than necessary. Each block has some end goal. These blocks are labelled (though not in the above - shame on me). The wires in a block are always Default. Care is taken so that they are not obscured. Relays if necessary
  • Between blocks faint wires. This is so that they do not obscure the canvas and the logic within the blocks themselves.

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

Just my opinion. Difficult to select sliders in the picture.

That’s what the file is there for. :wink: “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)” :laughing:

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… :thinking: 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.