If you move a wall, and that wall has features (e.g. openings), it's
desirable to also move those openings (because they are invisible). This
is a special exception to `should_transform_children` because the
definition of the feature (opening) is inherently tied to the parent
(wall).
What wasn't considered is that this would typically then also move
subchildren of the features (e.g. fills like doors). I'm surprised
nobody caught this earlier.
I did also consider another approach where if you move a wall, it moves
all unfilled openings, and if you move a door which fills a opening, it
moves the opening too. Intuitively it sounds nice, but it doesn't work
because:
- Openings can have multiple fillings. If you move all fillings, they
all fight to move the openings.
- All logic about children goes one way: a placement may have child
placements relative to it. This breaks the convention (if moving a door
instead moves its opening) which can make brains explode.
- It starts to conflate rules about relative / referenced placements
with spatial decomposition. We assume all IFCs are valid and follows the
convention of relative placement but we cannot guarantee this. This also
leads to brain explosion.
Previously the code looked for additive facets (entity, instance)
anywhere in the query, and then only added the default basket once at
the beginning of the query. This change makes it look for additive
facets in order (that way you could start with a default selection, and
then later use an additive facet) and does it per facet list (so you can
omit the additive facet at the beginning of each list).
The IDS documentation used to state that "optional" on requirement
facets was "for information only" and didn't affect the pass / fail
state. This was changed a while ago (which I missed) to a new behaviour:
both no values and passing values will pass.
Previously, to edit a single IfcMaterial pset, you'd do so in the
material manager. In contrast, to edit a IfcMaterialSet pset, you'd do
so only when assigned to an object. Not only is it bad to edit psets in
two locations, it also means you can't edit psets until you've first
assigned the material set to an object which is bad. Now it's less code,
and material / material set psets are in the same spot.
There still more consolidation work to do, to allow editing of sets in
the material manager and to figure out how to show item psets, but it's
a step in the right direction.
Dion Moult