Each girder will break up the roof outline into zones.  Then using a combo of boolean subtraction and intersection we should be able to generate this as a starting point:




The blue shaded truss outlines are the girders, the purple shaded are the trusses requiring a further subtraction step to make the correction for the valley truss sets, notice the third purple truss  from the right. 

Basically I'm walking you through my algorithm for generating the truss geometry data so I can then draw each truss.  As you can see this is not a trivial process.  Lots of steps and lots of "edge cases" that can potentially trip it up.  That is what I mean when I say the devil is in the details.  However if the basic algorithm is sound one should be able to add in logic to deal with the issues and in the end you end up with a robust piece of code.  These are the kinds of things that keep me up at night.

Based on these slices we should be able to extract the key geometric points that define each truss and then send that data to the separate truss "draw" algorithm which sorts out all the messy details on how to place the webs, plates and all that fun stuff.

Here is a simple schematic of a slightly more convoluted roof to try and understand the methodology a bit better:

The two girders in the center of the structure could probably be combined into one larger girder, but maybe it is better to distribute the loads across to trusses instead of one.  The shaded areas are the valley sets or overframing required to fill in the voids.

This design requires 10 main girders and 5 cross girders.  Notice how there is a hip truss at each outside corner and a half valley set at each inside corner.  When to inside corners are symmetric we end up with a full valley set.

Based on these patterns that are emerging I might be able to auto place the girders or at least provide an initial placement which then can be further refined by the user.

I've been pondering how to control the truss layout of these complex roofs and after much thought and sleeping on the problem for a night I've come to the conclusion that for all but the simplest roof types (gable or half hip both ends on a rectangular footprint) there needs to be user specified girder trusses.

Even the simplest hip roof (rectangular, hip both ends) needs two girder trusses. The algorithm should be smart enough to detect the layout in such a simple case but even so the setback of those girder trusses will have to be user controlled. With my existing hip set tools this is provided as a simple numeric value since the location and orientation of the hip girders is already determined.

When you move to complex roofs the location of the girders becomes completely open ended. In other words we have too many degrees of freedom to confidently compute the solution. You can't solve a multi-variable math problem if you have more variables than you have constraints or equations. That is the nature of this beast.

My thinking is this:

1.) The user creates the perimeter or outline of the complex truss roof just as one currently does with the complex rafter module. The general roof shape and secondary features are generated (ie. sub-fascia, sheathing, cladding, gutter, soffit and fascia etc...), however the actual truss framing is not generated with this initial creation step.

2.) Next, the user clicks the girder truss creation tool which allows one to add in specific girder trusses between any two points within the roof outline (layer). The algorithm will require that the two endpoints of the new girder either terminate on the perimeter or along the length of an existing girder. Obviously the new girder cannot have both of its points on a perimeter edge or another girder, so that check will be built in. An HTML dialog box will allow the user to set a number of properties of the girder (ie. 2-ply, top chord depth, bottom chord depth, truss configuration, panel number for hip girders etc...)

3.) Once the girders are set then a context menu option will allow the user to attempt to generate the actual truss framing. If the girder layout is inconsistent, or illogical it will fail and display the applicable warning to the user. I'm still feeling this one out a bit so there may be an additional step where the user determines the rotation of the trusses in each zone created by the girder trusses.

I think I can make this work but only time and some extensively testing will tell. I think the concept is fundamentally sound but as I've learned in the past with other programming problems, the devil is in the details.

Version 4.5.2b - 05.09.2026

- Added the following (L.J. Smith) rosettes: LJ7037, LJ7027, LJ7026, LJ7033.
- Fixed a floating point rounding error in the "Move Segment" tool.
- Enabled handrailing fittings (ie. rosettes) for the start and end of a handrail when no post at these locations is selected.
- Added a left and right half-post component into the newel post library.







I tested out a half post because I've seen stair railings that terminate like the image below:

Tutorial 86: Stair Railing

I spent the better part of today trying to figure out ways to make the boolean subtraction more efficient.  In the end my best solution was to create a square "cutter" in place of the actual (ornate) post which does significantly help.

However if the face count of the "cutting" post is under 100 then I just use the original post geometry.  I've noticed that some of these ornate posts can have over 400 faces or polycounts.

Now I just need to do a few more checks and throw the kitchen sink at this thing:

I've added in an an auto-clearance calculation for the balusters that are adjacent to posts so I think I have that mostly under control now but some additional logic may need to be added depending on feedback from everyone.

Here is a first look at these various railings with shoerail added.








The offset option for each post position allows one to have the shoerail cut by the posts or rest underneath the posts.  I'm trying to make this as flexible as possible.  Also I created the four standard LJ Smith profiles beyond the very basic rectangular profile.

Due to the fact that there is quite a bit of boolean subtraction that can happen with the interaction between the posts and the handrail/shoerail combo, regenerating a railing can take a while, especially if it is much more than about five or six segments.  I guess its a tradeoff between simplicity and ornate details.

The only way to squeeze more performance out of the boolean subtraction is to convert it to a more low level C++ routine, I may consider that.

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.

After some more updating of the new railing tool code and some additional logic, here is an OTP rail with various fittings and various corner conditions:

I've never really advertised my extensions too much, most of my customers are word of mouth and since I am now fairly well known in the SketchUp community the need to advertise has never really been something I've worried about.

However, what many people don't know is that for students and educators I am practically giving away my extensions for free.  Couple that with either an educational license for SketchUp or SketchUp Make 2017 (free and can be used for non-commercial work) one can be modeling with all of the Medeek extensions and its not going to break the bank.  To that end I have put together this small Youtube Short (video), hopefully it is well received.