archipack icon indicating copy to clipboard operation
archipack copied to clipboard

Incompatible with BlenderBIM 0.7.x

Open acui opened this issue 2 years ago • 1 comments

Archipack version: 2.5.0

Blender version: 3.2.1

Os version: Windows 11

Description of the issue:

There was an error when trying to export ifc. After inspection I found that it was caused by the API changes after BlenderBIM was upgraded to 0.7.x. I updated some of the BlenderBIM calls in the archipack_io_export_ifc2.py, but now it still gives errors because the object's BIMMeshProperties.ifc_definition_id is always 0. The modified archipack_io_export_ifc2.py is in the attachment. archipack_io_export_ifc2.zip

acui avatar Aug 16 '22 09:08 acui

Hi, Thank you for the file !

Basically it does mean that either there is no project "ifc file" in memory or the object has no proper IfcClass - basically no ifc unique id - representation in ifc file.

BlenderBim concept change in recent releases. The "source of thruth" in blenderBIM is a ifc file stored both in memory when the file is open and saved to disk at export time, blender only keep track of objects using the ifc unique id on objects, so the whole ifc thing is kept on ifc files. Recent blenderbim releases implement an "event driven on change" listener so it is able to update memory file representation of objects up to date when editing, wich is quite challenging as you also have to track bim objects relationships like relative locations and parenting and update according.

Archipack exporter implement an "on the fly" project creation at export time, in order to ensure a 1:1 synch of current file state and exported ifc, as the "event" system was not mature enough at the time of writing. While working in earlyer versions, it is now broken, and the biggest issue is the ifc uuid change for entity each time you export the file, as the project must be destroyed / re-created every time. The main issue with such way is that it make it impossible to edit ifc properties of objects as the exporter must whipe everything on the fly at export time.

So in order to provide support for ifc properties editing we do have to handle user changes by triggering blenderbim events according, hoping event system is now reliable enough to handle all things properly. Another way is to trigger at least the "create" event so objects are getting a unique ifc id, and then keep track of changes in archipack using a kind of "dirty" flag, then update things properly at export time. This should include handling of 3d / footprint / axis / plan representations (contexts), proper relationships, ensure removed objects are not left in ifc file, and so on, a quite interresting challenge to implement properly.

s-leger avatar Aug 16 '22 12:08 s-leger