Medeek Wall Plugin


I like the 2D option! I think it could be of particular use to architects as follows:

Add an action that creates what (I think) architects call “linework” grouped together and on it’s own layer.

I’m MOSDEF not an architect, but I’ve seen examples of architectural workflows which often include the creation of “linework” - a 2D representation of a floor plan with all walls outlines and symbols for windows and doors. Since you intend to include these symbols in your 2D representation once you implement doors and windows, I’m guessing it should be relatively simple to provide a way to save this separately.


I haven’t really thought about a x-ray mode since I thought the user could just as easily modify the various materials to allow for transparency, however additional feedback could steer me in this direction if that is something that could be of utility.


I like the whole idea of the model changing hands from the designer to the engineer and then finally to the contractor or builder.

Initially the designer would use first the 2D mode to work on overall space layout and then bring it up into the no-framing option to consider all of the architectural elements (ie. trim, windows, doors, siding/cladding etc…) I agree that most architects are generally not overly concerned with stud layouts, holdowns and all of the nuts and bolts that go into a design. They are the big picture guys who are responsible for selling the design, look and feel, and functionality to the customer.

From there the engineer can look into the insertion of additional wall columns and also review the headers, beams, king and trimmer qty. etc… and stud layouts. At this stage something might jump out at him, for example he may determine that a triple top plate is required because of a large truss span, or 2x8 wall studs are required due to the wind loads or wall height or both. The engineer would want to have the full 3D model with framing enabled. He is the nuts and bolts guy when it comes to safety and structural issues.

This is sometime where the engineer and architect clash. I’ve actually had to delete windows out of a design for lateral strength (steel moment frames were too expensive) much to the chagrin of the designer of that job but sometimes practicality overrides ambition and creativity.

The engineer can also enable holdowns/straps (with anchor bolts, threaded rods, coupler nuts) for specified wall panels. He will probably turn off the layers that deal with the look and feel of the building, ie. gypsum, cladding, windows, doors, trim etc…

Then the model gets passed to the contractor who then has the full details of literally every component including the nailing information for every wall panel (that is my goal).

He can quickly pull dimensions or other information from the model as needed and also be able to see exactly what was intended by the designer and engineer.

With the new layout API I am also planning on setting up some automation for wall plan generation and wall framing elevations/details. I haven’t fully defined what the end product will be in this regard but I think some production drawing automation may be useful, especially for prefab wall panel designers/companies.


As I’ve been testing the plugin and debugging it I’ve noticed that performance lags a bit when the wall gets quite long and there are a number of studs (components) present.

Speaking with some other developers, it is their opinion that it would be better to model the studs, blocking and insulation as groups rather than components. From what I understand the overhead associated with groups is less than components and the model would therefore be less bogged down once there are a lot of studs/blocking floating about.

Any additional thoughts in this regard, especially from the SketchUp Sages would be greatly appreciated.

PS: The lag was mainly due to the Outliner being left open, once this is closed up there is a marked improvement in speed.


2nd Toolbar:

Like the Truss Plugin the Wall Plugin will have a second toolbar. The planned icons/tools will be:

  • Wall Split
  • Wall Move
  • Window Edit
  • Window Move
  • Window Delete
  • Door Edit
  • Door Move
  • Door Delete

To delete a wall it is just a matter of deleting it from the model, all windows and door embedded in that wall (group) will of course be automatically removed as well.


I’m throwing this out for discussion - not advocating it!

In the interests of UI simplicity, is not a door a special case of a window with a bottom height on the wall of 0?

If so, could not the Edit/Move/Delete options for windows and doors be merged?


hmm not sure. A window has a plate at the bottom of the wall. A door doesn’t.


Could the plugin not infer that from the bottom height?

As an edge case, what should the plugin do with a window whose rough opening bottom height is less than the thickness of a single plate? And yes, I’m aware that this case is one that I’ve never seen in the real world, but edge cases are important when you’re programming.


so… an opening modifier? I can see possible issues with the merge in placement of doors and windows. If openings aren’t separated as doors or windows the program wouldn’t know which goes where.


Interesting point. I suppose a full height window is very similar to a door opening however the only difference would be leaving the sill plate (bottom plate) intact.

The other issue is trim both exterior and interior and how these are dealt with differently.

I still like the idea of separating the two but I do see the logic behind this argument.


As I said when I raised this, I’m not advocating for either position. The merge appeals to me in the never ending quest for UI simplification, which I consider a good thing provided it doesn’t compromise function. Yet I could imagine that there are good, real world reasons to keep them separate. Hence I raised the possibility. I’m sure that either way you go, it will accomplish all it need to accomplish.


After giving it some more thought I’ve decided you are right.

There will be an icon to add a new window or door but the icon(s) to move, edit or delete one of these openings can be the same icon.

The second toolbar will be:

  • Split Wall
  • Move Wall
  • Edit Opening
  • Move Opening
  • Delete Opening


