Hi, bypassing the problem ‘missing railing on one side’, I return to the Very Original intent of attempt to tweak the code - setting Tread Depth and Riser Height (in addition to setting Landing Depth)! The updated ArchStairs.py with this feature and some minor bug fix is attached.
Setting Tread Depth and Riser Height
The existing Tread Depth and Riser Height attributes in the properties are ‘result’ calculated from other parameters.
Now, following attributes / properties are introduced. They could be set rather than auto-generated similar to Landing Depth.
Tread Depth Enforce *
Riser Height Enforce *
What are Overridden?
The result is it overrides following cases:-
Length is ignored: The overall length would be Tread Depth Enforce x Nos. of Steps
Height is ignored: The overall height would be Riser Height Enforce x Nos. of Steps
If base object like DLine, DWire, Sketch is used, their length / height are also ignored
The above point would have issues when multiple objects are used to general ‘multi-segment stairs’ - e.g. when the 1st segment length is overridden, there would be a gap or overlapping - have idea how to treat this…later
\
Remark:
Should they be better called below?
Tread Depth Override
Riser Height Override
p.s.
You can see the ‘connecting bit’ between flight and landing is ‘out-of-sync’ - haven’t fixed yet… ArchStairs.py (47.8 KB)
Hey nice to see your stair progress, will be joining you as soon as I can get my linux mint system setup right. Got a couple random ideas about this stairs I’ll like to check with you when I am ready.
Hey lots of kudos on that stair stuff, it is really dope, works right out of the box, and so smooth, I don’t know that yet, I haven’t even tried to play and tweak the settings, it just works as expected.
So I did a new Linux re-install and tried to rebuild my system up partially somewhat,
So I had to do all the app image things one more time, but this time I organised the files in a way not to get mixed up etc.
So I just tried the file out of curiosity, and i’m not having the same problems as before. so cool. I’m impressed.
Nice work.
Your stair landing tool is pretty cool, when drawing a simple non linear shape on the ground plan it creates a landing on the ground,
this is so cool because it even provides for the possibility of creating side walks, curbs etc, and linking this with a profile tool like
railing enhances the possibilities even further. Nice development.
I don’t have much time to work recently - though i find I have been obsessed with this coding for 4 weeks or more!
(I should be working on some other ‘experiment’…)
By memory, this version:-
Should create 2 railings on both sides
For ‘multi-segment’ staircases, the railing created should now be a continuous bar, rather then segments for different ‘segments of staircases’
Now, change the width of each ‘segment of staircases’, the continuous railing bar should follow
(of cos, w/o proper ‘offset’ at those ‘turns’ between different segments…)
Currently the railing is formed by ArchPipe
Hard-coded the height (900mm by memory), offset from edge (90mm if not wrong)
But you can tweak the ArchPipe attributes/properties
E.g. you can ‘Offset End’ and ‘Offset Start’
Can customize the ‘Profile’
No separate tool to create back the railing/ArchPipe if it is deleted by accident
(can use python to do that just not automated…)
Some questions / survey hopefully can direct what should be done / more intuitive for users:-
I am hesitating where should i put the properties of the railing, e.g. height, offset…
e.g. make a new object similar to ArchPipe but with above properties
Should have a boolean “Railing” “No Railing”?
What ‘features’ are most commonly wanted for railing? ‘End Treatment’?
I have not tried to make the landing accept different width for each ‘turn’…
Or a vertical shaft of staircase repeating for 50 storeys…
or more landings / customise steps for each of the flight in a simple stairs…
Hesitating between what ideas? The way it looks to me is that railings are their own thing,
so they have their own property, just like windows can fit in a wall and have their won properties.
Perhaps what I see is how to control segmented railings.
For example there might be corners which don’t need railings on the same draft-wire that defines.
So an option similar to the windows in menu where you can add elements or subtract elements that constitute the railing as per what was selected.
But nice job.
Maybe in the meantime I just add properties in the Stairs Object to control simple railing Height and Offset. Yes could have a menu to add / remove element constitute railing - seem not having the knowledge to do it by myself yet Though you can manually create which segment of railing through python
Every Stairs Object now has attributes of OutlineLeft, OutlineRight, OutlineLeftAll, OutlineRightAll - which simply is the wire geometries of the railing you see generated by code
OutlineLeft(Right)All is simply the wire geometry connecting all its ‘last segment’ stairs railing gemetries
So if s = Gui.Selection.getSelection()[0] of your selected ‘segment’ of stairs.
import Draft, w = Draft.makeWire(s.OutlineLeft) will make a 3d wire of the railing skeleton
import Arch, Arch.makePipe(w) should make only just the segment of railing you want…
… maybe I should current Arch.makeStairs to just do the above ‘semi-automate’ it
Some ‘bugs’ / ‘features not implemented’ found more I use it … little surprise to find railing follow when stairs align Right or Center…
Ok now height and offset of individual railing can be tweaked.
I don’t know why need height on either sides be different but it looks cool and may help some corner cases
And find a ‘bug’, the ‘height’ of railing at start is different from at end… forgot the 1st riser height to add (last screen capture)
… and lazy to fix bugs in last post ArchStairs.py (59.3 KB)
In answer to your question, the (UK) construction terminology for the 180 degree ‘return’ indicated would be ‘half-turn landing’; similarly 90 degree would be ‘quarter-turn landing’; stair risers at an angle from a centre point are described as ‘winders’ - if in a full circular plan, this would of course be a spiral stair.
Hi, thanks for comments! Regis quoted D.K. Ching for ‘Half-turn’ or ‘Half-return’. There is no ‘quarter-turn’ in the original Stairs but you can create it with the new ‘feature’ I experiment in the new ArchStairs.py. If you have problem, please raise it here.
So, I would keep simple half-turn stairs like in original Stairs object in the Flight properties and call it:-
HalfTurnLeft
HalfTurnRight
Thanks and please feel free to test the ArchStairs.py and give comments! Need more architectural practitioners to contribute indeed!
The updated ArchStairs.py is attached with some other bug fixed.
(HalfTurnRight stairs used to become HalfTurnLeft on file reload !!!) ArchStairs.py (59.6 KB)
Hi, it take me quite some time reading github help, kunda/chris’ etc discussion, wiki etc.
Going through the step and making the 1st PR with Landing Depth Control. I am not sure everything is correct, noting some checkboxes in PR seem not applicable or I don’t fully understand.
Anyway, just 1st attempt and hope do better next time…
Good job on the PR. Couple of points:
In the commit and on Github, add the URL of the most salient point of this thread (since it is enormous) so the devs have a quick context of a discussion that they can look at (and remember posterity will be reading these commits and wondering as well).
Look up some YouTube clips about how to Rebase a commit. Essentially this means how to integrate the changes from your fork back in to the master branch (that may contain changes since you forked master). Since your PR report was warning of being out of sync with master (though I think it’s still possible to merge because there were no merge conflicts AFAICT). It’s still customary to Rebase as a good habit.
Congrats for the PR! Welcome as the newest FreeCAD developer!
I think there is an error in your PR, I added a comment on github. You should be able to fix it easily by pushing a fix on the same branch (or editing the file directly on github)
After going through this weeks’ study and 1st attempt, I have few observations / lesson learnt (jog down for myself in fact):-
I started to play with 0.17 git 13522’s ArchStairs.py… for more than 1 months (terribly slow)… size increased from about 25kb to 60kb (contain lots of added remarks along with added codes)
Then I find terrible trouble when I try to merge (single out 1st ‘feature’) after setting up github and cloned from upstream
Need to resort to LibreWriter to ‘TrackChange’ and half-manually ‘merge’ (Writer seem not very good at identifying all differences ‘correctly’)
Then, upon the attempt to merge, the upstream has more updates of cos
Now fully understand why should ‘rebase’ upon attempt to merge (still haven’t done this yet for this time)… though other comment that ‘should rebase about every month’…
Always need to test so I can find the typo… but I do not compile… tested this time on the 0.17 git 13522 (extracted AppImage) and find ArchComponent changes in latest commit is needed for the latest rebased ArchStairs.py to works… so other error…
Needs to think again better workflow…
Wondering what i should do about another 15 ‘versions’ of changes that based on 0.17 git13522…
BTW, I did not ‘fix’ the calculated Tread Depth calculation after introduction of the LandingDepth yet.
I think the ‘fix’ come around > ‘10 versions’ in my local pc.
The Tread Depth is no longer ‘calculated back’ as in original code but updated ‘directly’ when the tread depth is generated in various method in the ArchStairs.py.
The updated ArchStairs.py with this feature and some minor bug fix is attached.
