This Shift-E still needs more polish as we figure out the best hotkeys
and what's most natural to users when they select different combinations
of objects, so expect the conditionals that govern when Shift-E does
things to still change in the future.
There are a few differences to the previous implementation:
1. It is no longer recalculated on wall regeneration. The new wall
regeneration is strict to the spec on the rules of rel connects path,
and so this being a "userdefined" connection we only calculate it
explicitly when the user invokes the operator.
2. It uses meshes instead of clipping planes, so you can clip to
strange shapes or gable roofs or whatever. Nice.
The issue was caused by deleting an object outside the aggregate while in
aggregate mode. The selection for these objects are now disabled to prevent
this issue
- Implementation of @theoryshaw PR #5922.
- Note: `IfcPropertyEnumeration` allows multiple choices, but this is not
applicable for this use case. Users must manually deselect other options;
otherwise, it defaults to the first selected option.
for occurrence classes without special type.
E.g. previously:
you select IfcSlab and change it to IfcRoof - since there is not IfcRoofType in IFC2X3 it would figure the matching product type is IfcBeamType and change this slab's type element to IfcBeamType. IfcBuildingElementProxyType seems more generic and fitting.
E.g. you select IfcSlab and change it to IfcRoof - since there is not IfcRoofType in IFC2X3 it would figure the matching product type is IfcBeamType (which is confusing too but that's another subject) and change this slab's type object to IfcBeamType which consequently change IfcSlab to IfcBeam instead of IfcRoof that was selected originally.
Noticed investigating #5918
Previously, changing props.ifc_file had an update hook to reload
information about the IFC model. But this isn't always correct because
there are two situations:
1. The ifc_file path changed because you saved the file for the first
time or saved as, and this is merely recording a new saved path of the
existing file object.
2. The ifc_file path changed because the user manually changed it or
selected a new file. This could reference an entirely new file object.
This is dangerous because we can't trust anything anymore, including our
undo history.
So the new default situation is that there is no magic hook. If you
change props.ifc_file, that's all it changes ... just a path stored in
Blender with not much significance.
If the user runs select_ifc_file to explicitly relink the file, it now
explicitly purges in that situation and clears the undo history.
Basically now behaviour is explicit, not using magic hooks.
Bruno Perdigão