3D Truss Models

medeek

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

medeek

Here is an excellent example of a complex roof that involves multiple girders and overframing using valley sets:

What I find particularly interesting with this case is the use of the half valley set on the right hand side. Why is this? This is cause for more investigation.

This next one is a bit confusing because it shows multiple levels of roofs, but the doubled up hip is what is most interesting, specifically trusses 08 being carried by the cross girder 14 which is then carried by girder 04. The shaded region over this section is to be framed onsite per the notes, or optionally one could valley truss this out with a half valley set, I’m starting to see a pattern here and I think I know why.

medeek

The proper way to truss out the previous L-shaped roof would be the use of a “half valley”. I’ve never actually seen one of these framed up in real life but based on the layout drawings I’ve seen I know they exist. If some one has some additional shop drawing, images or even truss layouts of these (shaded red in the model below) please send me some examples.

MtnArch

Personally, I will normally just call for stick-frame fill framing in these areas in lieu of the multiple 'half-valley' trusses. I'm not sure if either way is more efficient for the framers.

medeek

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.

medeek

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.

medeek

Version 3.8.1 - 05.13.2026

Enabled a second layer of wall sheathing for common and scissor trusses.
Enabled XPS (blue, green, pink and grey), ISO, EPS, GPS, and PU foam insulation within the wall sheathing and wall sheathing 2 options.

medeek

Version 3.8.2 - 05.17.2026

Cleaned up the filed and folder structure of the complex roof module.
Enabled the truss template in the complex roof module.
Added a "Roof Family" parameter into the draw and edit menus of the complex roof module.
The complex roof edit menu now displays and allows configuration of custom roof planes.

medeek

I’m now porting the Truss plugin over to Rhino. I’ve started a separate Rhino thread here for those that are interested:

Medeek Truss

My name is Nathaniel P. Wilkerson and I am the creator of the Medeek suite of tools within SketchUp. I’m not sure if this is the correct forum or category but I am in the process of porting my “Truss plugin” from Sketch…

McNeel Forum (discourse.mcneel.com)

medeek

Version 3.8.4 - 08.20.2026

Added an advanced (weighted skeleton) solver for complex roofs.

Note that I have retained the "Legacy" solver for now. When you draw or edit a complex roof you will now have an additional parameter which will allow you to choose the solver or primitive engine. I've tested the new solver with well over 50+ roof configurations however I'm sure a few cases will sneak through.

Both solvers should yield the same result but if they do not please report that information to me via email (nathan@medeek.com).

The new solver is what is called a "weighted straight skeleton". It uses wavefront propagation. It is the "proper" way to solve a complex roof. The legacy method used a system of boolean subtractions to carve out the complex roof organically from an initial prismatic solid. Overall the legacy method is pretty good however there are certain oddities or roof geometries that will foul it up, hence the need to develop the more advanced method.

medeek

First look at a complex roof with discontinuous fascia heights. On this L-shaped roof there are actually four different fascia or gutter heights (0", 12", 24" and 36"). I'm trying to stress test the primitive solver first to make sure we can handle any and all combinations of "raised" fascia offsets. Note that each roof plane can now have its own fascia offset (positive only), so things can get a little crazy with these types of roofs.

The downstream sheathing, cladding and labels seems to be working fine without any modifications but I'm sure there will be a few more hiccups once we dive a bit deeper. The framing, sub-fascia, soffit and fascia and gutter algorithms will all need new logic to account for these more challenging configurations.

I've been mulling this problem over for three years now, maybe this time I can finally come up with a workable solution, it's not going to be easy.

immaxy

@medeek Interesting stress test. Having different fascia heights on the same roof really shows where the difficult part starts — not generating each element individually, but keeping the fascia, soffit, gutter and framing coordinated when one condition changes. Curious to see how you solve this one.

medeek

First look at some interesting roofs with the algorithm actually putting the sub-fascia where it belongs.

medeek

I'm now turning my attention to the hip & ridge caps. This has actually never been fully developed for complex roofs. I had gotten about half way into it and then Covid hit in Mar. 2020 and disrupted some of my development tracks. I went back into my code and found where I had left it disabled but mostly functional.

My previous way of mathematically calculating the cap terminations worked well for simple deterministic roofs. However my new algorithms are more general and work off of the topology itself and therefore should be more robust and actually easier to generate. Sometimes you just need to look at a problem with a fresh set of eyes.

The RVH junction or node is next, I think we can clean that up a bit.

medeek

There are still a few cases I have not yet covered for hip and ridge, but the current module should now cleanly handle about 97% of all complex roof configurations. I will now move on to the rafter framing. The introduction of raised fascia offset has caused some complications for the actual rafter framing. I now need to spend a few days unraveling that.

The possible node configurations currently handled by the new algorithm are:

HHR, VVR, VRH, HHHH, VVVVRRRR. Also the hip terminating at the eaves (corner or rake).

medeek

Version 3.8.5 - 08.28.2026

Enabled discontinuous fascia/gutter lines for complex roofs.

medeek

Tutorial 33: Multi-Level Fascia Lines (15:08 min.)

medeek

Version 3.8.5b - 08.30.2026

Fixed a bug in the gutter module for complex roofs with discontinuous fascia lines.
Fixed a bug in the primitive generation step for complex roofs.
Improved the rafter framing algorithm for complex roofs using the advanced primitive solver (weighted straight skeleton).

When you have framing enabled it should now take about half as long to edit or regen a roof. This should be a significant performance increase when using the new advanced solver (which invokes) the new framing logic.

Additionally the common rafters at a RHH junction were being over trimmed previously. That should now be resolved.

At this point I highly recommend using the new advanced primitive solver. I’ve kept the legacy solver for now, just in case, but at this point it probably makes more sense to use the new solver and take advantage of the performance improvements and framing corrections.

I’m also super excited that I have somehow been able to enable hip & ridge for complex roofs. I hit a real roadblock previously on this feature but it turns out it was actually not as difficult as I had imagined it was. It just took a slightly different approach (rather than a mathematical solver I used a pure topology approach).

medeek

Looks like I'm finally live on Food4Rhino:

Human Verification

(www.food4rhino.com)