Bonsai "Families"

pekezoco

Hey everyone,
I’ve been exploring BonsaiBIM recently and I’ve noticed something interesting about how it handles parametric elements like doors and windows.
It seems Bonsai already includes a few predefined “families” or types — similar to Revit — for example:
Doors: swing-to-left, swing-to-right, etc.
Windows: single-panel, double-panel, triple-panel, etc.
These types come with parametric geometry, meaning I can easily modify their width, height, or even the profile thickness directly from the properties panel, which is great.
However, I’m trying to better understand how these parametric definitions are structured and how to extend them.
Specifically, I’d like to know:
1-Where does Bonsai store these existing types?
2-Are they defined somewhere in the add-on files, in a library folder, or embedded in a schema?
3-How can I add my own variations or new types — for instance, a four-panel window or a custom door operation?
4-How can I create my own “families” from scratch (I assume these correspond to IfcTypeObjects, but I’m not entirely sure), with modifiable parameters that drive the geometry the same way the built-in ones do?

I’m trying to understand whether this system is open for user-defined types or if it’s still hardcoded for now.
Any guidance, documentation references, or examples would be super helpful!

Thanks a lot in advance,

sjb007

Parametric items are coded. For example: src/bonsai/bonsai/bim/module/model/door.py
Anything that uses the parametric panel to create objects is going to be similarly generated by main application code. i.e. doors, windows, stairs, roofs, and perhaps others. Parametric items are just conveniences to easily create objects that are generic but varied.

theoryshaw

Some are in the schema, as well. Some are being depreciated.
https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcDoorLiningProperties.htm

sjb007

@theoryshaw That might be in the spec, but I don't think the parametrically driven items in Bonsai are making any use of those values when generating the representations.
i.e. the door saves it's parameters in a pset named BBIM_Door. i.e. it is entirely custom to Bonsai.

theoryshaw

I think it does follow the schema though.
That's not for everything, but for doors I think there's alignment.

theoryshaw

https://github.com/IfcOpenShell/IfcOpenShell/blob/6df5632f91653cc3bec676178b88ca2789139aa5/src/ifcopenshell-python/ifcopenshell/api/geometry/add_door_representation.py#L251

sjb007

Follow yes, but the Bonsai door implementation is unique to Bonsai. If you load a Bonsai created ifc with a parametric door into another program you will not be able to tweak the parameters because the other program does not have the same code paths generating the doors representation based on the BBIM pset. You will be stuck with the door representations last generated in Bonsai.

Mas

@pekezoco
if you want to create your own parametric objects in Bonsai, there are some things you have to know and keep in mind.
Should the assembly be editable in other software parametric - than you have to find a way to create solids or breps in bonsai/blender (Imo you have to have strong python and bpyAPI (BlenderPhythonAPI) skills and skills how to use the API in the other software.(if you want to use the parametric values)
If you want to create tesselated parts, that are editable in Blender/bonsai, till you are ready to use it as static IfcObjects you can do this with GeometryNodes (and create an Addon out of it).
I did that. https://community.osarch.org/discussion/3173/geonodes-parametric-flanges-junctions-90-bends#latest
The Nodes can be used in Bonsai and blender (assetbrowser) / appended / copied from another blendfile. If you want to create a bundle out of it you have to know or learn how to create (Blender)addons (there are tutorials on youtube, some scripts on Github, also a Addon for creating Addons out of Geometrynodes, Script Templates in BlendersTextEditor)

theoryshaw

@sjb007, i gotcha. Thank you.

theoryshaw

So currently it looks like Bonsai codifies the parameters of a door into a pset unique to Bonsai, as @sjb007 indicated.

  /*#76=IFCDOORTYPE('248S4ETCXBZO8pqQ0xtvsy',$,'Parametric Door',$,$,(#77),(#86,#164,#183),$,$,.DOOR.,.SINGLE_SWING_LEFT.,$,$);*/
    /*#77=IFCPROPERTYSET('17Sg3qAhb0ARr97MzlZA3V',$,'BBIM_Door',$,(#78));*/
      /*#78=IFCPROPERTYSINGLEVALUE('Data',$,IFCTEXT('{"door_type": "SINGLE_SWING_LEFT", "overall_height": 6.561679790026246, "overall_width": 2.9527558272904924, "lining_properties": {"lining_depth": 0.16404199719507237, "lining_thickness": 0.16404199719507237, "lining_offset": 0.0, "lining_to_panel_offset_x": 0.08202099859753618, "lining_to_panel_offset_y": 0.08202099859753618, "transom_thickness": 0.0, "casing_thickness": 0.24606300190364908, "casing_depth": 0.016404199108403184, "threshold_thickness": 0.08202099859753618, "threshold_depth": 0.32808399439014474, "threshold_offset": 0.0}, "panel_properties": {"panel_depth": 0.11482939681434255, "panel_width_ratio": 1.0}}'),$);*/

I would think, for it to be IFC compliant, it would have to codify these parameters into a predefined property-set entities like...

#214=IFCDOORLININGPROPERTIES(
  '4TzDLiningProp0000000001',  $ , 'DoorLining', $ ,
  0.16404199719507237,        -- LiningDepth
  0.16404199719507237,        -- LiningThickness
  0.32808399439014474,        -- ThresholdDepth
  0.08202099859753618,        -- ThresholdThickness
  0.0,                        -- TransomThickness
  $,                          -- TransomOffset (not provided)
  0.0,                        -- LiningOffset
  0.0,                        -- ThresholdOffset
  0.24606300190364908,        -- CasingThickness
  0.016404199108403184,       -- CasingDepth
  $,                          -- ShapeAspectStyle (deprecated / NIL)
  0.08202099859753618,        -- LiningToPanelOffsetX
  0.08202099859753618         -- LiningToPanelOffsetY
);

