Medeek Truss

Version 3.8.2b - 05.21.2026

  • Fixed a bug with the complex roof draw tool and metric units.

Version 3.8.3 - 07.29.2026

  • Enabled the following method within the Medeek Truss API: truss_set_attributes

Finally back to SketchUp, it feels good to be back in a comfortable saddle.

This time I’m revisiting the algorithm I use to generate the primitives for complex roofs. The legacy solver is fine more than 95% of the time but there does seem to be that odd roof that causes it to fail. Here is an example:

I’m still not quite sure why it fails so spectacularly but I finally had enough and I am now seeing if I can’t rework my straight skeleton algorithm into something a bit more robust. So far the results are already promising, here is that same roof (primitive only) with the new straight skeleton algorithm.

This may take a few days as I really need to try and break the algorithm so I can find all the weak spots and systematically eliminate them all.

Well, it didn’t take me too long to break my new algorithm, here are some tests that proved useful:

The equal pitch algorithm seems to work reasonably well now. The question is what happens when we throw in some unequal pitches.

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.

The thing is, all of those are of one special case of one single plate height for all the rafters to spring from. Here’s a simple example of the intersection with different plate heights:

I declined a prospective job that was thousands of square feet, had dozens of these intersections and flat roof portions where roof peaks would get too high. It was giving me panic attacks just looking at it. Figuring out roofs can be a bottomless pit if you’re looking for a universal solution.

It is not so much the single plate height as it is the gutter line or sub-fascia elevation. I am aware of this limitation and have given it some thought for a few years now. I’ve even put out a video discussing the issue about three years ago.

I don’t think it is an insurmountable obstacle but I still have not come up with the solution yet. However that may change…

The roof overhangs make things especially “interesting” when it comes to discontinuous fascia:

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.

A few more complex roofs with offset fascias.

I’m now studying what happens when you have these discontinuities at the sub-fascia. There is only ever two possibilities (outside corner and inside corner). There is a high and low end at each discontinuity, the end treatment depends on whether it is high or low. It is not a trivial problem but at least it is deterministic.

If it’s deterministic then I can code it…

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



Keep it up Nathan and Medeek Truss will be drawing “window peaks” on dormers before long. Thanks for the continued improvements.

Wow, that is an amazing piece of architectural complexity there.

Lets face it, at some level I will have to admit defeat, many of these roofs just get to be too much even for my most convoluted and well thought out algorithms, but I will do my best to make them as flexible as I can.

There are a lot of special cases that must be considered when calculating the sub-fascia and rake boards, especially as we combine hip roofs with other roof plane options (Gable).


Currently working through all the possible cases for soffit and fascia. It is tedious but progress is being made.

Just a few of the roofs I’m testing to see if I can break anything.

Notice the overlapping inside corners. If I can pull this off we should be able to construct about any type of complex roof. I now only need a better dormer module and a polyline porch/shed roof tool. I thought after five years I would be done developing these extensions, its been almost 11 years now, and no end in sight.

Gutters are surprisingly simple.