Material simplification

[michelangelo-acca]

The simplification of materials is cool, but during the implementation we found "strange" that to identify a material, we had to look for "objects with "bsi::presentation::diffuseColor" and hopefully with a "bsi::name".

Could the use of something similar to "bsi::ifc::v5a::class" but for IfcMaterial be more elegant?

[michelangelo-acca]

Plot Twist: now there is a "bsi::ifc::v5a::material" attribute to "identify" materials...and nodes inherits from it (both "objects", like in the case of the wall, and "meshes", like in the case of the window frame and glazing) 😮

Still, the space, has an "old style" material attached (i.e. without "bsi::ifc::v5a::material").

• Is this an error or is it intended to be like this?
• If it is an error, out of curiosity, is the IFC5 file considered "invalid" even if passes all JSONs checks?

[aothms]

Still, the space, has an "old style" material attached (i.e. without "bsi::ifc::v5a::material").

Very sharp. Not really "old style" because fully old style would still be to have the materialbinding schema applied.

This is an intentional easter egg from me though. It allows to separate the presentation aspect from the material, similar to how we have that in IFC4 where you can style the representation items or have a material applied to the product.

In this particular case the space doesn't have "a material" but does have a "presentation", which I think is semantically quite fitting.

is the IFC5 file considered "invalid" even if passes all JSONs checks?

This is still the biggest open question to me. How much schema will we have that governs the validity of the combination of schemas. I think a prime example of this is [0]: you cannot assign a material to a virtual element or to an opening. On the one hand I think this is well-intentioned and valuable, but on the other hand, there are so many valid exceptions to this where this would have made sense.. So my tentative conclusion is that this becomes more the scope of IDS, but I'm happy to be proven wrong.

[0] https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcRelAssociatesMaterial.htm#5.4.3.46.4-Formal-propositions

[michelangelo-acca]

Ok, just another question: in the current wall example, the Space has the presentation, while it's mesh does not. Still, in the viewer, the mesh takes the "material" (or presentation) of the parent. Is this rule written somewhere or the example needs to be changed now that we have the possibility to put material directly on meshes?

[aothms]

We have indeed been discussing this.

I'm personally open to all options here. Currently it's a bit like a scene graph approach: material/styling affects all descendants of a node (a bit similar to positioning). I'm also fine if we decide that the presentation needs to be always on the mesh or always on the parent. In the frame/glazing case it would be a bit wasteful to have to introduce another node in order to have a parent to the mesh. I can also imagine cases where if you have assemblies of many elements of the same material you might want to relate that at a higher level. Hence, I'm ok with material affecting all descendants as it generalises this. Do you or your team have opinions on this @michelangelo-acca ?

[michelangelo-acca]

Thanks for the clarification, no strong opinions on this, its just that during implementation, at the moment we limited the lookup of the material/presentation only to the direct parent, because we tought that if you have a file with an IfcSite with a presentation, and no other descending object have one, than you see all of the colour of the Site, which may be odd...but given the Assembly requirement (aka material on type?) than it could be ok to look upper in the hierarchy...

[michelangelo-acca]

Quick question: what is the colour of the presentation of the "Void" node of the Window in the example?

• None, because it's mesh does not have a material
• Concrete, because the Window is descendent of the Wall and its the closest parent with a material
• None, because the Wall is far away from the Window in the hierarchy (but then how far is too far?)
• Other (?)

[aothms]

Great question, another option:

• None, because Voids never have a material/presentation

I think we should discuss this with a bigger group of people. I don't have a preference, the people like you building importers and exporters should decide what makes sense in relation to their own native data models.

[michelangelo-acca]

Ok, just as a reminder...would the situation change, and if yes how, if the material of the wall was on it's mesh and not on the object itself?