Is there an nice way to accommodate mirroring objects in the schema?
If not, is it possible to propose one for the NextGen?
cross posted to: Mirroring · Issue #86 · buildingSMART/NextGen-IFC · GitHub
Isn’t that one of the simpler cases of a Cartesian transformation operation carried out with mapped items?
Indeed it is already possible using a non-uniform cartesian transformation within a mapped item, but I wouldn’t exactly call it “nice” 
With this method, perhaps some of the object is mirrored, and others not. This adds to the confusion about the implied constraints of how mapped representations should be used.
Further reading on this topic:
- Controversial proposal to drastically simpify mapped representations
- Is IfcProductDefinitionShape a 1:1 relationship? - #4 by angel.velez
On this topic I’m a proponent of “less is more” and would want to rethink how mirroring (and other common geometric modifiers, like arrays) can be applied without overcomplicated the already complex representation tree.
1 Like
Philosophical response coming up.
I think the ability to simply represent mirrored objects is what differentiates CAD from BIM. And by that, I mean that it is a CAD ability, not a BIM ability. What real world object is the same if you mirror it? I believe - and happy to be wrong on this - that a mirror of an object is really just a simplification/shortcut when modelling, and not representative of real-life part numbers, etc.
Ditto non-uniform transforms. Unless your house is made out of silly putty, you shouldn’t model all walls as cubes with non-uniform transforms. Maybe a beam or column with a non-uniform scale along the axis? But that should be explicit and not buried inside a geometric entity somewhere in your tree.
Personally, then, I’d like to see non-uniform mirrored transforms removed from IFC.
2 Likes
Cheers @angel.velez - I think everybody agrees on the distinction between CAD ability and BIM ability.
Personally, though I’m not quite sure I buy your argument. The utility to designers is just too great to ignore. Every BIM tool has a mirror feature, and it is semantically meaningful to the designer that when they author one, the mirrored version is also authored, therefore I would expect to see it in IFC too.
Since it is a CAD ability and not a BIM ability, that implies it should be a non-rooted entity, but does not disqualify its utility from IFC.
Would agree, the utility is too great to ignore.
+1 for mirroring.
in the trench discussion: BlenderBIM: mirrored objects don't export · Issue #1496 · IfcOpenShell/IfcOpenShell · GitHub
I believe mirroring and also scaling introduce so many chances of problems that it might not be worth it in the end…
What is the swing direction of a mirrored left swing door?
What is the volume of a 2x scaled 111m cube?
For manufacturers, mirrored variants have different product codes or serial numbers.
Another trivia is that mirroring reverses the surface normals (the determinant of your transformation matrix is negative). Which is solvable of course, but should be taken into account.
Any object (or object type) that is a mirror of another object, especially those which contain multiple elements that change the “handedness” (left/right) of an object, should become another distinct object/object type. Many factors (orientation, sub-element placement, orientation, and handedness, surface normals, etc.) all rely on explicit statement of object/object type REAL orientation/placement.
Mirroring is a convention/convenience of production in the tools. It should NOT be part of the IFC schema. Any mirroring should be devolved either automatically or manually prior to encoding and sharing via IFC.
Same goes for scaling.
If one takes the stance that IFC should never be the native file of a BIM application, it would make sense. Not sure why this stance would be taken.
If however, you have a scenerio where the IFC is the native file of an application, it would seem to make sense to encode this mirroring into the schema somehow.
If it’s never allowed in the schema, would programs like BlenderBIM and Constructivity (among others i’m sure), which rely solely on the IFC file, never be able to offer this convenience of mirrored instances?
Then mirroring should be an operation/transformation, not a data type or feature of an analogue representation in itself. This is problematic whether one uses a proprietary or open format. Where in the real world does a “mirrored” object or type exist?
Again, copy/Paste, Mirror, etc. are conventions/conveniences of the digital authoring process. They are not real representations. For BIM data to be consistent and reliable, especially as it may be further transformed, analyzed, and used for a plethora of other purposes, such processes should not be persistent in the encoding of the information. At some point, the operation should be stripped and the result have non-mirrored attributes of orientation, handedness, etc.
Examples… If I mirror a toilet in a floor plan, there may be little or no impact because of the nature of the object. but if I mirror an offset corner cabinet, where a door may originally be on the left side, but in the mirrored version it is on the right side, these are two different physical configurations and must be counted and documented as such.