mirror of
https://github.com/IfcOpenShell/IfcOpenShell.git
synced 2026-08-14 11:24:19 +00:00
Dion Moult
8cf7057abc
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.