IFC4 Reference View - open discussion items

[TLiebich]

In order to close the first round of specification work of the new IFC4 reference View, the following items should be discussed and concluded on:

• using local placement: are we using local placement as an object placement (without the need for cascading placement systems as in IFC2x3 CV)? It would then be similar to the X3D position, but would still involve matrix operations on the vertices
• adding IfcGrid: a grid is an important items for coordination, also for linked reference models, when added, we also add 2D curve geometry (lines and arcs)
• adding IfcOpeningElement as semantic information (not as subtraction shapes): should we keep the opening information (e.g. to keep the sizes and attributes) and use shape aspects to represent it?

[jlkiss]

One more thing should be discussed: if the main goal of Reference View is to exchange models in WYSIWYG mode, the correct color information have to be there. But allowing swept geometries in the MVD some restriction should be applied: if the extrusion/revolved/… geometries have multiple color faces then tessellation geometries should be used instead. I think this would worth an agreement!

[timchipman]

On the topic of local placement, I would vote to keep the cascading placement as-is for the following reasons:

1. Compatibility
2. Translating or rotating an object would then require updating all descendent objects, possibly causing round-off issues [though the reference view isn't supposed to be for editing, some apps could allow such basic move operations]
3. Applications would need to perform additional processing when converting to/from Reference View
4. Woud otherwise require additional efforts by implementers

[timchipman]

On the topic of color information, each triangle can be specifically colored or textured within IfcTriangulatedSurfaceModel, and each face can be specifically colored or textured within IfcFacetedBrep. For other geometry however, nothing is currently defined for how specific faces would be identified, though it is possible to link specific solids as a whole.

For scenarios where an element has different colors on different faces, IfcTriangulatedSurfaceModel would seem to fit the most typical scenario for custom product types. For building elements such as walls, any paint or wall coverings on either side should use IfcCovering which can have dedicated color or texture, while each component or layer of an IfcWall (e.g. studs, insulation) would have separate geometric representation items, each having their own styles attached. For implicit parametric elements, it's also possible to use IfcMaterialConstituentSet, IfcMaterialLayerSet, or IfcMaterialProfileSet to define colors and correlate to geometry via IfcShapeAspect.

[timchipman]

On the topic of openings, keeping IfcOpening intact would seem to be a good thing, with or without IfcDoor or IfcWindow filling the opening - then the relationships are kept intact and semantic information is retained. This would also seem to simplify implementation when switching between Reference View and Design Handover View -- then an export of the Reference View would amount to reducing the representation detail exported, but not the structure of objects and relationships and any derivative information (e.g. property sets) that may be attached.

[TLiebich]

on @jlkiss - yes the way to handle single face coloring and also textures in IFC4 reference view is using IfcTriangulatedSurfaceModel, if one of the acceptable subtype of IfcSweptSolid is used for a more compressed geometric representation, such as IfcSweptDiskSolid, it is restricted to a single color for the whole shape. Explanations provided by @timchipman for implicit geometric elements, using IfcMaterialLayerSet, etc. only relate to the IFC4 handover view (presentation by material is out of scope of the IFC4 reference view).

[timchipman]

For applying colors and textures, the following entities are in scope for both RV and DTV: IfcStyledItem IfcSurfaceStyle IfcSurfaceStyleShading IfcSurfaceStyleRendering IfcSurfaceStyleWithTextures IfcImageTexture IfcIndexedColourMap IfcIndexedTextureMap

Values for transparency have been added to IfcIndexedColourMap (overall transparency, not per-triangle as with color), and promoted to IfcSurfaceStyleShading (already defined on IfcSurfaceStyleRendering).