A quick preview of the Window Tool (locating only):


Exterior trim can get very elaborate based on some work I’ve seen and also some recent renderings sent me of some exceptional architectural work.

That being said I’m wanting to start off simple with the exterior trim and then as things progress keep adding more options and layers of complexity as required.

For doors and windows I’ve come up with the following basic trim parameters based on my own observations and also suggestions from you, please review and comment:

I typically don’t see any sill trim at the bottom of doors, but that may be an option if necessary.

I am planning on placing the trim flush to the framed opening unless someone thinks I should add an additional parameter for a reveal.

I like the idea of having the header, jamb and sill all independent widths for total flexibility. Each of these 11 parameters can be set to a default value in the global settings, but adjusted for each door or window.

As for color (material) and layers, those both can be set in the global settings as well. The layer cannot be adjusted in either the wall or opening edit menus however the material will be allowed to be adjusted in the window or door edit menus.

If the cladding or sheathing is not enabled for a wall then the trim will not be drawn, however the parameters will be stored in the library for that opening if they are entered (ie. trim enabled).


I’ve been looking at some screen shots from Chief Architect and giving some thought to framed opening headers and their trimmers.

Beyond the myriad of options I am already providing for window and door headers I may need to extend the list to a few others.

The current list is:

(2) 2X4
(2) 2X6
(2) 2X8
(2) 2X10
(2) 2X12
(3) 2X8
(3) 2X10
(3) 2X12
1-3/4X7-1/4 LSL
1-3/4X9-1/4 LSL
(2) 1-3/4X7-1/4 LSL
(2) 1-3/4X9-1/4 LSL

For larger doors (garage doors) glulams are fairly typical in my neck of the woods. If the designer selects glulam an additional menu will pop up that allow for the selection of the exact glulam size. I’ve already implemented a similar feature in the Truss Plugin for glulam rafter roofs.

I think it might also be interesting to provide an auto calculate feature based on the width of the framed opening:

  • AUTO 2X
  • AUTO 4X
  • AUTO 6X

This is not an exact engineering solution since we don’t know the loads on the header but it could at least get it ball park. Future releases of the plugin will have more engineering capabilities added so that one can actually run the actual numbers on a header (I’m think Forte type software here, one that I commonly use in my own practice).

Along the same lines another parameter should be added into the global settings to allows for auto-calculation of the door/window trimmer qty., again this would be based off of the width of the framed opening and also factor in whether the wall is an interior or exterior wall.


Another preview showing the insertion of windows and some other features:

View model here:


I’m only about 2-1/2 weeks into the actual development of this plugin so realize that I’ve only just scratched the surface. With the latest preview video I am getting a lot of questions about other wall systems. Initially I will release the plugin with the conventional light wood framing but subsequent developments will also look at steel framing, CMU, brick and other more exotic methods as the demand arises.

The framing option will currently be:

  • Yes/No/2D

This will probably be expanded to (or some other variation):

  • Lumber/Steel/CMU/None/2D/etc…

I still have a lot of work to do before I can release this even to the beta testers.

The current pre-release “todo” list is:

1.) Wall and Window edit, move and delete functions/Tools.
2.) Global Setting tabs for Window and Door settings.
3.) Rudimentary Door and Window plugin that integrates with this plugin tightly.
4.) Wall Move and Split Tool.
5.) Add air gap parameter for the cladding (ie. brick fascia).
6.) Auto corner configuration
7.) Polyline Wall Tool and Face Wall Tool (right now all you can do is create a single segment at a time).
8.) Final clean and addition of any additional parameters to the Global Settings.
9.) Further refinements to the Add Window and Add Door Tools.
10.) Gable/Shed Wall Tool.
11.) Add glulam beams to Window and Door header options.
12.) Update Wall Plugin web page.

I’m sure there are other items that are probably missing from this list but those seem to be the major items right now.

I probably should have just left them but the blocking and insulation algorithms were complex and so it took me a couple of days to figure them out and then commit them to code. At one point I just had to start over since my initial algorithm was too inefficient and the code quickly got out of control and became an ugly bowl of spaghetti for lack of a better word.

Please keep sending me your suggestions, they do not get lost. I am compiling another post-release “todo” list where all of these other items will be considered and hopefully the majority implemented.


An additional parameter for cladding will added to the advanced wall options:

Cladding Corners: Flush/Lap/Miter

This parameter becomes important for certain cladding such as brick facade where the cladding thickness is significant and no corner trim will be present to cover up the corners.

Another parameter that should also be added is an air gap, I am showing a 1" air gap between the brick cladding and sheathing in the image above.


I’ve added in the air gap and corner parameter:

I then put a wall on top of floor and stemwall foundation:

The one thing that immediately jumps out at me is that the vertical offset parameter for the sheathing and cladding probably needs to be divided into two parameters so that the offset can be set separately for both sheathing and cladding.


So actual (4x8) sheet placement for waste management and joint control isn’t a concern?