Hello,
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.
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).
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:
Contour the wall surfaces to mark the step levels and heights.
Tween the corresponding contour curves to find the mid-curves
Iteration Process starts here:
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.
Generate a perpendicular line from the Mid-points to the wall curves. (This marks the front and back edges of the step)
Shatter the contour curves on the intersection with the extended lines, (and join the edge curves to make the step geometry)
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)
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.
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.
HTH-
OB
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.
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.
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.
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.
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)
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.
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)_RE2.gh (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 https://www.grasshopper3d.com/forum/topics/problems-with-angle-force-on-polyline-using-kangaroo-2)
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)
The walking line is not necesserally in the center point of the steps nose (especially when the inner and outer curves arenāt parallel), it is generally parallel to the inner curve of the stair (for having always the same horizontal distance to the inner handrail).
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.
Riccardo,
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.
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.
Butā¦
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).
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.
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?
180911_Stairs_Type 1_v0_4_re2.gh (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.
