Good Morning,
I'm surely doing something wrong, Ive updated BBim to version 240204. I'm not able to change the spatial container of an object in the object information window. The trees of the spatial structure can't reach the final level, it opens site, bulding but can't show the storey. I attach screenshoot, sistem info and the file.
Thank you, and forgive my english knowledge!
I installed "blenderbim_py311-0.7.11-alpha240730-windows-x64" in Blender 4.2 but when I opened my .ifc file most part of the building model is not showing. I observed in the Blender Outliner that the IFC aggregation tree has been disorganized. But when I open the same file with old BBIM-addon in Blender 4.1 there's no problem so I am bringing to attention if this could be a bug in the Blender 4.2.
Find the attached image to see the disorganized ifc tree (IfcProject-->IfcBuildingStorey-->IfcSite-->IfcBuildingStorey-->IfcBuilding) in the Outliner.
Thank you
The latest version purposely does not have a hierarchical tree in the outliner, it is now flattened on purpose. If you want to see a hierarchical tree, check out the new spatial decomposition panel (middle right of your screenshot).
If you have missing objects please urgently submit this as a bug and if the file is private share to dion@thinkmoult.com
At the Project tab you can control the structure... and if you are pressing the little arrow beside "italian house" the next structure element should open. (Maybe it works) excuse my bad English too.
Thank you @stefanm2,
you are right, inside the project tab the spatial tree extends itself at the storey level, but i've tried to change the storey of the elements in the object information tab instead of dragging and drop in the project tree on the left and I was'nt able.
Thank you again for your answer
After deleting the 5 groups, I could enter the spartial container in the Object-Tab. Hope that helps...
Indeed IfcBuilding "Italian House" had in it's IfcRelAggregates 5 IfcGroups. IfcGroups don't have ObjectPlacement, therefore the error.
I'm not sure if it's widely used in IFC to assign IfcGroups to spatial elements like this but it seems that FreeCAD (file originates from '0.21 build 0','FreeCAD','118df2cf_ed21_438e_a41') is assigning spatial objects to IfcGroups to store groups from FreeCAD hierarchy IFC and IFC do not restrict this use.
So, I've made a change to BlenderBIM, so it wouldn't break in this case, you can test it in the latest version from Github Releases page.
Thank you very much @Andrej730 !
you are right i've created the model in FreeCAD then exported ifc for BBim. In BBim i've "ifcized" storeys and material.
I'm not so skilled in BIM, i've found useful grouping element (for example the complex stair that is built with every single element).
I've thougt using group was a common way as I've read on @yorik blog https://yorik.uncreated.net/blog/2024-005-freecad-news-19 that group can be used like a sort of Layers.
Although we can accommodate this, and this is not illegal, I'd say it's invalid usage. It's invalid from the perspective that there is no defined object composition concept that says this is allowed to be used this way. Aggregation relationships are documented to be used between two of the same type of object, not between two types of objects: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcRelAggregates.htm
Decompositions imply a dependency, implying that the whole depends on the definition of the parts and the parts depend on the existence of the whole.
The spatial composition / decomposition concepts only allow spatial and project relationships, nothing else, see the table at the bottom of https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/concepts/Object_Composition/Aggregation/Spatial_Composition/content.html
Aggregation also forms part of the spatial hierarchy. In contrast groups are non-hierarchical: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcGroup.htm
Grouping relationships are not required to be hierarchical nor do they imply a dependency.
Ping @yorik - I'd say this is a bug that needs to be fixed in FreeCAD.
This is something we do often and like in FreeCAD, to have groups inside the hierarchy. We don't consider it properly a bug, as indeed I couldn't find anything that prevents it in IFC, and all BIM apps seemed to swallow it gracefully... until now :)
That functionality could be removed of course, but it would be a pity, it's useful... It's not used to create assemblies or anything, just to organize the objects in FreeCAD. The objects inside the groups are correctly related to the building structure, so the groups can be fully ignored if must be.
I'd vote to accommodate this ;)
There's nothing wrong with showing groups inside the hierarchy, and Blender also allows for collections with multiple parents and so on, what I think is wrong is using IfcRelAggregates across types. You can keep the functionality, just use a different relationship for it - an IfcRelAssignsToGroup.
I suspect most BIM viewers will swallow it because they don't visually represent placements or bother about authoring, they just show any graphical element.
Here's another scenario clarified by Nick Nisbet (one of the IFC author veterans) explaining why it is invalid: https://github.com/buildingSMART/IDS/issues/262
But IfcRelAssignsToGroup requires an IfcGroup as RelatingGroup (That's what we use already to relate the objects to the group). How do you relate the group to the building structure it's nested in?
Indeed, you use the rel assigns to group with the relating group and the related object is the building structure.
Sorry for not understanding clearly... Wouldn't that make the building structure part of the group, and not the opposite?
Now we do these 3 things:
wall, structure, whatever... -> RelAssignsToGroup -> group
wall, structure, whatever... -> RelAggregates -> buildingStorey
group -> RelAggregates -> buildingStorey
What should we change there ? Make group -> RelAssignsToGroup -> buildingStorey seems wrong, no?
I apologize to the whole OSarch community if i've created a dispute between the Big Boss! :)
It's very difficoult for me to properly read in english, maybe IfcRelReferencedInSpatialStructure as written in https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcGroup.htm
I've to say once more thanks to the community for the possibility to study and learn the IFC schema
No dispute at all ;) We're on the verge of defining a standard!
Short answer, I double checked and actually this is explicitly illegal. This is the exact code that defines it as being invalid in IFC (See WR41 in 5.4.3.68.4 Formal propositions).
Long answer: taking a step back, the reason it's a bit confusing is because IFC is documented in three ways:
The schema itself, which includes data types, cardinality, where rule definitions, and so on. If you do something that disobeys this, it is illegal and should not be supported. However, sometimes the data types are overly broad for technical practicality - this doesn't mean that you can use any combination you want, it's simply to make it easier to define. Also sometimes people forget to check the where rules, such as in this scenario.
The second layer on top is known as "concept templates". These are visualised in chapter 4: fundamental concepts and assumptions. It's not just diagrams, it's actually code behind it. So it defines the "grammar" of how are you allowed to use relationships. For example, it is technically legal to have an IfcRelAggregate that places a bridge inside a building storey, but it is assumed not to occur with any defined meaning because it is not permitted in any concept template (particularly spatial decomposition in chapter 4. Anything which doesn't follow a defined concept has undefined behaviour, so expect things to break and be unsupported :)
The final layer is the written documentation. This is the human readable text. It's surprisingly meaningful - every single sentence in there is there with a purpose, but it's a bit hard to read and it takes a while to get a "feel" of what the original authors intended. If there are interpretation ambiguities, often it is up to the original author to clarify (like Nick Nisbet from the previous post), and otherwise see if there is a way to ideally fix the ambiguity through improving a concept template or even the schema definition itself. Of importance here are the "Informal Propositions" they are things which have even more weight than the regular text because they are attempted to describe something logically black and white that cannot be expressed easily as a formal proposition (a where rule).
(There are also implementer agreements, but phased out in IFC4 and up)
So for those three things you do:
wall, structure, whatever... -> RelAssignsToGroup -> group ... this is completely fine. It is legal, and valid.
wall, structure, whatever... -> RelAggregates -> buildingStorey ... this is legal, but it is invalid. Chapter 4.1.4.1 defines how aggregation is meant to be used, and it is only allowed to be used within IfcElement <--> IfcElement, or IfcSpatialElement <--> IfcSpatialElement. If you want to do IfcElement <--> IfcSpatialElement, you need to use other relationships like ContainedIn or ReferencedIn. There are also informal propositions in the docs on the hierarchy of SpatialElements themselves (e.g. a building can be in a site, but not vice versa).
group -> RelAggregates -> buildingStorey ... like previous, it's invalid. Use RelAssignsToGroup :)
So now addressing:
Wouldn't that make the building structure part of the group, and not the opposite?
... no. There is no parent or child in this scenario. IFC defines relationships as being either hierarchical or non hierarchical. As you've correctly determined, aggregation is a hierarchical relationship, so the "children thingS" (plural) are part of the "parent thing" (single). Other hierarchical relationships are nesting, or same-type relationships group/subgroup, task/subtask, cost/subcost, etc. IFC uses an "ing" and "ed" convention to express 1:N relationships, but this does not mean hierarchical.
However RelAssignsToGroup is not hierarchical. It is similar to say a material relationship or a document reference relationship. It's just ... a relationship. A thing can be in zero, one, or many groups. In contrast, RelAggregates is hierarchical and a thing must exist once, and only once. The specific wording they use is:
The spatial project structure, established by the IfcRelAggregates, shall be acyclic.
So if you rely on an IfcGroup in that hierarchy, you break that rule because IfcGroups can be cyclic.
Now that the mumbo jumbo is out of the way, there's nothing stopping you visualising the RelAssignsToGroup as a (potentially cyclic) tree in FreeCAD. In fact, we do that in BBIM too as an option. By all means, use IfcGroup and it's a great thing and I think it's awesome to support a tree view where groups are the main organisation (note to self: we need to support it too!), so long as you also obey the rest of the IFC constraints (in that somewhere, there needs to be an acyclic aggregation hierarchy).
It would be a bit mad to allow cyclic group relations, ie. Group A is contained in Group B and Group B is contained in Group A.
Groups still need to form a directed acyclic graph (DAG), which allows multiple parents as well as multiple children for each node. Aggregates being fully heirarchical (with maximum one parent per node) are a DAG Tree.
@brunopostle cyclic as in Group A contains a Group B and Wall X. Group B also contains Wall X. But yes, cyclic is generally madness, hierarchical vs non-hierarchical is the more meaningful distinction here.
@Moult said:
Short answer, I double checked and actually this is explicitly illegal. This is the exact code that defines it as being invalid in IFC (See WR41 in 5.4.3.68.4 Formal propositions).
But this doesn't prohibit using IfcGroups in RelatingObjects (atleast explicitly) - it only says that if IfcSpatialStructureElement is part of RelatedObjects then RelatingObject should either be IfcSpatialStructureElement or IfcProject.
Thanks for the explanations @Moult !
So the solution here would be this, given obj1, obj2, obj3 being part of a group1 which is part of storey1?
IfcRelAssignsToGroup([obj1, obj2, obj3, ...], group1)
IfcRelAssignsToGroup(storey1, group1)
And then have some logic to deduce group1 is to be actually part of storey1?
But then how would you differentiate when you want group1 part of storey1 or storey1 part of group1?
IfcRelAssignsToGroup(storey1, group1)
This creates a non-hierarchical relationship between storey1 and group1. It's non-hierarchical, so storey1 is equally part of group1, and group1 contains storey1. You don't need two separate relationships (I'll need to check, maybe you must only have a single relationship). So you'll have IfcRelAssignsToGroup([obj1, obj2, obj3, storey1, storey2, storey3...], group1) etc. Then if FreeCAD wants to visualise that as a hierarchy, that is also allowed, but it is non-hierarchical.
I understand... So we'll have to find something on our own I guess, a way to mark the hierarchy that only FreeCAD sees (with a property or so)
It's a pity because it will become "FreeCAD private"... I guess I know the answer, but do you think it would be worth trying to argument with BuildingSmart people to allow groups to be part of a hierarchical structure?
Other option of course, would be to enforce the illegal move to make our point ;)
I generally think it's not the rich approach, see if you want to visualise this tree:
Site --> Building --> Group --> Storey
This implies two relationships: the first is the hierarchical requirement of IfcRelAggregates(Site, [Building]) and IfcRelAggregates(Building, [Storey]), and then you'll have your non-hierarchical relationships of IfcRelAssignsToGroup([Storey], Group).
Then in FreeCAD you can write logic to visualise it like:
def get_children(element):
if element.is_a("IfcGroup"):
...
else:
if [r for r in element.HasAssignments if r.is_a("IfcRelAssignsToGroup")]:
...
elif site.IsDecomposedBy:
...
... but you can see how this can get recursive. For example, if Building is part of Group, and Building also contains Storey, and Storey is also part of Group, then what? If you lazy load the tree, that's OK and you can handle recursion, but it's probably confusing to users.
My advice is to use a more appropriate semantic class from buildingSMART, not mix the spatial tree and groups. For example, if you want something strictly hierarchical, why not use something hierarchical? IFC supports Composition Types of spatial structure elements. For example you can have a "PARTIAL" building. Basically a generic "this is part of a building". Is it a wing? Is it a module? Is it a shared basement across a multi-building development? Yep ... it's a "part" of a building. I think that's more semantic than "Group". In IFC4X3 they now have explicit FacilityParts.
Alternatively, if you want non-hierarchical, use IfcSpatialZone. It's just... a spatial zone which you can assign whatever meaning. Then FreeCAD can visualise a SpatialZone set of collections perhaps. Users don't even need to think about the spatial tree at all - it's super flexible.
Hmm IfcSpatialZone could indeed be a good subsitute here... It would also have the advantage of probably become visible in other BIM apps too.
But using groups is a very basic action in FreeCAD, we use them everywhere (but they can't be cyclic, nothing in FreeCAD can), it's very handy, instead of having all your bunch of objects under your Storey, you can organize them into groups (which are specific to that storey). But it does not always correspond to a spatial zone, sometimes you group for ex. all IPE120 beams... Using a spatial zone for something that is not a spatial zone seems wrong too...
I think I'll play a bit with the spatial zone concept, and then also stop aggregating the groups into the storeys (I guess I'll find another "hidden" way to have FreeCAD spot them and aggregate them)
Login or Register to reply.