B
by bernd on 16 Dec 2020, edited 17 Dec 2020
#
BlenderBIM exports a IfcMaterialLayer this way:
#199=IFCMATERIALLAYER(#112,200.,.F.,'Concrete, Cast-in-Place gray',$,$,0);
The last entry (the "0") ist the priority. This is a an integervalue.
https://standards.buildingsmart.org/IFC/RELEASE/IFC4_1/FINAL/HTML/schema/ifcmaterialresource/lexical/ifcmateriallayer.htm
BlenderBIM does saved it as "0". Is this the correct way to save a integer? I found other integers are saved as "IFCINTEGER(2)" in the ifc.
The reason for asking is as follows. A cloud plattform we use has problems importing ifcs exported from Blender because of this integer. If I add a "." to the integer the file will be imported, but this would be clearly wrong as it is an integer value.
I just would like to be sure who is guilty before I get in touch with them once again.
cheers bernd
M
by Moult on 16 Dec 2020
#
Good catch. I'm not so sure. Ping @aothms
S
by stephen_l on 16 Dec 2020
#
Looks like an archiCad's way to store some values
A
by aothms on 16 Dec 2020
#
+2 votes
BlenderBIM does saved it as "0". Is this the correct way to save a integer?
Yes, it's the only way even 0.0 e.g is wrong.
I found other integers are saved as "IFCINTEGER(2)" in the ifc.
That's when the type of the attribute is of a Select, so the instantiation can choose concrete type. For example in properties the type of the value van be set at runtime as it is a select, but than needs to be qualified with the type. E.g IfcReal(0.0) or IfcLengthMeasure(0.0).
So I don't think BlenderBIM is in any way at fault here
B
by bernd on 17 Dec 2020
#
+1 votes
Just got feedback from the cloud plattform. They will adapt the plattform.
BTW: I am glad they do adapt it and thus adopt the standard. They are one of the bigger player in the market.