Designing a new window / door generator
The current parametric window / door is based on the specifications provided by IFC (commonly known as the "Standard Case"). This standard is nice, but I sometimes wonder if it's actually been properly audited by someone who works as a door / window manufacturer or architect who does door / window schedules / details :)
I think it's now time for Bonsai / IfcOpenShell to be opinionated and offer a new door / window generator using our own rules informed by users to overcome the limitations of the standard case. Ping @yorik who has tackled this many times already in FreeCAD. See https://github.com/IfcOpenShell/IfcOpenShell/issues/3537 and https://github.com/buildingSMART/IFC4.3.x-development/issues/673 and https://github.com/IfcOpenShell/IfcOpenShell/issues/4206 for existing efforts. There are more efforts already but I can't find the link now, and please check out FreeCAD's amazing work too.
What I'm hoping for:
- This will be a door/window generator that can be used purely in the IfcOpenShell API as something we offer. This means FreeCAD can benefit from it too, as well as people who want to generate doors but are dissatisfied (as some of us are) with the standard case. This is not mutually exclusive with other "geometry generation" methods. Just because we offer this doesn't mean we stop offering other methods too.
- Doors and windows are similar, and sometimes are combined in real life. FreeCAD actually does treat them as one tool, and I think this is a good idea unless @yorik tells me it was all a big mistakes :) It would be nice to have a macro "cell-based" approach like suggested in 4206, where each (potentially merged) cell either holds a window or a door, etc. Similarly terminology should be shared.
- You can either generate a profile extrusion (e.g. for framing) using text/numeric parameterics (e.g. single or double rebate, rebate depth, etc), or by specifying a profile. There must be a logic behind the axis alignment of the cross sectional profile.
Things I hope for:
- I don't like one monster "100 parameters for every possibility". I prefer highly opinionated "Wood frame door" vs "Metal frame door" that has less parameters but tailored for that typical geometry. See for example how we currently do stairs and railings. This may mean there is a "wood generator" or a "metal generator" or a "single door" generator that behaves very differently to a "double door generator" etc. It's simpler to explain and debug.
- I'd very much like to also see sliding doors and roller doors be added to our repetoire. Can't do non-residential without them.
- Apart from specifying a cross sectional profile extruded along an axis, I don't think we should support other geometry as an input. This obviously places limits (no circular hobbit doors for you!) but that's cool, later on other tools and workflows can be built.
In order to implement this, I'm hoping for some consensus behind everybody who's ever brainstormed this in the past, and some very nice clear diagrams of parameters that can later be used as documentation.
Anybody interested in helping take the lead in moderating feedback and generating the diagrams to serve as a specification for this? @Andrej730 has built a super, awesome, shape builder library that means that once we agree on a diagram, the work required into turning this into a parametric IFC shape is potentially quite easy.
and 10 others.
Comments
As a suggestion, the generator could add a property to set how much the door/window is opened. Currently this needs to be done manually and changes to the generator parameters result in a regeneration of a closed door/window.
Thanks!
Yes, the windows and doors should be able to rotate about the hinge axis without rewriting the entire representation - and they should open and close as you explore a building in 'walk mode'.
I would first think about the 'hole in the wall' define that, then think about how that hole is finished, i.e. jamb/framing then think what is going in the hole in the wall. It could be a window of various configurations and/or a door(s) or it could just be an opening in the wall or perhaps we could include recesses in walls too
Hopefully I have a little time at work tomorrow to draw some diagrams to share :)
This is a big task :) I'm actually in the middle of refactoring FreeCAD's own window/door tool. Basically following https://yorik.uncreated.net/?blog/2023-025-new-window-tool
Basically I think:
In FreeCAD, each window component has:
The window object itself contains basically a list of components, an extrusion direction, plus a few cosmetic things. Also a percentage of opening so the window can "really open" in the model :)
I'd be thrilled to try to build something common together, directly in IfcOpenShell!
I'd start on a more abstract level.
Here's a diagram on information needed for a BIM model of a door:
It's the structure of the green part we are discussing here. Some questions to consider:
And here are diagrams illustrating #3:
3D geometry of a door:
3D geometry of a window:
It sounds as though what's being suggested here is that "build a door tool" is the wrong way to go. Instead it should be more like "build-a-bear" (maybe this is a terrible analogy) where you can "build a doorknob", "build a frame", "build a panel", "build a louvre" and then finally assemble "component ABC at coord XYZ". So perhaps IfcOpenShell could build this series of mini-objects?
Door openings, window openings, and window partitions are in the IFC document. It would be nice if some of these settings match IFC, along with handles, frames, etc :)
https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcDoor.htm
https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcDoorTypeOperationEnum.htm
https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcWindow.htm
https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/PEnum_WindowPanelOperationEnum.htm
https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcWindowTypePartitioningEnum.htm
It appears to me these are more or less a practicing Architect would be interested during schematic and detailed design stage. There were discussions probably a few more attributes or components might be interested, e.g. finishes of panel, frame, vision panel (inside/outside), ironmongery (like lock/handle, hinge, closer, selector appearance / type), materials and appearance, fire rating (intumescent strip and smoke seal details) , otherwise more detailed information would be fabricator's expertise.
To this end, there are features and efforts in FreeCAD when provides the flexibility to build complex door shape - though not sure how and if FreeCAD / IFC may support e.g. door lock/handle type shape).
Another item which interest me is Stairs in FreeCAD which I am trying to have another look to refactor and provide more flexibility and features to build more complex and probably freeform stairs.
https://wiki.freecad.org/Arch_Window#Defining_window_types
https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://forum.freecad.org/viewtopic.php?t=90822&ved=2ahUKEwja673WxuKLAxXdk1YBHaBNBnoQFnoECBQQAQ&usg=AOvVaw0xZ6Ha3e7DXQDfzxiiitMv
In contrast to the complexity, I'd also prefer an option of a purposely limited but basic, few parameters, early-schematic door/window that "just works".
BTW @KoAra yes, the current implementation completely follows the IFC standardcase. For this one, any shared concepts should also share terminology.
This would certainly be appealing if feasible. Build a doorknob that you can use as both a doorknob or a window handle, build a frame that can be used for a window, door, or a simple opening; define a louvre for all openings on a building. Then combine all those "presets" into a full doors or windows assemblies, instance the knobs on the opening parts at a configurable position.
If we could modularize those at UI level too, then a full door object would have say a Frame _ UI panel with the frame settings, a _Paneling _UI panel with the paneling settings, a knob placement UI with a list to pick from designed knob presets, etc. A window object could then recycle the same UI modules (frame, panels, knob placement).
A simple opening without door or window but with a frame could use the same _Frame UI to set the jambs. Maybe the _Paneling _ UI could eventually be used to design wall panels or a wainscot.
The downside of this approach other than implementing it, is that the UI for a full blown opening will have a complex UI, but I suppose if we want a comprehensive tool we'll always end up with one anyway. To mitigate this, a new base opening could have a simple base UI that would generate a good default, then users would add complexity, as desired to not overwhelm from the start.
Great to see this post come up! @Moult, I’d be happy to contribute or even take the lead in moderating inputs for the specification. We touched on this briefly last year, and since then, I’ve conducted quite a bit of research that I’d love to share. I really see the value in your “build-a-bear” approach. As an architect, I want to define my frame and panel types once and be able to reuse them multiple times when creating door assemblies. I’d rather not have to re-enter the same parameters for different door types that share common frame or panel configurations, as this can lead to errors.
@tim go for it, please take the lead :)
Can I request that even if we do end up with a more complex but powerful modular build-a-bear set of generators, can we also agree upon a simple but limited variant? Something that new users will see like "oh, here's a door" and not have to consider much more especially for early stage design.
In terms of timing, the next release date is 5th April, so if there was some consensus (doesn't have to be finalised, after all we'll learn by doing) in about 2 weeks, that'll give another 2 weeks to flesh together a working prototype we can play with and release in this cycle.
Thanks, @Moult. I agree, it’s important to balance a powerful modular system with a simple, user-friendly version for new users, especially in early design stages.
The timeline works for me. I’ll be offline for a bit as I’m about to board an international flight, but please keep the ideas coming and I’ll catch up as soon as I can.
I'm a bit jet-lagged and still catching up on the useful information above but unless there are strong objections, it seems we're moving forward with a component-based approach for a combined door-window assembly generator. I like this direction as it balances ease of use with customizable complexity—keeping the top level simple while allowing detailed parameters within components. This should also lead to lightweight yet powerful schedules, ensuring intricate details (e.g., door frames) don’t unnecessarily inflate every instance in a model.
Based on the discussion so far, our core components appear to be:
Frames
Panels (including panes, and louvers)
Sills and Thresholds
Casings
Hardware
Are we missing anything?
Hi @tim glad you have volunteered to take the lead on this important development . from the above conversation I understand the proposal is simple / complexed. Simple is basically parametric, define the door leaf/panel, size and location. Then jamb/frame, size of the profile and starting origin of the sweep, around the left, top and right of the leaf, in relation to the void origin. The void is calculated by the door panel/leaf size and jamb/frame size. We also need to locate the axis of the door handle, this is an offset in the X from the strike side of the door, from the base of wall/floor in the Z and to face of leaf, then mirrored. Also on the Simple door we should include double doors, equal size panel/leaf and unequal. The I think once this proof of concept is done then we would add sliders, face and cavity/pocket. A third option is simply a hole in the wall with frame/jamb detail. The hole in the wall could have a recess option as well. The third stage is to add the ability to make bespoke and complexed doors, shape and style. On the subject of placement from a user perspective it is help to place a door or opening with options of left centre or right side snapping to the wall and also to the 3dcursor. Additionally at the point of insertion determining which of the 4 swing direction is a time saver. I'm sure there's more to add, but I'm on my phone at the pub so later. Thanks for reading :)
@Nigel thanks for your thoughts! My intention is not to lead us toward creating separate "simple" and "complex" versions but rather to structure the values into required and optional parameters. The required values would define a straightforward version, while optional parameters would allow for more complex configurations. We can also assist users by providing sensible default values that rarely need adjustment.
A key goal for me is ensuring that the simpler version remains accurate for the values it represents. I really like the idea of letting users define door panel dimensions, as I see this as a fundamental shortcoming in the current parametric door system.
Regarding the sweep definition, I agree with your approach. To ensure the door assembly and void are accurately represented, there should be a small gap between the inside of the frame and the door panel - something we can handle with a sensible default.
I see this as an iterative process—diving deep into the details while continuously zooming out to ensure clarity and usability. Double doors, sliding doors, and cased openings are all important and can be built out progressively, with each type filtering applicable values.
I also like the idea of controlling placement at insertion (snapping left/center/right), but we should stay focused on the specification for now rather than the implementation.
Your comment regarding swing direction is interesting. I don't know if there is a limitation with IFC that means we can't mirror a door type and handle the swing direction on the instance, rather than creating a type for each swing direction. Does anyone with more experience in this area know if IFC allows for this approach?
Similarly, defining door handle positioning parametrically makes sense and I would cover this in the hardware section.
Feedback and input welcome.
Anything that is mirrored is a different type in IFC.
@tim I was thinking of the simple/complexed in one tool but where the complexed option is 'hidden' until the user chooses to reveal all the options. Like how some photocopiers provide a decluttered interface, not sure if I'm explaining myself well. Some BIM apps have dozen settings when all the user wants to do is insert a simple door, we want to entice new users in.
The actual user options like placement methods can come later, I just had to get it out of my head, same with being able to save our preferences for door settings.
slightly off-topic
how to set IfcWindowPanelOperation in Bonsai? it's in Pset_WindowPanelProperties.OperationType
thanks
This looks good, and we could mimic this in FreeCAD. We have separate items for transparent and non-transparent panels, because it allows us to represent a window correctly even without materials applied (otherwise it's not possible), and for louvers because it uses a different function to draw the geometry. Maybe there could also be a "Custom" or "Undefined" category?
So after giving it some thought my proposal is a kind of a curtain wall approach:
1. the first parameter to choose is the 2D topology - a 2D sketch which defines panels, frames and their naming
** OverallWidth, Overall Height has to be defined every time, other properties are defined by the elements of the topology
** by selecting a simple topology you get a primitive element with a no parameters, by selecting a different one you get a complex element
Here are the drawio schemes @tim
You don't say.
Where to begin. After spending the past few days reading, digesting, organizing my thoughts, then unorganizing and reorganizing my thoughts again, I’m ready to contribute some structure to the discussion. My main goal is to keep this project focused and avoid drifting into curtain wall territory, that would be a valuable project in its own right.
To keep things contained, I’ve compiled a set of common door arrangements, including doors, sidelights, and transoms. I’ve structured them into a 3 × 2 grid, which I believe covers the majority of use cases for both doors and windows. Does this approach make sense to others?
Common door arrangements

I think a 3 x 2 grid would cover the majority of use cases for doors and windows, but what do others think?
The key challenge is defining a set of parameters that covers the:
As I started breaking down the key components of a parametric door, it became clear that door frames need more attention. Right now, hollow metal frames, a standard in commercial construction, are missing from the current system. At first, I thought we needed separate definitions for wood vs. metal frames, but after digging deeper, I realized that the fundamental parameters are the same across all frame types, the main difference lies in material and fixing method.
Instead of defining individual frame members, my proposal is to introduce a Door Frame Set at the assembly level, consolidating all necessary parameters in one place. This approach makes the system more structured and easier to use, while still allowing for key adjustments where needed.
Below is my proposal for Door Frame Set parameters. A similar approach would apply to window frames, with their own dedicated parameter set.
Door Frame Set
Designed for Single Rebate, Double Rebate, Double Egress, and Cased Opening frames.

Suitable for Wood and Metal frame profiles

Designed to accommodate face-fixed, wrap-around, and flanged frame-fixing methods (fixing details such as flanges, anchors, and straps are not included).

Supports dynamic depth adjustment based on wall thickness. Alternatively, a fixed depth can be set manually.

Properties
Name: User-defined
Description: User-defined
Material:
Dimensions

1. Thickness (Numeric > 0, Default: Undefined) Defines the thickness of the door frame.
2. Depth (Calculated: ProjectionInner + Throat + ProjectionOuter) Total depth of the door frame, measured perpendicular to the door face. This is a calculated value and cannot be overridden.
3. Throat (Numeric > 0, Default: Undefined) Represents the depth of the throat opening. If Undefined, it dynamically adjusts to match the wall thickness.
4. ProjectionInner (Numeric ≥ 0, Default: 13mm) Extends the frame outward from the inner side wall face.
5. ProjectionOuter (Numeric ≥ 0, Default: 13mm) Extends the frame outward from the outer side wall face.
6. RebateFaceInner (Numeric ≥ 0, Default: 0mm) Defines the width of the rebate face on the inner side. Typically set slightly larger than the door panel width to accommodate mounting and gaskets. If 0mm, no rebate is created on the inner side.
7. RebateDepthInner (Numeric ≥ 0, Default: 15mm) Defines the stop depth on the inner side of the frame. Only applies if RebateFaceInner > 0.
8. RebateFaceOuter (Numeric ≥ 0, Default: Undefined) Defines the width of the rebate face on the outer side. Typically set slightly larger than the door panel width to accommodate mounting and gaskets. If Undefined, it defaults to RebateFaceInner. If 0mm, no rebate is created on the outer side.
9. RebateDepthOuter (Numeric ≥ 0, Default: Undefined) Defines the stop depth on the outer side of the frame. Only applies if RebateFaceOuter > 0. If Undefined, it defaults to RebateDepthInner.
10. Soffit (Calculated: Depth - RebateFaceInner - RebateFaceOuter) Represents the remaining frame width after subtracting the rebate face dimensions from the total frame depth.
11. BaseSidelightThickness (Numeric ≥ 0, Default: Undefined) Defines the thickness of the frame at the base of the sidelight. If Undefined, it defaults to Thickness
In the current IFC door lining properties, the frame depth can adjust dynamically to match the wall depth in which it’s placed. This proposal relies heavily on that behavior. I’m unsure how difficult this would be to implement, as Bonsai doesn’t yet support it, but if we could achieve it, it would be a game changer. Would love to hear thoughts on this approach!
Can I advise having three separate systems:
For example, a single part might be a solid panel, defined by 3 dimensions, width, height, and thickness. Another part might be a door frame, defined with 10 dimensions. Notice how at this point, we don't care if the dimensions are automatic or manual. We can spec super quickly all sorts of things from kick plates to vision panels to door knobs. This is also reusable across any future casework, joinery, or similar. This can be 2d or 3d.
Then an example super simple element definition is just a panel, frame, and their relative insertion points.
Then, an aggregate system will define the elements it is compatible with and how it assembles it together. This is where automatic dimensions to fit the frame dimensions etc come into play. For example your 3x2 grid is in this category.
This separation reflects how things work in the real world, and also allows us to iterate from simple to more complex. Notice how they also match IFC... each part in the kit of parts is a shape aspect, each element is an IFC element, each aggregate is an aggregate. This part, element, aggregate approach can also work in the future with furniture, railings, fences, stairs...
If we make mistakes, we can redesign each of these 3 systems separately to minimise risk.
To accommodate the different fixing methods, the part itself remains unchanged, only the element or aggregate system needs to know this (to offset the frame).
If parts are all separate, we can allow users to define one material per part. That gives us one less thing to worry about.
I like the parameters you've come up with for frames and they match my experience doing door details. I assume although you're drawing a profile, this will be swept left, top and right edges for a door frame?
Do you think any changes if it becomes core filled?
@Moult thanks for the detailed breakdown, it’s really helping to clarify how these components fit together. Here are a few thoughts and questions on the system you described:
Would it make sense for every "part" to have at least a Name and Description, while Geometry remains optional? Would a part also require a classification, or would this not be required at this level - ie should a door knob know it is a door knob or is it just a part with a name?
I’m not entirely sure I follow the list of examples here. Since the goal is to generate doors and windows, how do members and plates fit into this system? Are they placeholders for future expansion, or do they play a role in the current scope?
This is the part I am most excited about. In most architectural software I’ve used, door frame dimensions are defined at the "element" level, which means the same frame dimensions need to be manually assigned across multiple element types. Separating them as independent parts seems like a more modular and reusable solution.
Thanks for the clarification. I initially thought my 3x2 examples were considered simple elements, but I see now that it falls under an aggregate system. So, for example, a door with a transom would consist of:
Does that breakdown align with what you're describing?
Would be nice, but I think for parts like framed glass doors, we will need two materials.
In my workflow, as long as the frame Name can be scheduled and the profile can be drawn once in a detail, I don’t necessarily need a complex 3D sweep, just a simple rectangle would be sufficient. However, there have been some com documentation phase. Would there be a way to support both simplified and high-detail representations based on workflow needs?
If needed, the user could simply assign a different material e.g. "Core-Filled Metal Frame" instead of "Hollow Metal Frame", rather than adding complexity to the part itself. Would that approach work within this framework?
In IFC, a "part" would translate to what IFC calls a shape aspect (i.e. named geometry) or constituent (i.e. named material, which correlates with the named geometry). It's basically just a list of geometric shapes that we have named. It's so generic that anybody can reuse these shapes in any context. At this level, it's purely about geometry. Maybe a better name would be a "shape" because it correlates exactly to the IFC concept of shape aspects.
A simple door/window element (right now) is made out of two shapes: lining and framing. You can see this if you add a new parametric door/window in Bonsai. You could however have a door made out of a framing, panel, vision panel, kick plate, and doorknob. A double swing door has two separate (potentially different) panel shapes. This creates an IfcDoor or IfcWindow.
A door with a transom be similar, just require more shapes.
A framed glass door consists of at least two parts (frame, defined by X dimensions + glazing panel, defined by 3 dimensions) so it can have at least two materials.
Simple vs complex is done best by having multiple geometric representation contexts at different target scales.
Classification. Naming stuff getss messy super quickly.
This is my biggest issue with your suggestion @Moult - as I said, where I live, most (all) people would get very upset to see a door with a transom or a 3x2 window as an aggregate. This is supposed to show up as a single element in a schedule.
We definitely need multiple detail levels for 3D in Europe, as I wrote above. My prefered workflow would be having an element with simplified geometry for design phase which can be easily switched for a more complex one (and back! This is an issue on its own).
If I'm correct, ifc doesn't allow mixing 2D and 3D representations as revit does. This means for 3D Model representation it doesn't matter, it only matters for 2D.
Sure, I guess the core suggestion is that there are things that can be designed separately, that each build up open the previous thing, and that they exist as a concept in IFC.
I was wrong to suggest that things like gridded arrangements must occur at an aggregate level. It should definitely be possible to have a single door element generator that has rules to handle a 3x2 grid for both glazed and door panels.
I only mention aggregate to be aware that in the future curtain walls are made out of windows, doors, air terminals, members ... etc.