#215=IFCDOORPANELPROPERTIES(
  '4TzDPanelProp0000000002',  $ , 'Panel_1', $ ,
  0.11482939681434255,        -- PanelDepth
  .NOTDEFINED.,                -- PanelOperation  (use a real enum if known)
  1.0,                        -- PanelWidth (normalised ratio)
  .NOTDEFINED.,               -- PanelPosition  (use LEFT/MIDDLE/RIGHT if known)
  $                           -- ShapeAspectStyle
);

I'm curious why this wasn't done out of the gate?

theoryshaw

This conversation, is probably related, as well: https://community.osarch.org/discussion/1738/standardizing-bbim-property-sets

Mas

@theoryshaw imo than you are fast in the discussion of what parts ar Objects, how to assemble it, and that depends on the role (e.g. the producer of the door will also get the length of the seals, the number of layers, the insulation, the fixing points, screws,...) In my opinion the architect should create the opening (maybe an style of the door and the type) and replace the door with an IfcObject he got it from the vendor/manifacturer after. (and this is the final part for construction, FM...)
If Im creating an Ductsystem as the MEP/HVAC guy the needs are different from the "placeholders" the architect uses. (And thats why i dont like the actual behavior of the style-material system -- a bend of freshair and wastedair have the same material, the same type - but not the same style- so I have to create a type for every air"type" -at the moment, some costumPsets --> working nice with Templates,...). I think its sometimes a little bit tricky to pack all the needs in one solution. (But to exchange the IfcTypes and Objects, it dont need much- thats a real benefit against the 2D block none BIM practice)

RaphaëlVouilloz

That's a really interesting question I ask myself too. I think families->types is one way, among others, to draw parametricaly, which comes from the industrial sector. Revit has adapted it for AEC, but ArchiCAD for example doesn't use it. From my understanding there is no families in IFC, just types.
If you think of the family->types concept in Revit or any industrial tool such as TopSolid, families are actually not stored in your main model but work as external files. It is parts you import into an assembly. Parts may have a unique shape, or adapt to multiple shapes. To achieve this, you can declare parameters or geometries as drivers of this shape: types are actually a set of values for theses drivers.
I understand traditional IFC as an export of the "final" model, which means just with the types actually used in the project. It doesn't embed the parametric family you would have used to model them in a tool like Revit or TopSolid.
Now if you want to reproduce this in FOSS. My guess is that you could use for example FreeCAD to draw a parametric door with sketches, like in a rfa environment. Then for each type you want, for example changing the height of the door, just edit the height dimension and save in the IFC as one type.
What will not work is to edit a shared parameter of the family after import to update all types, for example changing the width of all doors. Maybe a workaround could be found.
I would like to screencast a video of this idea soon.

JanF

You mean like this?
https://community.osarch.org/discussion/793/blenderbim-parametric-based-ifc-types-doors-windows-etc#Comment_9568

steverugi

@theoryshaw

So currently it looks like Bonsai codifies the parameters of a door into a pset unique to Bonsai, as @sjb007 indicated.

yes, I don't understand why certain attributes already existing in the IfcDoor schema are stored in a property set, like
9. OverallHeight
10. OverallWidth
12. OperationType
as well as to why IfcDoorLiningProperties and IfcDoorPanelProperties (containing most of the rest) were deprecated in future release..

EDIT: but all goes under property sets (specifically for instances, not for type), so we are good to go (IFC compliant)
it remains to understand why Bonsai doesn't use them?