This is pretty cool! One relevant thing to add is that per most building codes in the US (based on the IBC) stair construction is limited to a 12 ft max rise before an intermediate landing is required.
Not sure if this requirement is applicable in a landscape (i.e. non-building) context…
On those stairs to the beach I mentioned, I have counted up to 30 steps per flight so maybe the rules are different outdoors? Initially, I considered counting steps in the Anemone loop but other priorities for the algorithm prevailed and I didn’t know how to handle a limit of 12 per flight (for example). Honestly though, I didn’t even try.
One determining factor seems to be the path route. Changing the path to follow a more gentle slope in a few places would use fewer steps between landings. In this case, 159 steps are required for the change in altitude so 159 steps / 12 per flight = 13.25 flights, whereas I have 18 flights… Given this path length, fewer landings would be have to be longer? And steps would have to be well above the terrain in places to make that happen instead of trying to follow the terrain as I did?
Or putting it another way, 159 steps / 18 landings would be ~9 steps per flight?
For buildings it’s 12 ft rise in total height max, not 12 risers…
But looking into it more terrain or landscape stairs are just a “feature” element and not subject to building code so that would explain your beach stairs as long as they don’t lead to a deck connected to a house or dwelling.
Summary quote from a building code forum:
“As long as the steps do not provide access or egress from a residence or accessory structure then I believe they are not regulated by the code.”
This is a quick and dirty hack, not a proposal! Similar to version terrain_steps_2021_Jul15b.gh from four days ago(though better than that). It uses the same number of steps in each flight of stairs. The number of flights is calculated based on ‘Steps/landing’ and ‘Landing’ length (two sliders).
It’s interesting to play with. I skipped trimming the extended landings for now.
UPDATE: Version ‘Jul19c’ fixes an off-by-one error causing misalignment and restores trimming of extended landings.
Next logical issue is to cull steps in the top flight if necessary to match total calculated steps required based on the Z difference between start (bottom) and end (top) of path. This approach looks pretty good! Maybe following the terrain too closely was a misdirection?
This post suggests a way to explore alternate ‘ShortWalk’ paths without too much disruption. This is not a better way to accomplish path finding, just a suggestion about work flow.
This GH file uses Data Input to get the brep surface from terrain_geo_V1.ghdata, then creates a different mesh (rather crudely) used by the same ‘ShortWalk’ code as before. Only the new path is passed to Data Output with a different ‘Destination’ file name, ShortWalk_V2.ghdata.
Next is a copy of terrain_steps_2021_Jul19c.gh from yesterday with a second Data Input to read the alternate ‘ShortWalk’ path. The ‘StepsLanding’ and ‘Landing’ (min. length) sliders are adjusted so the steps end at approximately the correct height and location.
These two parameters offer very little control of the outcome. Some flights are buried by the terrain while there are too many or too few steps for the path height. One wishes for a smarter algorithm.
And last is a copy of terrain_steps_2021_Jul19a.gh from yesterday using the same alternate ‘ShortWalk’ path. The ‘Landing’ (min. length) slider is the only adjusted parameter. The result is arguably “smarter” but the four longest flights have 37, 31, 25 and 24 steps!
Food for thought. Clearly, the total number of steps should be fixed. And maybe the landings should vary in length depending on the terrain?
P.S. This is ‘terrain_stepsV’ again but with a much shorter ‘Landing’ (minimum) value of 1.6 m. The four longest flights have 26, 17, 15 and 14 steps, though some bugs are evident where the path is nearly flat and the landings need to be much longer.