Medeek Stair

I think the time has finally come where I split out the stair module from the Medeek Wall extension. One could argue that the stair module probably could just as well fit within the Floor plugin but I think it makes more sense to eventually make it its own extension due to its complexity and the need to add even more features and perhaps one additional toolbar.

Until I split it out fully it will remain within the Medeek Wall extension however any updates or additions to the stair module will be notated and logged here. The current thread for Medeek Wall is getting very long so that is reason enough to create this new thread for the stair development in my opinion.

After some additional thought what is lacking is a railing or balustrade tool. So for the next few days I will work on that and see if I can come up with something that pairs well with the existing stair tool.

My first question is the name of this new extension, should it be singular or plural? Stair or Stairs? I’m leaning towards Medeek Stair (singular).

Before I even start putting together the nuts and bolts of the railing tool I need to figure out what is the most common configurations that the tool will need to handle. Below is a sampling of various balustrade and railing configurations:

My key take away after studying railings for a few minutes is that we can roughly divide railings into interior stair railings and deck railings.

With stair railings we are usually dealing with OTP (over the post) or PTP (post to post) railings. Also since this will be a polyline tool will need to separate out the following post designations: Start, End, Corner and Intermediate. All, some or none of these posts may be present in the railing at these positions, additionally each one may be OTP or PTP.

If a post is not present at the start or end of a railing (straight or polyline) then it may simply end (terminal end) with a straight cut or it may have an angled/beveled cut. Additionally it could terminate with a fitting or a rosette (note the railing segments between the arches).

Corner posts may also be present (or not). With PTP things seem pretty straight forward but if the corner posts are OTP, then a fitting will probably be used (45, 90, 135 deg.) and the post will be slightly out of alignment with the balusters as shown in the image above.

With intermediate posts the same applies. If the post is PTP then the railing will simply be bisected by this post. If it is OTP then a tandem cap fitting will be used. Intermediate post spacing will be calculated and will approximate the intended spacing. I’m not entirely sure what algorithm to use for that yet.

Balusters will be very similar to the existing stair tool, with the inclusion of baluster shoes. However baluster spacing will need to be calculated for each polyline segment and may or may not be the exact spacing. Also a shoe rail option will need to be added.

Deck railing is a completely different topic/discussion.

Here is a first look at the proposed Edit Menu for the Railing Tool:

The options shown are for typical stair railings (balustrade), additional options or parameters along with additional sub-menus may be added for Deck, Glass and Cable railing types:

BASIC OPTIONS:
Railing Name:
Railing Type: Balustrade, Deck, Glass, Cable

HANDRAIL OPTIONS:
Handrail: YES/NO
Handrail Profile: Circle, Square, LJ6000, etc…
Handrail Height:
Handrail Size:
Handrail Ext. Start: 0.0
Handrail Ext. End: 0.0
Handrail Material:
Handrail Fitting Start: NONE, PTP, LJ fittings etc…
Handrail Fitting End: NONE, PTP, LJ fittings etc…
Handrail Fitting Corner: NONE, PTP, LJ fittings etc…
Handrail Fitting Mid: NONE, PTP, LJ fittings etc…

START POST OPTIONS:
Start Post: YES/NO
Post Type: Circle, Square
Post Height:
Post Size:
Post Material:
Post Profile/Comp: NONE, library components
Profile Segments: 12
Bottom Offset: 0.0

END POST OPTIONS:
End Post: YES/NO
Post Type: Circle, Square
Post Height:
Post Size:
Post Material:
Post Profile/Comp: NONE, library components
Profile Segments: 12
Bottom Offset: 0.0

CORNER POST OPTIONS:
Corner Post: YES/NO
Post Type: Circle, Square
Post Height:
Post Size:
Post Material:
Post Profile/Comp: NONE, library components
Profile Segments: 12
Bottom Offset: 0.0

INTERMEDIATE POST OPTIONS:
Middle Post: YES/NO
Post Spacing: 60"
Post Type: Circle, Square
Post Height:
Post Size:
Post Material:
Post Profile/Comp: NONE, library components
Profile Segments: 12
Bottom Offset: 0.0

BALUSTER OPTIONS:
Balusters: YES/NO
Baluster Type: Circle, Square
Baluster Size:
Baluster Spacing:
Baluster Offset List: “empty by default”
Baluster Material:
Baluster Profile/Comp: NONE, library components
Baluster Profile/Comp 2: NONE, library components
Profile Segments: 12
Baluster Shoe: NONE, library components
Bottom Offset: 0.0

