Part of the transition process disconnecting blender materials from IFC materials to make it less confusing.
E.g. previously if we would load an element A with material M and style S it would load it as blender material M that looks like S.
But also if you would load element B with just style S, it would add it as blender material M though B has nothing to do with material M.
Noticed after error below trying to duplicate an element
File "addons\blenderbim\bim\module\geometry\operator.py", line 769, in execute
return OverrideDuplicateMove.execute_duplicate_operator(self, context, linked=False)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "addons\blenderbim\bim\module\geometry\operator.py", line 778, in execute_duplicate_operator
IfcStore.execute_ifc_operator(self, context)
File "addons\blenderbim\bim\ifc.py", line 381, in execute_ifc_operator
result = getattr(operator, "_execute")(context)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "addons\blenderbim\bim\module\geometry\operator.py", line 772, in _execute
return OverrideDuplicateMove.execute_ifc_duplicate_operator(self, context)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "addons\blenderbim\bim\module\geometry\operator.py", line 855, in execute_ifc_duplicate_operator
new = blenderbim.core.root.copy_class(tool.Ifc, tool.Collector, tool.Geometry, tool.Root, obj=new_obj)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "addons\blenderbim\core\root.py", line 54, in copy_class
collector.assign(obj)
File "addons\blenderbim\tool\collector.py", line 62, in assign
collection.objects.link(obj)
RuntimeError: Error: Object 'IfcActuator/Cube.001' already in collection 'IfcBuildingStorey/My Storey'
Previously there was a problem with this method that it might confuse Blender objects copied from other sessions (or even from the current session but a few steps back) from current IFC objects and might unlink them accidentally.
Option to provide either element or obj was more of a convenience feature but now they have a different meaning to clearly distinguish between unlinking ifc element and unlinking some blender object without touching any ifc elements.
This ensures that IOS-Python always 1) has the appropriate version and 2) contains exactly the same content as PyPI (i.e. with the latest Python files that might be outdated from the bot builds)
It wasn't considering that IfcTaskTimeRecurring might be just created and IfcTaskTimeRecurring.Recurrence is None resulting in error below
File "\api\sequence\assign_recurrence_pattern.py", line 120, in assign_recurrence_pattern
if len(file.get_inverse(settings["parent"].Recurrence)) == 1:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\file.py", line 524, in get_inverse
inverses = [entity_instance(e, self) for e in self.wrapped_data.get_inverse(inst.wrapped_data)]
AttributeError: 'NoneType' object has no attribute 'wrapped_data'
1) It wasn't removing ownerhistory in the case if task was RelatingObject in IfcRelNests
2) Replaced handling of IfcRelNests as an inverse with direct api calls.
3) Added some basic tests.
It seems there is a lot of copy paste going on here. There needs to be a more detailed review once the v0.8.0 blob is more stable because right now I cannot fully test - it's hard to say if create_shape fails due to our bug or due to v0.8.0 not yet being stable. I'll revisit this later.
Thomas Krijnen
