Standardizing BBIM property sets?

theoryshawtheoryshaw
edited March 11 in General

With the increasing number of BlenderBIM specific Psets, I'm wondering does it make sense to try and start to standardize these? A few for example:

  • BBIM_Array
  • BBIM_Batting
  • BBIM_Dimension
  • BBIM_Documentation
  • BBIM_Door
  • BBIM_Fitting
  • BBIM_Linked_Aggregate
  • BBIM_MirroredType
  • BBIM_Railing
  • BBIM_Roof
  • BBIM_Search
  • BBIM_Section
  • BBIM_Stair
  • BBIM_Window
  • EPset Parametric
  • EPset Status
  • EPset_Drawing.
  • EPset_Productivity
  • EQto_BodyGeometryVaIidation
  • ePSet_Georeferencing

By standardizing, other programs like FreeCAD, and others, could adopt as well. Ping @yorik.

I took a stab, here, of seeding some documentation around this concept.
...
To make it more universal, could see changing the prefix from BBIM_ to OSA_. Mocked up, here

Thoughts?

paulleeGorgiousMassimoduarteframosAce

Comments

  • Andrej730Andrej730
    edited October 2023

    What OSA stands for?
    Oh, you meant OSA like in OSArch :\

  • wmiwmi

    Given that this is hosted on osarch.org I assume OSA ist short for that and would allow other tools (FreeCAD in this respect) to use the same set of parameters. Fitting BBIM_ into the sets would give these sets a proprietary co-notation. Perhaps IOS_ might be another way to indicate sets to be used by all applications that use IfcOpenShell. I admit that I found it weird at first when there were so many entries concerning Apple's mobile operating system when you cannot even run Blender on them.

  • yorikyorik

    I'd love a cross-platform standard set of properties! I think we could have all of them: OSA_ for common OSA sets, BBIM for things that are of BlenderBIM only (I would think blender-related things) and maybe another for FreeCAD-only stuff (I don't see any at the moment). But mostly everything non strictly software specific should definitely go into something generic. I'd certainly be happy to have FreeCAD support things like automatic arrays or stairs.
    Just one question regarding your Osa_Array @theoryshaw @Moult : child objects are referring to their parent by GUID. Is that not sort of "anti-IFCish"? Shouldn't they be referenced by step ID instead? (although I like the fact that referencing by GUID does not depend on step numbers...)

    theoryshawpaulleeAceMassimo
  • brunopostlebrunopostle

    A more IFC-ish way to do this would be to list all the child objects in an IfcGroup, ie none of this two-way reference stuff.

    theoryshaw
  • bruno_perdigaobruno_perdigao

    Great idea! As for BBIM_Aggregate_Data, I think I'll change some things. I'm trying to rewrite the code to use IfcGroup as suggested by @brunopostle.

  • theoryshawtheoryshaw

    Here's a little inspiration... :)
    https://chatgpt.com/share/681a28a3-f6a0-8013-8d39-097458695dbb

  • MoultMoult

    Great idea, but just a note that epsets are a little special, they are a convention increasingly being adopted for backported functionality in IFC via psets.

  • MoultMoult

    I've raised the idea with @aothms about possibly publishing these as a bSDD dictionary, given that I've been working with bSDD recently.

    Thoughts on organisation name / code / prefix? BBIM? IOS? OSA? Bonsai?

    theoryshawLeonstrrduarteframosKoAraMassimoemiliotasso
  • theoryshawtheoryshaw

    Cool... I vote for OSA_ or OSArch_ to try and make them a little more universal, and appeal to broader OS ecosystems such as FreeCAD, etc.

    JanFLeonstrrsteverugifalken10vdltlangduarteframosKoArasjb007MassimoJohnand 4 others.
  • yorikyorik

    I'd be willing to adopt them in FreeCAD ;) The most important point would be to have a good, written specification/definition

    MoultduarteframosMassimotheoryshawpaulleeemiliotassoatomkarinca
  • falken10vdlfalken10vdl

    As a follow up from Display shadows button not respected when loading saved .blend file. #5282 . Please also consider BIMSolarProperties in order to restore the state of the solar analysis.
    Cheers!

  • theoryshawtheoryshaw
    edited October 2025


    Here's a little more inspiration... :)
    click to expand

    Chat history

    You said:

    As industry foundation classes go, could one say it's a political question of where to divide what should be included in the schema versus what should be only handled in the application?

    ChatGPT said:

    Yes — that’s actually a very perceptive way to frame it.

    In the world of Industry Foundation Classes (IFC), decisions about what should be modeled explicitly in the schema versus what should be left to applications are not purely technical. They’re political and strategic as well as technical.

    Here’s why:

    🧭 1. Schema as a Common Language

    The IFC schema defines a common, neutral structure intended to support long-term, cross-platform exchange.
    When something is included in the schema, it becomes:

    • A shared data concept that all compliant software should be able to read and write.

    • More stable and persistent over time (since schema changes are slow and deliberative).

    • Subject to governance by buildingSMART International.

    Political implication: Adding something to IFC can be seen as giving it “official” status — effectively picking winners in modeling approaches.

    🧰 2. Applications as Competitive Territory

    Application developers (e.g., BIM authoring tools, analysis platforms) often want to:

    • Keep flexibility to innovate and differentiate.

    • Avoid being constrained by a standard that moves slowly.

    • Decide on their own data structures, workflows, and UI features.

    Political implication: If too much is standardized, vendors may resist adoption; if too little, interoperability suffers.

    ⚖️ 3. Boundary Decisions Are Negotiated

    The “boundary” between schema and application is negotiated among:

    • Standards bodies

    • Software vendors

    • Industry stakeholders

    • Government agencies

    For example:

    • Should room color schemes be part of IFC, or just handled in visualization software?

    • Should temporary construction logistics (cranes, scaffolding) be modeled or just managed in specialized tools?

    These are not purely technical questions; they involve power, cost, interoperability strategy, and governance.

    🏛️ 4. Standards Lag Innovation

    IFC tends to codify what is already widely practiced, not what’s experimental. So the political dynamic often looks like:

    • Early adopters innovate in applications →

    • Industry reaches some consensus →

    • Standard gets updated to formalize it.

    This “ratification after practice” helps keep the standard stable but makes it conservative.

    ✅ In short:
    Yes — deciding what goes in the IFC schema vs. what remains in applications is as much a political and governance decision as it is a technical one. It reflects negotiations over control, interoperability, innovation pace, and industry alignment.

    Would you like me to give some real historical examples where this boundary was contested (e.g., MEP systems, property sets, or construction scheduling)?

    You said:

    Do you think software like BonsaiBIM and freeCAD could be a mechanism to tease out what should be included in the IFC schema?

    ChatGPT said:

    Yes — very much so.

    In fact, projects like BonsaiBIM and FreeCAD are in a unique position to influence the evolution of Industry Foundation Classes (IFC) precisely because they operate outside the commercial vendor politics that often dominate standards discussions.

    Here’s why they can be powerful mechanisms for teasing out what belongs in the schema:

    🧪 1. They allow fast, transparent experimentation

    Commercial software vendors tend to move slowly and protect proprietary workflows.
    In contrast, open-source projects can:

    • Prototype new modeling concepts directly against IFC.

    • Explore edge cases and corner workflows (e.g., construction sequencing, temporary works, sustainability attributes).

    • Adjust rapidly without waiting for committee cycles.

    This means they can surface patterns and gaps in the schema much earlier.

    Example: If several users implement workarounds for temporary site equipment or construction logistics in BonsaiBIM, that points to a missing standardized concept.

    🧭 2. They can reveal what actually works in practice

    IFC schema decisions should reflect real, useful workflows, not theoretical ones.
    If open-source tools:

    • Use a certain modeling pattern repeatedly, and

    • That pattern proves interoperable across tools,

    …then it’s strong evidence that the concept is mature enough for standardization.

    In other words: schema follows practice. Open-source tools help create and document that practice transparently.

    🪜 3. They lower the barrier to entry in standards work

    Standards development is often opaque or dominated by well-funded stakeholders.
    Free and open tools:

    • Let more practitioners experiment hands-on with IFC.

    • Allow designers, builders, and researchers to propose schema improvements backed by working examples, not just theory.

    • Strengthen the legitimacy of user-driven proposals.

    This shifts influence from boardrooms and vendor roadmaps to actual modeling communities.

    🪡 4. They make “soft boundaries” visible

    Some things don’t have to be standardized — they can live in application-specific layers or property sets.
    But when open-source tools all independently converge on the same custom approach, that’s a clear signal:

    • It might be time to move that concept from “application layer” to “schema layer.”

    For example, early widespread use of “custom property sets” eventually led to formalizing certain building element properties in later IFC versions.

    🏗️ 5. They can serve as reference implementations

    If a proposed schema concept can’t be implemented cleanly in BonsaiBIM or FreeCAD, that’s a warning sign.
    If it can, it becomes:

    • A proof of concept for standards committees.

    • A way to test schema changes in real workflows.

    • A reusable codebase others can adopt.

    ✅ Bottom line:
    Yes — open-source modeling environments like BonsaiBIM and FreeCAD can be powerful “proving grounds” for determining what should be standardized in IFC versus what should stay at the application level.

    They make the political/technical boundary visible through use, rather than abstract debate.

  • MasMas
    edited October 2025

    BBIM DuctCalc (mountingParts) PartPressureLost Pa (pascal), AirVolume m³, AirSpeed m/s
    BBIM PIpeCalc (mountingPars) PartPressureLost Pa (pascal), MediaVolume L(dm³), Factor (for WaterPipesCalc) BW (in German Beiwert) - A factor that is added for DIM calc
    BBim Temp deltaTemp (°C /°F) min/max Temp, SingleTemp
    ....
    in Germany there is a Standard called "VDI 3805", in this is defined how geometry and data should be shared for mounting-parts digital. (nothing special for MEP/HVAC, it´s DomainSpecific) Its the ISO16757 in progress.
    There are more initiatives in the EU there should come the digital Product Pass, maybe as modeler it will be done by links like with bsdd, but it would also be cool, if there is a function with singlechoice (field) -at the linked DB- to apply the information needed as (standardized) property.

  • theoryshawtheoryshaw

    I put in the request to register OSArch with BS: https://technical.buildingsmart.org/services/bsdd/manage/
    ...
    I think the first pset we should tackle is OSArch_Array.
    Thoughts?

    dpszl
  • theoryshawtheoryshaw
    edited March 18

    OSArch got accepted. :)
    I added the following, as admins...

    wmikmnoffbrunopostlesteverugiMassimozoomerNigelRoelduarteframosbruno_perdigao
Sign In or Register to comment.