Should IFC have a convention that codifies what the representation looks like relative to if the object is ‘cut’ by some some camera?
Maybe a boolean attribute like TargetCut
?
Would allow things like door swings to not show up, if not cut.
Should IFC have a convention that codifies what the representation looks like relative to if the object is ‘cut’ by some some camera?
Maybe a boolean attribute like TargetCut
?
Would allow things like door swings to not show up, if not cut.
Hey Ryan, I think this is rather specific to Bonsai. The camera object there is just an IfcAnnotation with a custom ObjectType and paper space info has been ruled out of scope pretty much in IFC4.
There are a couple of projects that want to do drawing generation based on IFC such as the BIMLegal project here in the Netherlands. But they don’t reach this kind of need for visual styling and need for interoperability on the drawing semantics.
I notice that IFC already includes IfcGeometricProjectionEnum
with options like PLAN_VIEW
, SECTION_VIEW
, and ELEVATION_VIEW
. That seems to recognize that objects may need to look different depending on the drawing or viewing context. It makes me wonder, why was this concept of accommodating different representations introduced in the first place, if not to reflect how geometry appears in different views or drawings? Following that logic, wouldn’t distinctions like cut versus projection be a natural extension of the same principle? Couldn’t there be a way to codify this condition alongside TargetView
so that drawing generation from IFC becomes more predictable and interoperable?
If IfcGeometricProjectionEnum
was created to capture the idea that geometry appears differently in plan, section, or elevation, then isn’t “cut versus projection” just another instance of the same underlying idea? The goal isn’t to redefine the object itself, but to acknowledge that representations change depending on how the viewer encounters them.