IfcOpeningElements in the BlenderBIM add-on

edited November 2021 in General

This day I have been trying to use the Blender BIM add-on as an IFC creation tool, instead of an IFC authoring tool as intended at the moment? (please correct me if I'm wrong).

My aim is trying to find a fast workflow for cutting an IfcOpeningElement in Blender while using the IFC model as the single source of truth.

  1. I have modelled a really simple cavity wall in Blender

  2. added a dumb opening from the Blender BIM add-on

  3. Used the IFC Void tool to cut the opening

  4. Exported it to IFC

I think you see where this is going.
I need to add an opening for each wall, which is extremely time consuming.
However when I do this I can parent the IfcOpeningElements, so when moving them don't have to move them all three individually.

I moved the IfcOpeningElement 1 meter, it worked perfect when exporting to IFC

However. Very this method is very time consuming. I know there is Archipack PRO. But I was deliberately avoiding Archipack PRO because I want to use IFC as the single source of truth and not an Archipack or .blend file. Plus I use the parent-object functionality when importing the IFC in Blender again.

I have three questions:
1. Whenever trying to resize the IfcOpeningElements, I all have to resize each three IfcOpeningElements one-by-one. Is there a smarter/better way?
2. When importing the IFC again in Blender to keep the IFC as the single source of truth, I lost my Parent-object (obviously). But the BlenderBIM add-on automatically hides the IfcOpeningElements and does not show the opening:

Also when I click show opening, it does not show the opening in the wall while it's still there.

What is the reason for this?

  1. Do you have any idea or an approach for a fast workflow in Blender to use just one IfcOpeningElement to cut through multiple IFC elements? No idea if the IFC schema allows it.


  • Curious too. I would think you could apply (1) IfcOpeningElement to multiple walls. Maybe there's a schema restriction for this.
    Look forward to when BB can visualize multiple layers of a wall, as discussed here. This would solve your problem, in part.

  • edited November 2021

    An IfcOpeningElement can only void at most one IfcElement (unless I'm mistaken)
    Currently there is no way to achieve this workflow without using one IfcOpening object per Wall object. You may be able to link the mesh data so that any change in one of the opening objects propagates to the others but that may be it.
    I believe the solution as mentioned by @theoryshaw is native managing of wall layers as mesh in a single object. But IfcWall is another beast with just the right amount of complexity that it's not really trivial :)

    Or alternatively, but that would mean a lot of overhead on the blender side, linking a single IfcWall to several Blender wall objects and dynamically update booleans to propagate changes due to an IfcOpeningElement

  • It's unfortunate that it's only a one to one relationship.
    I remember this project @Moult used an IfcOpeningElement to trim the tops of a bunch of walls to follow the roof line.
    That would be handy!
    But it doesn't seem like this is possible in light of the schema?

  • Yes, the void can only cut one object which I find pretty poor in IFC.

    Let me ponder a bit on this and see what I can come up with. Perhaps @aothms might know a convenient way around it in the schema or another relationship we could use.

    As for the last example, that trick worked because the walls were all one object - fine if you're modeling cowboy style in meshland, but not so fine if you want to follow the standard case convention where the walls stop at each junction. (Which is incredibly valuable for 4D/5D work, as well as parametric wall layers, so I sincerely hope buildingSMART never decides to discourage this convention).

  • For what it's worth, logged schema feature request. : ) https://github.com/buildingSMART/NextGen-IFC/issues/87

  • @Moult said:

    modeling cowboy style in meshland

  • This has been discussed quite a few times within bSI. There's also quite a few people in favor of it. Other common examples are elevator shafts through multiple slabs for example.

    The issue is that most people want to insist on the IFC spatial hierarchy from project > site > containment | aggregation > openings > fills to remain a strict tree (so every child exactly one parent except the root). And openings in multiple elements violate that. It's also problematic with the FillsElement relationship, which window can fill the opening if the opening itself is in multiple walls.

  • edited November 2021

    is it possible to use an alternative workflow?
    the walls are modelled 'full width' then the windows are added and then the wall is converted to an internal wall, a cavity and an external/veneer wall but some software magic but of course the question is, can it then be simply edited add windows remove windows etc?
    Just a thought

  • edited November 2021

    Also @theoryshaw, regarding your use case specifically, to be pedantic. This not what an opening is about. They are really for openings and recesses, not for clipping. That's what IfcBooleanClippingResult is for. So I think the somewhat unfortunate answer is that needs to be solved in the authoring tool with constraints between elements (modelled as IfcRelConnects e.g between wall and roof slab) and a bespoke "translation" to geometrical concepts. Due to the element-level isolation and other things, IFC isn't a perfect match to the design intent and constraints in an authoring tool.

    Secondly, I must say that a clipping plane (IfcHalfSpaceSolid; the only allowed operand for IfcBooleanClippingResult) is a more natural way of defining the geometry than an arbitrary boolean operand. What if you weren't to move the operand, but want your roof slabs under a different angle? It's not a very semantic way of expressing your intent I mean.

  • And one more comment related to @Coen's original post. The way to model this in IFC is to have a IfcWall without representation (maybe an Axis) and then three IfcBuildingElement part objects with actual geometry. The opening is then associate to the IfcWall parent and the IFC implementations will apply that opening to all IfcBuildingElement part objects. I can imagine of course that also doesn't really map well to Blender's Boolean modifier, but perhaps some instancing and parenting makes it not entirely frustrating?

  • @aothms I assume you mean the empty Wall aggregates the Building Element Part objects.

    Is there any particular rule concerning nested classes? Should the wall layers be Building Element Part or can they be Wall aggregated inside the parent Wall?

  • @brunopostle correct

    It's a good question, the answer is a bit vague. The general principle up until now was that this was governed by concepts and model view definitions (and General Usage being some sort of encompassing model view).

    Then you would have a concept such as Element Compositions that describes the general graph layout of composition and then you could have constraints on such templates, such as an IfcWall -> IfcBuildingElementPart.

    So in theory this is exchange specific. This is what bSI is now trying to avoid and get tighter as such the freedom to arbitrarily constrain such concepts hinder interoperability.

    Also, while the principles are there in IfcDoc and mvdXML, the authoring experience is quite limited and they have fallen behind wrt to the actual schema development.

    So probably a good source of info would be to scroll through the implementation guide and implementer agreements.

    If I look at the Element Decomposition concept from the latest version of the IfcDoc repo, this is what I can find, so it's not very complete.

  • @aothms I hadn't even heard of Wall Elemented Case, this spec has dark corners.

    I'm glad to hear that an opening can cut assemblies, such as wall studs, and I have wondered how to do skirtings that span between doors.

  • Very dark, but all *Case elements are also deprecated, which shows how incomplete and not-up-to-date this mapping is I just showed.

  • A minor note about those reading:

    Secondly, I must say that a clipping plane (IfcHalfSpaceSolid; the only allowed operand for IfcBooleanClippingResult) is a more natural way of defining the geometry than an arbitrary boolean operand.

    Unfortunately modeling this natively is not yet supported in the BlenderBIM Add-on. We don't yet provide the ability to dig into the individual booleans of a shape representation with a nice modeling interface. Sigh, another one for the todo list.

  • We don't yet provide the ability to dig into the individual booleans of a shape representation with a nice modeling interface. Sigh, another one for the todo list.

    But maybe that's also not necessary? I feel like it would also overcomplicate general cases. Perhaps you could somehow special case halfspaces in that it'd be a group with mesh and a plane or sth and in that special case during export they're folded into representation items. During import they're exploded into grouped elements.

    Perhaps that's also a way out of @theoryshaw's use case. You just create a "Clipping Group" in Blender so that all elements in that group are clipped by the plane(s). It really seems possible to bidirectionally sync this with IFC. Although it's not fully "native" so I can see the problems there. Really just thinking out loud here.

Sign In or Register to comment.