BBIM - two door types with connected properties
Hi,
I have an IFC model exported from Revit. There are two types of doors, with boolean property "IsExternal". When I change this property in one type, the other switches too. This is not the behavior that I would expect, because theses two door types should not have their properties associated. They were not associated in original Revit file neither.
When trying to create new property, it behaves the way I expect - each door type can have properties independent of each other. I recorded a short video with this behavior and I attached my sample file.
My question is, whether this is the correct behavior. If it is, where is it possible to check, which properties/attributes are connected between two types?
Tom
Comments
Out of topic. I opened your file with BB 231021 and when i tired to edit the window sill (
IfcBuildingElementProxy/M_Trim-Window-Exterior-Flat:with Si.002) withTAB, blender crashes.Those elements have a
SweptSolid*representation with 3IfcExtrudedAreaSoliditems.@Andrej730 does Blender crash because editing an object with more than one representation item is not yet supported?
Using BBIM 231020 I am able to edit the window sill ( IfcBuildingElementProxy/M_Trim-Window-Exterior-Flat:with Si.002 ), but when I finish the editing, other 3 window sill instances disappear from the project.
Immediately after export from Revit, when you open the file in BB, are the property's connected?
Might be problem with Revit export, if so.
Yes, it happens straight out of the box when opening the exported IFC.
I also tested the "IsExternal" property of two types of walls in the project and they behave independently - as expected.
@carlopav even if something is not supported yet it shouldn't crash Blender. Just tested it - it doesn't crash, atleast on windows 11. Can you please try to start Blender from console and send console errors you get before the crash?
Sure. You find it here attached. I'm on win 11 too.
The crash happens exactly when exiting edit mode pressing TAB key.
@carlopav Fixed after the commit, you can try it with new build. Couldn't reproduce it before because it was requiring BIM Tool to be opened (crash was caused by current type preview image becoming invalid).
Thanks for reporting this, found other issues along the way fixing this! ?
@Andrej730 great, you fixed it! @semhustej sorry for the intrusion :)
No problem @carlopav , I am happy the file helped with the development :)
Back to the original issue: I tested new export from Revit with default Autodesk door and window types. The behavior is still the same - when IsExternal parameter is changed, the value for all door or window types is changed at once. So it seems to be somehow linked to the Revit export. My question is: is there a way in BBIM to see the connection of parameters between types? Is this possible in the IFC schema or it should not happen at all?
Tom
This is one way.
It appears these types have different psets... so maybe it is a BlenderBIM bug, after all.
Thanks for pointing out the debugger. It seems like a powerful tool for model checking.
I am not familiar with the IFC structure, but from my quick glimpse it seems the property in the property sets of both door types is pointing to the same line (#216), which defines the property instance. So then it makes sense to me, that when I change the value of this line, it changes in both door types. So it seems like a Revit export problem. I am not sure whether I used the default Revit IFC exporter or the FOSS IFC exporter.
It looks as though all "IsExternal True" and "IsExternal False" parameters in the project are directed to only two lines in the IFC file, as seen in the video:
@semhustej I am no expert here but I remember Dion recommending using the Github Revit exporter and using some specific settings, I cannot remember where to find this but suggest a search of this forum
Sorry @semhustej, yep, you're right. Was lookiing in the wrong place. So it appears it's a Revit bug.
As @Nigel suggested are you using Revit's open source IFC exporter, if you haven't already: https://github.com/Autodesk/revit-ifc
Not sure if that will fix this though.
If it doesn't, I'd post an issue on their github repo.
So I did some further testing with the latest 2024 FOSS Revit IFC exporter and all IsExternal properties are always linked - there are two of these properties, one set to True, one set to false. Tested with multiple MVDs and schemas. I guess the Revit exporter is mainly focused on coordination (if you do not edit the IFC, the parameters are OK), not on making editable file.
@Nigel yes, the FOSS exporter is recommended not only by Dion, by also by Autodesk.
Thank you for help with troubleshooting, @theoryshaw
I guess the more I think about this, the IFC produced by Revit is still a valid file.
There are IFC 'zippers' that reduce file sizes by consolidating a ton of repeating entities into one entity--and they are still valid files.
So, perhaps, BB should, when changing a pset value, make sure it's not already tied to another object, and if so, create an entirely new pset entity for it.
I cannot comment on that, as I am not familiar with the IFC schema to that depth. The exported Revit file is fine for reviewing, but not for editing the file. This is in accordance to how IFC schema is mostly considered in the industry right now.
I tested with Design Transfer View MVD too, with the same result. I did not test, whether this happens only with IsExternal parameter or whether it happens with other parameters with the same value.
I reported an inquiry to the Revit IFC exporter github page. The discussed behavior is intended - to avoid having large number of propertysinglevalues.
See here:
https://github.com/Autodesk/revit-ifc/issues/698
I do not know whether one of BlenderBIM's goals is to be able to edit IFC files exported from other software, so I am not pursuing this topic further.
Tom
I think this is a prevalent enough workflow, however, to put in a feature request.
https://github.com/IfcOpenShell/IfcOpenShell/issues/new
Hi @semhustej
I certainly hope BlenderBIMs primary goal will be to edit IFCs from other software ? as well as an IFC viewer and authoring app.
The current work around, however, would be to delete the Pset_DoorCommon pset from the door type, and then just add a new Pset_DoorCommon pset back again.
Yes, this works. After removing the property set from the type a re-creating it again, the Psets are created independently. But you loose other property values from the Pset, so this workaround will not fit most workflows.
Submitted the issue, even though I am not sure it is BBIM's issue :)
https://github.com/IfcOpenShell/IfcOpenShell/issues/3957
Thanks for highlighting this. This is indeed our fault and quite a simple oversight which I'm surprised has lasted this long. It's now fixed :)
Wow, that was fast! When I saw closed issue in my email that fast, I thought the report was closed and thrown into trashcan :)
Thank you very much, @Moult .
I guess if this scenario played out in a large proprietary software company, the bug would be fixed in the same time but only after marketing, legal, strategy, investment, the board and a myriad of others dilerated over the potential impact on market share, customer perception, shareholder reaction and competitive value, 2 years later...
Long live this free and open source community ?