BlenderBIM Add-on Useful Tips

From Wiki.OSArch
Logo blenderbim.svg This page is BlenderBIM Add-on documentation. All articles in the OSArch wiki related to BlenderBIM Add-on can be seen in the BlenderBIM Add-on Category

HANDLING MULTI PART OBJECTS IN IFC

Q: How do you handle ifc classification for multi part objects, for example, a desk made up of 5 parts would have an empty at the top level of the hierarchy named Desk. In ifc, this hierarchy is not preserved and the only way I've seen to get the entire desk to export as ifc is to classify each of the five components as an ifc desk, which is neither logical nor helpful. If my hierarchy named Desk and every collection instance linked to it can be exported either as one compound object each named Desk, or a multipart object with the hierarchy preserved and the top level of the hierarchy named Desk, that would be most helpful. This seems to me like a good candidate for the sort of automation python tends to be good at, which would be nice to have as part of the export process.

A: The correct technique is to use IFC aggregations. You can find the ability to create aggregations from the scene properties. It effectively creates a collection instance, and lets you retain the class hierarchy underneath it.


MESH OPTIMIZATION TIPS TO REMEMBER WHILE WORKING WITH BLENDERBIM

Paraphrased from comment by Dion Moult on the OSArch forum.

  • Most geometry (used for BIM projects) are not detailed meshes, but simple parametric shapes. Detailed meshes are 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 used in the past. To give an idea, a table would be 3000 polygons.
  • Compare that to an object in a BIM model which had over 61,000 polygons. This in itself takes 17 seconds for IfcOpenShell to process, per object. This single mesh (which was not reused - thus leading to further inefficiency) was the primary cause for the "forever to import" issue. If you exclude it during import, using a blacklist filter query of .IfcFurniture[Name*="insert object name here"], then the file imports in just under 3 minutes. Not great, but at least it isn't forever.
  • Having too many objects is a problem. 13,000 objects does not make sense for a small scale project. 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. So use linked duplicates instead.