@Moult Restarting blender is a mandatory step as once loaded pycache files will remain in memory whatever you do. There are some attempts to overcome this issue, but most failing at properly reload multi-nested-modules.
My guess is disable + remove, then restart, then setup new version is a safe path to get it working.
I had the same error as @John and uninstalling, restarting and reinstalling didn't help.
But I managed to install it by commenting this line excluding bimtester from the package, whose import raised the exception.
So, I guess, sth has to do with bimtester in this version
I have been able to install the new version successfully, but I'm not able to work with any IFCs with it. I'm neither able to import IFCs, not create IFC projects out of Archipack objects the normal way. Both processes throw errors (see below). I was using Blender 2.91.0 beta and wondered if it was a Blender issue that had been resolved in subsequent builds. I downloaded Blender 2.92.0 Beta and it's got the same issue.
P.S. I uninstalled BlenderBim completely (ensured the folder was no more in the add-ons folder), restarted Blender and reinstalled the add-on to no avail.
Error from trying to create IFCs from Archipack objects:
Python: Traceback (most recent call last):
File "C:\Users\ATTITA\AppData\Roaming\Blender Foundation\Blender\2.92\scripts\addons\archipack_20\archipack_io_export_ifc.py", line 2965, in execute
struct_man.create_ifc_structure(context)File "C:\Users\ATTITA\AppData\Roaming\Blender Foundation\Blender\2.92\scripts\addons\archipack_20\archipack_io_export_ifc.py", line 2712, in create_ifc_structure
self.ifc_name(o, apk_cls, context_prefix)File "C:\Users\ATTITA\AppData\Roaming\Blender Foundation\Blender\2.92\scripts\addons\archipack_20\archipack_io_export_ifc.py", line 2653, in ifc_name
self._add_predefined_type(o, PREDEFINED_TYPES[apk_cls])File "C:\Users\ATTITA\AppData\Roaming\Blender Foundation\Blender\2.92\scripts\addons\archipack_20\archipack_io_export_ifc.py", line 2643, in _add_predefined_type
p = o.BIMObjectProperties.attributes.get("PredefinedType")AttributeError: 'BIMObjectProperties' object has no attribute 'attributes'
location: <unknown location>:-1
Error from Importing IFCs:
Python: Traceback (most recent call last):
File "C:\Users\ATTITA\AppData\Roaming\Blender Foundation\Blender\2.92\scripts\addons\blenderbim\bim\operator.py", line 165, in execute
ifc_importer.execute()File "C:\Users\ATTITA\AppData\Roaming\Blender Foundation\Blender\2.92\scripts\addons\blenderbim\bim\import_ifc.py", line 323, in execute
self.load_existing_rooted_elements()File "C:\Users\ATTITA\AppData\Roaming\Blender Foundation\Blender\2.92\scripts\addons\blenderbim\bim\import_ifc.py", line 1080, in load_existing_rooted_elements
self.existing_elements[self.file.by_id(obj.BIMObjectProperties.ifc_definition_id).GlobalId] = objAttributeError: 'NoneType' object has no attribute 'by_id'
location: <unknown location>:-1
@Jesusbill did you try with the build I posted? It is not the same as the one on the website.
@DADA_universe thanks for the report! ArchiPack integration is broken in this release due to the huge fundamental changes in the BlenderBIM Add-on. I've had a chat with @stephen_l to explain the changes, but it may take some time for it to be fixed in Archipack. For now, if you wish to use Archipack, unfortunately you will need to use the older version.
The second issue is indeed a bug. Fixed now: https://github.com/IfcOpenShell/IfcOpenShell/commit/04a2949d75c837ee38b51451b5e3bb0e4e3d5e8c
I made a video about the new release. First part is published here:
https://youtube.com/watch?v=R-8uzPU__UM
On the publishing pipeline parts of a talk with I had with Dion about the release.
@Moult said:
@Jesusbill did you try with the build I posted? It is not the same as the one on the website.
Ok, perfect, yeah I tried the 210203 version for windows and it works! Great!
@Moult said:
@DADA_universe thanks for the report! ArchiPack integration is broken in this release due to the huge fundamental changes in the BlenderBIM Add-on. I've had a chat with @stephen_l to explain the changes, but it may take some time for it to be fixed in Archipack. For now, if you wish to use Archipack, unfortunately you will need to use the older version.
The second issue is indeed a bug. Fixed now: https://github.com/IfcOpenShell/IfcOpenShell/commit/04a2949d75c837ee38b51451b5e3bb0e4e3d5e8c
UPDATE:
I patched the script you referred to as suggested and sometimes the import worked, other times it threw an error, and some other times it just took forever trying to import until I forced Blender to close. I then tried the 210203 version and patched the importifc.py file as well. It is a bit more stable, it's not throwing those bugs anymore when importing, but there's a file that still makes Blender hang, not sure if it will happen with others. While it's importing successfully though, it does strip away some geometry (mainly some walls and roofs) while at it.
@DADA_universe am I correct in saying that you're trying to import into a file that already has objects, instead of a fresh file? In any case, would it be possible for you to create some bug reports at https://github.com/IfcOpenShell/IfcOpenShell with details of the error as well as files I can use to replicate it with? Otherwise, if it complex, you can also catch me online on the live chat during Sydney waking hours. If the files are private, my email is dion@thinkmoult.com
@Moult said:
@DADA_universe am I correct in saying that you're trying to import into a file that already has objects, instead of a fresh file? In any case, would it be possible for you to create some bug reports at https://github.com/IfcOpenShell/IfcOpenShell with details of the error as well as files I can use to replicate it with? Otherwise, if it complex, you can also catch me online on the live chat during Sydney waking hours. If the files are private, my email is dion@thinkmoult.com
Hi Dion, I've mailed you two files for testing, via WeTransfer, thought that might be more helpful.
Yes importing into a file that already has (or had, in cases where I imported and then deleted the hierarchy and then tried to import again)objects was throwing errors, but the patch you shared seems to quell those errors. Two issues however persisted: 1) One file taking forever to import, and 2) Other files having missing walls or roofs.
@DADA_universe I hope you don't mind me replying here in public so that others can learn too from what I've seen in your file. For the record, I received two files, a 7mb file and a 42mb file.
For the 42mb file, it was exported from the BlenderBIM Add-on, and contained 13,000 objects for roughly 150m2. It took forever to import. There are quite a few reasons for this.
The promised "twice as fast" import times of the latest version does not apply in this scenario - the optimisation is largely around importing data, not geometry, but this file is primarily detailed mesh geometry, with very little to zero data. In this case, the speed up will be minimal. Most files in the wild are the opposite of this.
I should note that in the future, there is a known optimisation to be made with geometry which particularly affects mesh geometry, of which this file is. Note that in the wild, most geometry is not detailed meshes, but simple parametric shapes. In the future, it is likely that this file will see big performance gains. Until then, I can only apologise that you are unable to benefit from the performance gains for now :(
The meshes were not optimised for BIM. Typically, you'd want to treat your BIM model the same way you'd deal with creating assets for game - keep the polycount low, and make it generated (i.e. parametric) in standardised scenarios (e.g. profiles). If you do want to include high poly geometric assets, such as for archviz, keep that as a separate file, and have BIM include the low poly proxy, and reference the high poly asset via an external file. The process for this referencing is not (yet) standardised, but there are a few approaches I have used in the past. To give an idea, a table would be 3000 polygons.
In particular, there was a wheel shown in the BIM model which had over 61,000 polygons. This in itself takes 17 seconds for IfcOpenShell to process, per wheel. This single mesh (which was not reused - thus leading to further inefficiency) was the primary cause for the "forever to import". If I exclude it during import, using a blacklist filter query of .IfcFurniture[Name*="Caster_Swivel"], then the file imports in just under 3 minutes. Not great, but at least it isn't forever.
Too many objects. 13,000 objects does not make sense for this scale. There are bookshelves, where a single row of books accounts for about 180 objects. This does not make sense - even in regular 3D modeling, you wouldn't have 180 objects for a single row of books. In BIM, you should model objects based on how they are installed on site. In this case, the books should not even be in the model, but if you wanted it to, then it should be merged into the bookshelf - an entire bookshelf with all of its books should be one object. Of the 13,000 objects, 9,888 are books (edit: there are more, actually). Fixing the 9,888 books on my computer drops the import time from the already improved 3 minutes, down to 70 seconds, to give an idea of the desired behaviour.
No mesh reuse. If you use the same chair 24 times, you should use the same mesh. Instead, the meshes are all duplicated, not linked.
After fixing these issues, I expect the filesize to drop significantly, and the import time to also become much, much faster. I think it would be quite an educational activity to see how to clean up this type of file with the new BlenderBIM Add-on, and might be worth a shared video. Thoughts?
Maybe also useful is a video tutorial of how to debug these types of files - how to spot errors, find elements that need fixing, etc.
I have not yet looked at the 7mb file.
Example screenshot of the 61,000 polygon wheel.
@DADA_universe the 7mb file issue is my fault, I'd say. The old BlenderBIM Add-on did exported meshes which already had their openings applied, in addition to the opening relationships. This causes a double boolean, causing weird boolean artifacts like the missing walls that you experience in that file. This has been fixed in the latest release, but still is worth teaching users about the importance of opening relationships in IFC. In the new release, you have the option to switch to unbooleaned meshes, which you should use before editing any mesh which has openings.
That said, the file is fixable with a few tweaks. Maybe this is also worth a video? I will start building more features that aid in this type of fixing.
@Moult said:
@DADA_universe I hope you don't mind me replying here in public so that others can learn too from what I've seen in your file. For the record, I received two files, a 7mb file and a 42mb file.
For the 42mb file, it was exported from the BlenderBIM Add-on, and contained 13,000 objects for roughly 150m2. It took forever to import. There are quite a few reasons for this.
- The promised "twice as fast" import times of the latest version does not apply in this scenario - the optimisation is largely around importing data, not geometry, but this file is primarily detailed mesh geometry, with very little to zero data. In this case, the speed up will be minimal. Most files in the wild are the opposite of this.
- I should note that in the future, there is a known optimisation to be made with geometry which particularly affects mesh geometry, of which this file is. Note that in the wild, most geometry is not detailed meshes, but simple parametric shapes. In the future, it is likely that this file will see big performance gains. Until then, I can only apologise that you are unable to benefit from the performance gains for now :(
- The meshes were not optimised for BIM. Typically, you'd want to treat your BIM model the same way you'd deal with creating assets for game - keep the polycount low, and make it generated (i.e. parametric) in standardised scenarios (e.g. profiles). If you do want to include high poly geometric assets, such as for archviz, keep that as a separate file, and have BIM include the low poly proxy, and reference the high poly asset via an external file. The process for this referencing is not (yet) standardised, but there are a few approaches I have used in the past. To give an idea, a table would be 3000 polygons.
- In particular, there was a wheel shown in the BIM model which had over 61,000 polygons. This in itself takes 17 seconds for IfcOpenShell to process, per wheel. This single mesh (which was not reused - thus leading to further inefficiency) was the primary cause for the "forever to import". If I exclude it during import, using a blacklist filter query of
.IfcFurniture[Name*="Caster_Swivel"], then the file imports in just under 3 minutes. Not great, but at least it isn't forever.
- Too many objects. 13,000 objects does not make sense for this scale. There are bookshelves, where a single row of books accounts for about 180 objects. This does not make sense - even in regular 3D modeling, you wouldn't have 180 objects for a single row of books. In BIM, you should model objects based on how they are installed on site. In this case, the books should not even be in the model, but if you wanted it to, then it should be merged into the bookshelf - an entire bookshelf with all of its books should be one object. Of the 13,000 objects, 9,888 are books (edit: there are more, actually). Fixing the 9,888 books on my computer drops the import time from the already improved 3 minutes, down to 70 seconds, to give an idea of the desired behaviour.
- No mesh reuse. If you use the same chair 24 times, you should use the same mesh. Instead, the meshes are all duplicated, not linked.
After fixing these issues, I expect the filesize to drop significantly, and the import time to also become much, much faster. I think it would be quite an educational activity to see how to clean up this type of file with the new BlenderBIM Add-on, and might be worth a shared video. Thoughts?
Maybe also useful is a video tutorial of how to debug these types of files - how to spot errors, find elements that need fixing, etc.
I have not yet looked at the 7mb file.
Example screenshot of the 61,000 polygon wheel.
Thanks a lot for the feedback Dion. I'm glad I sent the files. I knew the 42mb file was not optimized, but I didn't realize it was that bad! Really something to look out for. The wiki page on BlenderBIM best practices is now overdue and I need to get on with creating it and adding these optimization tips to it, and yes, if you do make those videos, (yes it's a very good idea to make them) I should link them to it too. Thank you.
BlenderBIM Add-on v0.0.210221 has been released with 57 new features and fixes. It's our built environment, help support the BlenderBIM Add-on: 100% free and open source software that lets you author and document BIM data fully to ISO standards. It's built by the AEC community, for the AEC community. Get it today: https://blenderbim.org/
As the prior release was an entire rewrite, there were consequently a lot of bugs introduced. This release is primarily about fixing those bugs, so no fancy release highlights ... unless you count the experimental 4D scripts, which are cool. With a more stable foundation, we can move forward and continue to build features as well as UX improvements.
Also Cinnamon is my new pet rabbit :D Isn't she cute!
New features:
BIMTester now operates on single feature files, which heavily improves usability
BIMTester custom schema is now specified as an argument, not as a tester requirement, which is where it belongs
BIMTester sentence quote usage is now standardised and always enable translations
You can now load the active IFC file into a BIMTester audit. No need to export first!
Now, users don't need to consider include curves and 2D annotations as they are always imported
You can now specify a set of custom step definitions to BIMTester, go and write your own test definitions!
New BIMTester web app mockup https://blenderbim.org/bimtester/
Validating IFCs UI now moved over into debug panel
New create shape debugging tool to help determine broken or crashing elements
Type representation maps are now shown in the IFC Representations UI panel
Type representations are now always imported (better for authoring), and also import super fast compared to before (before, enabling types being imported would significantly slow down import times)
Only IFC files are now shown in the export file dialog for a less confusing user experience
IfcPatch is now callable from the command line (thanks htlcnn!)
New IfcOpenShell.util.type module for checking applicable type classes.
You can now assign types with a smart type filter, without needing to first import types into Blender
New build script for IfcPatch to distribute binaries (thanks htlcnn!)
IfcOpenShell date util now supports converting to IFC2X3 date entities
Highly experimental script to convert from P6 XML into an IFC task tree
Highly experimental script to convert from IFC task trees into a Gantt chart JSON for jsgantt-improved
You can now edit parameters of parametric profile definitions in geometry.
New basic UI to view tasks in an IFC file
You can now add type instances, and mapped representations are enforced.
STEP IDs are now shown for non-rooted elements, like grid axes.
Blender now helps prevent saving Blender without having an exported IFC
Improve UI to change spatial container to prevent accidentally selecting incorrect objects
New fixes:
Fix bunch of error messages (commonly seen in IFCCSV) when you try to get a property value which is null
Fix bug where BIMTester audit classes dropdown wouldn't show.
There is now an ID and GUID map to Blender objects for easy access especially for devs
Fix bug where Blender booleans wasn't good enough. Now we're back to IfcOpenShell with optional Blender conversion on a case by case
Fix bug where unable to install add-on in older Blender versions
Fix bug where switching representations would not work or create duplicated meshes
Fix error when importing consecutive files
Fix bug so that users can now reassign the IFC file location if it moves.
Fix bug where vertex welded happened across representations (thanks aothms!)
Fix bug where spatial objects with representations didn't import correctly
Fix import bug where loading existing elements wouldn't work
Fix crash on Windows when removing property sets (thanks aothms!)
Fix crash when reassigning class (thanks aothms!)
Fix unable to load IfcPatch recipes (thanks htlcnn!)
Fix regression where dumb objects didn't get an IFC class
Fix ability to create grids which was totally broken
Fix bug when adding grids to drawings, which also was totally broken
Fix bug where product and type representations wouldn't be linked data in Blender when importing
Fix bug where representations wouldn't be purged correctly if they were part of a layer with many items
Fix bug where you could create mapped representations without having a type product
Fix bug where removing a mapped representation did not properly consider all mapped usages
Fix bug where switching construction type didn't enforce appropriate representation maps
Fix bug where you couldn't import two different IFC files in succession in the same Blender file
Fix bug where only a light removal occured when removing elements. Now, a full geometry purge is done as well
Fix bug regression in the absolute coordinate offset feature where I forgot to convert non-meter units
Fix bug where geolocation was lost if you tried to edit an absolutely positioned file
Fix bug where unable to install add-on due to clash with Blender-OSM.
Fix bug where you couldn't copy classes without representations.
Fix bug so that null ownership histories in IFC4 are now allowed
Fix bug where you couldn't edit the geometry of a grid axis
Fix bug where copying a class did not enforce mapped representations
Fix bug where removing mapped representations leaving you with nothing was a poor user experience
"You can now edit parameters of parametric profile definitions in geometry."
does anyone know what that is referring to, specifically?... sounds cool.
cool, I think I found it.
Curious, what is the native Blender functionality running this? Drivers? Modifiers?
None of this, under the hood it drive ifc definition and geometry is rebuilt using opencascade, as profile based shape will not be able to handle boolean modifiers.
Correct - the entire process is now IFC driven. This is why there was a huge rewrite and lots of groundwork to get the foundations right. In the past, data was encoded in the Blender file, similar to how in FreeCAD they've written code to translate and store IFC data within FreeCAD. This is a bit of a mammoth task (and in my opinion, never-ending), especially as IFC geometry certainly does have similarities to aspects of FreeCAD, but extend past the paradigms of a single software - and that is the nature of our industry. Our industry deals with many geometric representations suitable for different domains.
As you've discovered, the functionality is now there to support all parametric IFC geometry, magically out of the box, even detecting new geometry in new IFC version (e.g. upcoming IfcRail alignment curves, critical for linear infra). The BlenderBIM Add-on also now supports nested parametric geometry (e.g. CSG booleans + profiles + extrusions + meshes). However, also as you've discovered, the UX is pretty poor right now, relying on sliders and buttons. But as with all software, UX needs to come after the functions :) which it will!
this is fantastic @Moult , I'm also very curious to know how you did it inside the api. I was already eager to study your code, now I'm even more eager! You treat IFC like a native format, no other software does that!
Thanks to @Moult and everyone who has contributed towards this spectacular project. This is really good. Cheers!!!
On win10 blender2.93 alpha started to use python39(and now we cannot enable Blenderbim). I know everyone knows about it. How it is going to effect Blenderbim?
I think @Moult should leave that problem to solve for windows users.
@swathi you are right that it is something to pay attention to. It's not specific to Windows, I suspect. We will start needing to find deps built for 3.9. I've posted a bugreport here: https://github.com/IfcOpenShell/IfcOpenShell/issues/1340 - for a long term solution, we need to create a build bot for things like Python OCC, fcl, etc as well. This is quite a bit of work.
@swathi said:
On win10 blender2.93 alpha started to use python39(and now we cannot enable Blenderbim). I know everyone knows about it. How it is going to effect Blenderbim?
BlenderBIM use precompiled c+ library, highly sensitive to python versions, so it is likely to not work unless a new version of those libs are available for python 3.9
@Moult
Would it be possible to add which blender version is best used in conjunction with the latest BlenderBIMAddOn? Since 99% of my blender usage is because of BlenderBIM I would use the recommended Blender version in any case.
cheers bernd
Login or Register to reply.