Anemone: Creating a Staircase between two curves

I am trying to create a staircase between two double curved surfaces, but the two surfaces (curves) are not parallel. So my steps will not all be the exact same geometry hence I need to iterate through a series of repetitive steps to generate the Stairs (or steps).
I made a definition in GH that generates the steps, and I clustered it, copied/pasted it a number of times - which is not the smartest thing to do if I need to change the number of steps or if the double curved surface change.

I tried using Anemone to loop the cluster definition but it failed - giving nulls - for some reason. I am not sure if I’m using Anemone correctly though and this is where I need some help.

I attached a screenshot of the clustered definition and my try of Anemone Loop definition. If anyone is familiar with Anemone loops, i’d appreciate if they can help me with the Anemone definition to get it working.
I’ve also attached the GH files, with embedded curves.

180901_Stairs_Type (79.2 KB)


Hi Akabbara,
Can you upload your geometries too? (or internalize them in the .gh file)

Also, other than anemone, are the plug-ins needed? Because I don’t have them but i think it’s possible to do what you need without them, if your definition is clear enough (otherwise you can explain here how the steps are made).

Hi Riccardo,

Thanks for your prompt reply.
Attached is the GH file with internalized geometries needed.
For the other plug-ins, I used the ‘Divide Length’ component from Paneling Tools, and the ‘Close Curve’ from Pufferfish, but I think you can do without them.

A quick explanation on my definition, to get the steps:

  1. Contour the wall surfaces to mark the step levels and heights.
  2. Tween the corresponding contour curves to find the mid-curves

Iteration Process starts here:

  1. Divide the Mid (tweened) curve into equal lengths (which is equal to the Step Depth @ Mid-way). We only care for the first two points on the tweened curve (index 0 and 1) in each iteration, for the step we’re working on.
  2. Generate a perpendicular line from the Mid-points to the wall curves. (This marks the front and back edges of the step)
  3. Shatter the contour curves on the intersection with the extended lines, (and join the edge curves to make the step geometry)
  4. Move the back edge of the step (line) one level up (to the next contour level) and find the intersection point between the moved line and the mid-curve.
  • a- Generate a perpendicular line from this intersection point to the wall contour curves. (This marks the front edge of the consecutive step).
    Note that this line will not be parallel (or the same as) the moved line from the previous step because the curve has changed at this point, hence why we’re doing this iterative process for each step.

  • b- Trim the mid-curve at this point and divide the remaining length (again) to equal lengths (back to Step 3)

I hope this is explanation is clear

180901_Stairs_Type (104.3 KB)


Not sure this is close to what you want, anyway this version is without iterative process like anemone.

180901_Stairs_Type (162.1 KB)

1 Like

In Sweden we use(d) very simple rules for defining stairs (in my youth we had a wood shop making stairs and windows and anything really):

  1. Step height: min/max 150…180 mm, IIRC
  2. Step length: ~250mm along the
  3. Stepline, wich is located 1/3 from the “outer curve” of the stair.
  4. The above (plus “rest planes” if any) determined the total length of the stairs.

Fig. Eyeballing the proportions (steps would of course overlap, but here only the “non over-shadowed” step-width 250 mm is shown):

The red line is… well a red line, meaning, “do not shift steps exactly in the corners”. Instead, move away a bit from the corners (both inner and outer corner), say 50 mm or so, and adapt the “step line length” to even out. In this way one step will "bind " the corners together vertically to fixade the sides (if making grooves for the steps).

At the time (up until the early eighties) we drew the stairs like this on huge paperrolls rolled out on the shop floor, pretty close to how I would draw it in Rhino today, except for the paper.

Before I die I hope I will have the time to make my own stairs plugin in Grasshopper. :slight_smile:

// Rolf


Your discussion is interesting - and way over my head. I can however, chirp in with my wobbly memory that code says the narrow end of the tread is can be no less than 6".
You need to confirm this with your local code, but I’d hate for you to win this challenge, and then get blindsided with a parameter you hadn’t seen coming.

