OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.22164 (Git)
Build type: Release
Branch: master
Hash: f2a9f712e8d68ee2393d0fe748c02096c4148a32
Python version: 3.8.5
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: English/United States (en_US)
Probably something Basic I do wrong?
When Exporting to IFC, objects ‘Jump’
Imported in Blender (BlenderBim) (same result in other ifc viewers:
Freecad File attached
DhFundament.FCStd (152 KB)
I can confirm the problem. In most cases the following export preference helps: “Force export as Brep”. but it does not here.
What helped is to use Part → simple copy to make a copy of all objects. Means something inside the arch objects seams wrong.
attached a file only consisting of two objects. In IfcPlusPlus something is wrong.
structure_ifcexport_problem_01.FCStd (12.7 KB)
structure_ifcexport_problem_01.ifc (4.44 KB)
BTW: if the ifc is reimported in FreeCAD both are correct imported.
Thx
BTW tried recompute on all beams… different, but not desired result
BTW 2
Is there a way to define objects in general, in this case Structure/ifcBeam so that it will export to ifc4 with quantities From FreeCAD?
Imported to BlenderBIM, looks correct, but no base QTY.
When ticking the boxes in BlenderBIM, we get ‘guess’ the above data
Importing structure_ifcexport_problem_01.ifc in BimSync, no Base QTY show up
If applying Base Qty in BlenderBIM, then exporting, they will
Will try to document this somewhere 
What is the correct way to copy a structure object, preserving location ?
how did you do it? Can you reproduce the problem in a step by step follow up.
Somehow there some issue with it. But I can not find it. As soon as a simple copy or another structure is made the problem is gone.
Will try to
Trying to replicate verbally:
Will try to replicate in model later.
for me it seams to be a viewerproblem …
ifc exported from the file provided in the first post …
only blender does not show the objects.
screens follow …
DhFundament.ifc (40.3 KB)
@bernd
@Moult https://community.osarch.org/discussion/183/blenderbim-imported-geometry-wrong#latest|Post in BlenderBIM, solution.
>>> f = ifcopenshell.open('/home/dion/drive/bim/DhFundament.ifc')
>>> for e in f.by_type('IfcElement'):
... e.GlobalId = ifcopenshell.guid.new()
>>> f.write('/home/dion/drive/bim/DhFundament2.ifc')
Maybe we should implement this, avoiding duplicate GUID’s
Regards
open the file from this post: https://forum.freecadweb.org/viewtopic.php?f=39&t=49689#p425838
rund following code:
App.ActiveDocument.Structure023.IfcData["IfcUID"]
App.ActiveDocument.Structure045.IfcData["IfcUID"]
>>>
>>> App.ActiveDocument.Structure023.IfcData["IfcUID"]
'0kEY3dMYL4nguYLQ7LgyaC'
>>> App.ActiveDocument.Structure045.IfcData["IfcUID"]
'0kEY3dMYL4nguYLQ7LgyaC'
>>>
The uuid are identical and thus identical exported in the ifc file. This should never ever happen in an exported ifc file.
It is very easy to reproduce …
This should normally not fixed in export. The copy method should return an unique id already. But this is rather difficault, since there are dozens of tools which copy in FreeCAD. Thus we need to takle this on ifc export.
Most import is FreeCAD should write ifc files with unique uuids.
the code which reads the id or generates a new one. https://github.com/FreeCAD/FreeCAD/blob/c06a4d462b06/src/Mod/Arch/exportIFC.py#L2305-L2319
I have been thinking …
This is quite easy.
IfcData should not be a part of the FreeCAD document. IfcUID should be generated based on the object name (Structure023/Structure045).
Reading https://community.osarch.org/discussion/183/blenderbim-imported-geometry-wrong#latest|Post%20in%20BlenderBIM would imply that the IFCUid would need to be a ‘Global’ unique identifier. If it really needs to be truly Globally unique, I think the only option would be to use an (essentially) randomly created UUID: https://docs.python.org/2/library/uuid.html#uuid.uuid1 by using uuid.uuid1() or uuid.uuid4().
However, it seems that the ‘Global’ uniqueness needs to hold only on the document level, in which case the best bet would probably be to deteministically hash a known document-unique identfier, e.g. the previously suggested object “FullName”.
import hashlib
m = hashlib.blake2b(digest_size = 16)
hashstring = App.ActiveDocument.ActiveObject.FullName.encode("ascii")
m.update(hashstring)
print(hashstring)
print(m.hexdigest())
The advantage would be that the resulting 128-bit number would stay the same not only during document editing, but after load/save cycles on different computers. But would it actually be an advantage or disadvantage, that depends on what the ‘Global’ uniqueness should mean in this case.
EDIT:
So you’d need to change the uid = ifcopenshell.guid.new() on line 2313 of https://github.com/FreeCAD/FreeCAD/blob/c06a4d462b06/src/Mod/Arch/exportIFC.py#L2305-L2319 to
if not uid:
hash_for_uid = hashlib.blake2b(digest_size = 16)
hash_for_uid.update(obj.FullName.encode("ascii"))
uid = ifcopenshell.guid.compress(hash_for_uid.hexdigest())
# storing the uid for further use
if preferences['STORE_UID'] and hasattr(obj,"IfcData"):
d = obj.IfcData
d["IfcUID"] = uid
obj.IfcData = d
return uid
or something similar. Totally untested, as I don’t have ifcopenshell installed on this computer. Also, there should not be the if not uid: conditional, I think, because there would be a need to update the uid for any copied object. So, that logic needs to change, too.
According to the discussion in https://forums.buildingsmart.org/t/ifcgloballyuniqueids-spec-description-is-incorrect-proposal-to-simplify/1083 it has actually historically used uuid.uuid1() as I suggested above, but Yorik seems to have changed it to the current implementation, which overlooks the object linking/copying effects.
