Hi guys,
I decided to model a small project to start testing Blender BIM and I found an issue that I think is more related to a workflow rather then a bug. I created these enclosure elements that are based on a parent and a child mesh inside a collection. So I repeated that collection as instances. But when I exported to IFC their location is moved. I guess this has to do with how Blender deals with the collection instances location. Any thoughts on how to get this to work?
So geometry in IFC is not a 1:1 match with geometry in Blender. Therefore there are some methods of modeling in Blender that won't translate particularly well. Another example is modeling with curves - if you try them out you'll no doubt run into many problems.
I'll investigate closer - I have not fully tested how collection instances work internally in Blender, so I'm unsurprised that it has issues. Thanks for bringing it to my attention :)
@Moult I have done some more testing and I came to conclusion that the collections instances are exported to the IFC file with their axis inverted. The location distances seems to be right, but they all go to oposite direction.
@bruno_perdigao, it might have to do with the local position of the child objects vs their global position. Do try Object > Apply > All Transforms on the child objects to see if that stops them being displaced after exporting.
@DADA_universe When I apply the transformations to the instance it is moved to the original position.
This is the original mesh:
In this gif I compare the behavior of a normal object (cube) and the collection instance (sphere):
The issue is that collection instance use collection helper location as base, and there is no parent / child relationship between this helper and childs objects. So a special handler must be implemented to handle the collection location.
@bruno_perdigao I think I've tracked down the issue - or at any rate, I've spotted some pretty fundamental problems with how aggregations (that is what a collection instance is) are handled. These two commits will fix these problems:
https://github.com/IfcOpenShell/IfcOpenShell/commit/4c3913353cf37e289e35cb625faaa0f569b5f0cc
https://github.com/IfcOpenShell/IfcOpenShell/commit/5db2a46369feb1fc016ae360e2c83bd95e12a2c5
If we're lucky, your problem is the same one as the one I spotted, and after applying those changes, it'll "Just Work (TM)".
If it is still not working, I think you may need to send me your file (dion@thinkmoult.com) for me to investigate further.
@Moult Just giving you an update.
I sent you my file, but I kept working on this and now I have a few more questions. Instead of creating the collection and adding a collections instance as a normal Blender workflow I selected the elements and used the "Create Aggregate" from the Blender BIM Addon. It worked. I was having trouble placing the copies because I can't change the aggregate origin, but I manage this by creating an empty as a parent.
I exported to IFC and everything worked just fine.
The thing is I can't create another aggregate. I click the button and it does nothing. Also, the "edit aggregate" doesn't seem to be working, it just makes the object disappear.
@bruno_perdigao thanks, I received your file, but haven't had a chance to inspect yet.
Yes, in short, you should always use the aggregate buttons to create / explode / edit / save. I also see right now that the workflow to add another collection instance is pretty bad. Let me work on this and I'll get back to you with some fixes.
The edit aggregate will expose the meshes that form the collection. If the collection instance has been transformed, the meshes will appear in another location (i.e. their original location prior to collection instance transformation), giving the illusion that the object simply disappears. Aggregates in IFC seem to not be used in the fashion that is so easy to use in Blender. Usually, in IFCs produced by other apps, the aggregate is not reused (i.e. there will only be one collection instance, with no further transformation applied). In Blender, you have the ability to easily duplicate the aggregation - which is legal in IFC, but very uncommon - therefore the editing workflow at the moment is awkward.
Perhaps one solution is that when the "Edit aggregate" button is pressed, it can re-transform everything to let you modify that one aggregate "in-place". That would certainly improve usability.
I had a look at at your file and realised that there is indeed a bug that means that if you use the "Create Aggregate" feature without first having an "Aggregates" collection it won't be created properly. That's now fixed: https://github.com/IfcOpenShell/IfcOpenShell/commit/bd02c8e34b9db83bf70b6526c1550dda698d0f88 - without the fix, you can manually work around it by created the "Aggregates" collection in your IfcProject collection manually prior to creating your first aggregate.
When an aggregate is created properly, you can just Alt-D on the instance to duplicate and move it wherever.
I've sent back a working blend file. By the way, a few observations:
IFC doesn't support "arrays" so as a result the roof object will be quite expensive in terms of filesize in the IFC. (5mb for that one roof, it seems)
You had a separate IfcSite mesh from the IfcSite empty. This is invalid - if your site should have geometry, you should replace the empty with your mesh - retaining the same name as the collection. I've fixed this in your Blend file.
The site is also a little heavy in terms of verts - most sites only have surveyed points, not as you've shown. At the moment, I've only implemented the IFC2X3 breps, which means that it's going to be quite heavy in terms of IFC filesize. For example, if I export excluding the roof and site mesh, it drops down to 280kb, which is very reasonable. That said, I probably should implement the IFC4 breps, which'll make life a bit better anyway.
I don't think that should be a curtain wall. Perhaps it is simply cladding (e.g. IfcCovering/Cladding) - so in this case an aggregate probably isn't required... but oh well :)
@Moult said:
That said, I probably should implement the IFC4 breps, which'll make life a bit better anyway.
A heads up that this is now implemented: https://github.com/IfcOpenShell/IfcOpenShell/commit/ff5bc25228b700b89b78ec71eb1867c96a4d0bcf
Ping @yorik - using IfcPolygonalFaceSet is much more efficient than IfcFacetedBrep, but only works in IFC4. Not sure if FreeCAD supports it yet, but if not, I highly recommend it.
As an example of the efficiency gained, Suzanne by default exports as an 84kb IfcFacetedBrep. The exact same Suzanne exports as an IfcPolygonalFaceSet in only 44kb with no data loss.
In summary, in the next BlenderBIM Add-on release, expect much smaller filesizes upon export across the board.
@CadGiru
You can always write short descriptions and then link to threads like this. When the informaion is so short lived and evolving then maybe full documentation is a bit much effort.
Anything you write on the wiki and add at the bottom [[Category:BlenderBIM Add-on]] will turn up in that category list.
https://wiki.osarch.org/index.php?title=Category:BlenderBIM_Add-on
Let me know if you want help getting started on the wiki.
Will do
From my own experience w learning a workflow in various authoring programs, the most frustrating is feeling you are on the right track, then further down the line you discover you have done something i a correct way, but wrong according to the workflow you are trying to achieve..
Simple example from BlenderBim: The way you start modelling an ifcElement has an impact of how You for instance can harvest qty properties from the element.
Yes I see everything is changing quite fast which is great. Still my belief is that the better we can document a 'safe' workflow, the less frustration we will have from new users, and that way avoid loosing them.
Ping @yorik - using IfcPolygonalFaceSet is much more efficient than IfcFacetedBrep, but only works in IFC4. Not sure if FreeCAD supports it yet, but if not, I highly recommend it.
ooh that seems good.. will try! thanks for the hint!
@CadGiru the fact that there are default quantity take off properties for each IFC class is an inherent decision in IFC itself - not to do with the BenderBIM Add-on. Keep in mind that you can create custom Qtos, so if you need a particular Qto which isn't in the list, you can add it yourself.
@Moult thx for comment.. Sure we can probably but more or less what we want in an ifc file, but thought sticking to inherent default definitions were possible was good practice
Login or Register to reply.