Interesting. I don’t have acccess to the ISO-standard (costs ~$50 to download), but thirty years ago I hadn’t heard of any inner thread (since the outer thread, 1/3 alt. 350mm from the outer curve, will more or less determine the inner thread anyway, at least for std width stairs.

Perhaps that constraint has come up later? Or, as you indicate, it may vary in different countries.

// Rolf

Hi HS_Kim,
Thanks for your reply and giving it a try, but this is not exactly how it should be.
Your definition produces skewed stairs and as you go up the stairs they become longer and more skewed, which does not comply with the standard code. You can see it from the Top View.
Also, head clearance should be considered.
The stairs would need to be perpendicular to the walls (as much as possible) which differs from step to step
due to the double curvature of the two wall surfaces, I would think the only way is to calculate the edges one by one through an iterative process.

Should be like this:

I understand your concern, but IMHO, the problem is It’ll be harder to follow the standard due to the fact that your inner wall was curved drastically toward the end.
It would be difficult to make end part steps without a few exceptions or modify the curvature of the inner wall.
You may be able to tilt the end of the inner wall so that the inside of the last steps don’t overlap, but It’s a little difficult form …Or it may be a way not to make a step in a straight line.

1 Like

This is not always a problem. The most important thing - except for any codes stipulating a minimum inner step-length - is that this inner length is long enough to be able to carry the load of each step (expecially if it is an open stair with no vertical supports between the steps).

In any case, since the steps are on different heights, each step can be fastened even if “stacked on top of each other” even to a fairly slim pole (if the pole only have a radius big enough to provide a steady enough anchor carrying the load of each step).

You will in fact often end up with overlaps in sharp inner corners, sometimes only for the reason of increasing the self-supporting strength of the (inner) sides, if they’re not supported by a pole or wall.

It may well be that one would have to use an iterative approach to “even out” all distances, especially on the inner curve or path, in order to meet all the dimensional and load constraints that may apply. This is a very interesting problem.

// Rolf

Hi again,
It seems I’m late :sweat_smile:

You description about your algorithm was very good, I just followed the steps (marked inside definition, I’ve added comments also)

Just some things:
Point 3: Instead of equal lengths i did “divide distance” as i thought it is better, you can change it easily.
Point 6-a is almost not needed, I mean, the 2 lines (of the 2 different steps, one directly above the other) are almost coincident, other than almost parallel… recalculating it every time is almost… useless. I did as you said anyway.
Point 6-b: you can’t do that, the “mid-curve” (done with tween) is different for each step, you can’t “shorten it” and “reuse” it every step; you have to use the line from 6-a to cut the next mid-curve of upper level (never used before)

180901_Stairs_Type 1_b (1) (73.1 KB)

I think we could solve the problem about last posts (@HS_Kim 's and somehow also @RIL 's) by simulating the whole thing.
Iterative-math methods like this are somehow “blind” , not farsighted. Each step greedily “eat” space up to leaving no more for space or shape/proportion for subsequent steps…
A simulation method would take the whole shape, every detail, into account simultaneously, and you can give a minimum size for inner curve to avoid bad overlapping.
I’ll give it a try.

Something like this:
The curves are used as “rails”…
During the .gif i’m playing with the force sliders… i think the result is somehow “smoother” … the inside of the curve is more uniform.

Maybe this is excessive, but hey, it’s another way!

(I have to “untangle” the definition a bit before posting it… tomorrow.)


OK, I didn’t make it as fancy as Majewski, but with this approach the angles can be finetuned along the inner wall. Sliders for Max angle from the outer wall, and constraint to Min StepWidth (inner wall) to avoid overlap, and playing with the number of iterations one can stop the “nudging” at the inner wall when the distribution looks good enough, which will affect different parts of the stair due to the fact that the “nudging” is performed in very small steps.

I didn’t have all the components installed so I made only a planar solution, not connected to any other logic which was choked anyway.

In the clip I should have set the Iterations to 800-1000 in order to get the logic going from start, but anyway.

180901_Stairs_Type 1_b (94.9 KB)

// Rolf

1 Like

Here it is:
Sliders should be used 1 to 4 sequentially (then fixing them is possible in whatever order)
180901_Stairs_Type 1_b (1) (128.0 KB)
Now it’s a bit faster than yesterday.

There are a couple of problems:
The shapes are scaled by 1/100, otherwise kangaroo2 angle forces would not work (dunno why, maybe a bug… something already seen
And I used a counter component to make some forces automatically grow gradually to their max after every reset.
If you don’t have it you can just bypass those 2 multiplication components (but you’ll have to start with sliders at minimum and increase manually)

Again, this is just a “possible” solution… it can be easily proven wrong/incorrect, use it carefully.
(if you use strong forces too much fast, some step might completely fail and mess up in order… double-check the output)


Manual correction with the help of Riched Graphmapper(double bezier)by @Dani_Abalde. :+1:

180901_Stairs_Type (60.3 KB)


I’m a french stairmaker (better in “hard” stairmaking than in grasshoppering… [])

These methods helps for finding a nice unrolled curve for the inner stringer, in the same way as the graph mapper component. The inconvenient of the graphmapper is that it is difficult to know the inner lenght of each step. Hope this will help you.


Sorry for my late response, and thanks for all your inputs and feedbacks…they were all insightful and helpful.

Your definitions (both Anemone and Simulation) are Great! Thanks a million for the help.
The simulation gave me alot of geometry issues specially with the scaling though. I preferred the first (simpler) Anemone solution. Anyhow, I still need to go through the simulation thoroughly to understand how you did it with Anemone + Kangaroo.

About your comment on Step 6-a, the 2 lines are not coincident nor parallel, they shouldn’t be since the curved surfaces on both sides are doubly curved, the point on the surfaces which are perpendicular to the mid-points (at the 2 different steps or levels) will be different, no? so they don’t give a coincident line.

About Step 6-b, that’s exactly what I meant.

Now, I made some modification to the algorithm (In Point 4) where I’d find the perpendicular line ‘from the inner wall’ to the mid-point, and then extend that line towards the outer wall. It’s a subtle difference in the stairs but provides a better solution.

However, for some reason, when I join the edge curves of the steps, it does not provide a ‘Closed’ planar curve, and the iteration stops. I couldn’t figure out why, although the curves touch at ends…Any idea why this is happening?

Attached is the modified definition.
Thanks again.

180911_Stairs_Type (58.5 KB)

Here then.
180911_Stairs_Type (60.9 KB)
See red groups for new changes (+ comments).

Again about 6-a.
As I said, it is almost not needed. I mean, the difference in the wall surfaces, from one step to the other, is small, it is not visible. Making more complex the whole designing/project just for a small detail is useless.
I’ve added a step (3.5) where the internal/external curve is sorted… so your wall surfaces could do both turns, right and left. It could be useful.
But yeah, this step can possibly make the point 6-a much more troublesome, forcing you to do what i suggested back then (back line of a step and front line of next step vertically congruent).

You must go deeper.

Let me know if you need more help.

Thanks again Ric,

I’m still having two issues:

  1. With regards to the initial line for the first step, it is nice to have the offset as it helps alot, but it’s still not taking this initial line (formed outside the loop) to form the first step. It is taking the new initial line (inside the loop) for making the first step edges. The attached image shows the initial line (in green) that should be part of the first step. Because the new initial line is outside the surface boundaries.

  2. There is an issue with step number 7 (index 6), see attached image, where it doesn’t follow the algorithm logic, making an irregular step geometry. It’s generating the step in Green, while it should produce the step outlined in Yellow.
    I guess what’s happening here, is when the iteration goes through ‘Step 3.5 - sorting the internal/external curves by their local curvature’, the curves are flipped somehow so that instead of Projecting the corner points from the internal wall onto the external wall (through the mid-points), the projection goes from the external wall on to the internal wall just for that step or iteration (crazy)…Is it a glitch?

On an another note, if I want to add a parameter to control (increase or decrease) the overlapping of the steps, would that be easier done by moving the mid-points along the tweened curves prior to shatter/joining the side curves? which means every time I’d re-adjust the overlap parameter, there would be a recalculation and re-generation of the steps…or by doing the overlapping operations outside the loop after the stairs have been generated?

Top View:

In Perspective:


180911_Stairs_Type (65.3 KB)
The sorting method of internal/external curved was not good, done another one, now it’s good (you have to test it).
Added offset for step overlapping.
For the first (and maybe last) step the algorithm need to be changed in many parts… best would be to edit them manually or to create the first (and last) step outside the iteration.