buildingSMART Forums

1-Current Situation

This topic will collect and document the current situation of the use of colors and textures in IFC2x3 and IFC4.x. This should include schema representations, summary of intents/results, and implementations to date (such as certification MVDs or other “official” MVDs).

I’ll start this list on all the current possibilities of assigning colours and textures. I expect it to be incomplete, so I will edit this post when others point out things I’ve missed - and ideally for each possibility, we can produce a sample file.

Colours

Colours can be represented using one or more of these entities, of which the viewing application decides which they choose to visualise.

  1. IfcSurfaceStyleShading - RGBA, as simple as it gets. Supported by most vendors.
  2. IfcSurfaceStyleRendering - an attempt at CG colour properties. Mostly legacy, and not compatible with most modern shaders. Some vendor support.
  3. IfcSurfaceStyleLighting - colour properties for lighting simulation. Its applicability to validated engines needs review. Little to no vendor support.
  4. IfcExternallyDefinedSurfaceStyle - any advanced colour support. Little to no vendor support.

Textures

Textures definitions can be represented using one or more of these entities, of which the viewing application decides which they choose to visualise.

As a whole, I believe we can claim little to no vendor support for everything here.

  1. IfcSurfaceStyleWithTextures - the standard way to define a texture
  2. IfcExternallyDefinedSurfaceStyle - any advanced colour support. Little to no vendor support.

The texture data itself is then represented by one of the mutually exclusive following subtypes of IfcSurfaceTexture:

  1. IfcBlobTexture - embedded binary
  2. IfcImageTexture - a URI to a texture
  3. IfcPixelTexture - masochistic binary

Note: the above also defines a portion of the mapping (repetition) and shader tree (blend modes), which is highly unconventional from a CG standpoint.

The texture mapping is then represented by one of the mutually exclusive following:

  1. IfcTextureCoordinateGenerator - procedural mapping, based on X3D.
  2. IfcTextureMap - standard UV coords.

Note: the X3D procedural mappings are highly specific and may not be compatible with other procedural mappings provided by the CG industry.

Depending on the geometry, procedural texture coordinates are also defined on a geometry by geometry basis. The list shows those currently defined:

  1. IfcBlock - part of IfcCsgPrimitive3D
  2. IfcRectangularPyramid - part of IfcCsgPrimitive3D
  3. IfcRightCircularCone - part of IfcCsgPrimitive3D
  4. IfcRightCircularCylinder - part of IfcCsgPrimitive3D
  5. IfcSphere - part of IfcCsgPrimitive3D
  6. IfcExtrudedAreaSolid

Lighting

A discussion on colours and textures is not complete without discussing lighting. As lighting is necessary for both usecases of validated rendering and CG visualisation. The following entities may be used to describe lights.

Little to no vendor support for all, I believe.

Object proxying

A discussion on colours and textures it not complete without discussing object proxying. Proxy objects are necessary for the usecase of CG visualisation, where geometry is often substituted for those optimised for visualisation. Examples include grass and vegetation, entourage, furniture, colour schemes, optioneering for leasing, modular construction, animated content, highly parametric shapes …

Currently, the only known method is through:

  1. IfcDocumentReference - an unofficial convention is established on how to parse the document and retrieve geometry, merge colours, and merge textures, and how it interacts with parameters and animated shape keys

Little to no vendor support.

Colour and texture assignment

Either colours or textures may be assigned using the following techniques (deprecated techniques are omitted):

1. Using IfcStyledItem to assign a surface style to a single representation item

Diagram.

Chain of access from an element:

element.Representation.Representation[0].Items[0].StyledByItem.Styles[0].Styles[0]

Note: In IFC2X3, there is an additional Styles[0] in the chain.

2. Assigning a single material, which then has a colour.

Diagram.

Chain of access from an element:

element.HasAssociations[0].RelatingMaterial.HasRepresentation.Representations[0].Items[0].Styles[0].Styles[0]

Note: In IFC2X3, there is an additional Styles[0] in the chain.

3. Assigning material layers, of which each have a colour (variation of technique 2)

Diagram. Diagram 2.

Chain of access from an element:

element.HasAssociations[0].RelatingMaterial.ForLayerSet.MaterialLayers[0].Material.HasRepresentation.Representations[0].Items[0].Styles[0].Styles[0]

Note: In IFC2X3, there is an additional Styles[0] in the chain.
Note: a IfcMaterialLayerSetUsage is required, I believe.
Note: limited support by vendors due to parametric determination of colours.

4. Assigning material profiles, of which each have a colour (variation of technique 2)

Diagram. Diagram 2.

Chain of access from an element:

element.HasAssociations[0].RelatingMaterial.ForProfileSet.MaterialProfiles[0].Material.HasRepresentation.Representations[0].Items[0].Styles[0].Styles[0]

Note: In IFC2X3, there is an additional Styles[0] in the chain.
Note: a IfcMaterialProfileSetUsage is required, I believe.
Note: limited support by vendors due to parametric determination of colours.

5. Assigning material constituents, of which each have a colour (variation of technique 2)

Diagram. Diagram 2. Diagram 3.

Chain of access from an element:

element.HasAssociations[0].RelatingMaterial.MaterialConstituents[0].Material.HasRepresentation.Representations[0].Items[0].Styles[0].Styles[0]

In addition, a comparison needs to be made with these two chains:

element.HasAssociations[0].RelatingMaterial.MaterialConstituents[0]
element.Representation.HasShapeAspects[0].ShapeRepresentation[0]

Note: In IFC2X3, there is an additional Styles[0] in the chain.
Note: a IfcShapeAspect is required.
Note: what is the vendor support for this?

2 Likes