SHOERAIL OPTIONS:
Shoerail: YES/NO
Shoerail Profile: NONE, library components
Shoerail Width:
Shoerail Height:
Shoerail Material:

As one can see there are a lot of parameters and the menu will be very “busy” similar to many of my other menus, but that is the price you pay for making these plugins “complete”. Let me know if you see anything I’m missing here or something that could be presented in a more logical and efficient manner.

The handrail fitting parameter for Start, End, Corner and Mid will determine largely what happens when a post meets the handrail.

If None then the handrail is continuous and is not modified by the post.

If PTP the handrail will receive boolean subtraction from the respective post.

If set to a OTP fitting, the fitting will be inserted and the handrail will be trimmed back the appropriate amount. For intermediate (Mid) posts the fitting will always be a tandem fitting. For corners there will only be an option for a set number of angles.

The original stair toolbar will be expanded to include three new railing icons/tools:

wallstairssumenuactive

There are a lot of parameters for a railing so it will probably take a me a few more days to coble together the draw and edit functions. I’ve completed the HTML menus and the attribute library read and write methods so progress is steady.

The focus right now is on a typical classic stair rail (PTP and OTP). However once I complete that I will need to add the other three options: Deck, Glass and Cable.

In many ways the railing assemblies will be very similar to polyline stemwall assemblies, with the ability to move segments once an assembly is created.

One stairs you didn’t show is how many Cap Cod homes in New England are. Entering the front door in the middle of the wall, the stairs are directly in front and go up into the ceiling. The stairway serves as a divider between the two front rooms. Sometimes there are railings on both sides, sometimes only one side with a floor to ceiling wall on one side.

Send me an image of this type of staircase. I think you can already do this type of configuration.

This one goes into little hanging spandrel walls instead of continuing up into the ceiling:

This one is the same, but a mixture of wood and iron:

I think that norm will be these little banister height walls at the transition where the stairs go up into the ceiling (otherwise what would the spindles anchor into?) The AI says these can also be calls wing walls or drop walls.

So likely I’m worrying about nothing.

One can adjust the hand rail extension variables which should allow for this type of configuration. I will have to experiment with it further, and then post a few examples and maybe another tutorial video explaining the procedure.

Right now I am testing out various algorithms for the just the hand rail portion of the railing. OTP handrails should be fairly simple, there will either be a fitting installed or the handrail will simply miter at the corners. However PTP (post-to-post) handrails can be a bit more complicated.

When the railing edges or segments are all orthogonal things remain straightforward however what does one do with square posts at non-orthogonal corners like the one shown?

Should the post be rotated 22.5 degrees to split the difference?

If the post is round and symmetrical then there is no question about rotation.

Also for textures to be applied correctly the handrails need to be drawn parallel to the X axis and then rotated into position. A simple detail but in the long run it will be worth it.

I would go with Medeek Stair, this is consistent with your current naming of each module. Ensuring consistency.

Would it be worth considering individual offsets should the user, use two types of balusters in their assembly.

Also think about the potential of a balcony railing layout where this a right angle return on either one or both ends.

Are you considering using the polyline algorithm to be able to create railing?

You might want to consider the addition of top fixings for all metal balusters much the same as the bottom fixing, allowing users to create their own fixings as components.

I’ve made some progress on the handrail algorithm and I’m bringing in fittings now however when it comes to corner fittings I will need to employ a more advanced algorithm to detect corner angles and insert the appropriate fitting which may override the user specified fitting:

After some more fiddling with the code and some additional logic, here is an OTP rail with various fittings and various corner conditions:


I will also be including a new series of hand rail fittings that is compatible with the LJ6000 handrail profile.

Revisiting you asking for advice on the name of this plugin.

It just occurred to me that it should be Stairs - plural! I can’t think of a time I’ve heard of or used the singular “stair” - with the possible exception of when talking about 1 stair in a set of stairs (or stairway) needing repair?

I agree Medeek Stairway sounds better because it will create more than stairs.

IMG8945

All I think now.

I think I have the post algorithm mostly worked out now. The PTP posts use boolean subtraction against the hand rail since we can’t be certain of their contact angle or if they are square, round or some other non-standard geometry (custom components).

The problem with boolean subtraction is that if you are a dealing with a lot of rail segments and posts it can slow things up a bit. I may have to rethink this or have a way to disable the boolean subtraction for those who prefer performance over cosmetics.