Textures and Colors: Criticisms and Issues

Developers
1

This Topic will catalog the criticisms and issues regarding current methodologies and implementations of colors and textures for IFC2x3 and IFC4.x.

2

I will try to be as granular as possible, so that each one can be addressed an in itemized fashion in the thread to do with proposed solutions.

Issues about colours

  1. Out of the 4 entities that can represent a colour, it is assumed, but not made explicit in the documentation that IfcSurfaceStyleShading is the lowest denominator for viewers to use when trying to find an RGBA colour for a material. This ambiguity leads to ambiguous vendor support.
  2. Externally defined surface styles have no guidance on their implementation. This makes vendors hesitant on how to integrate it seamlessly for the user experience.
  3. IfcSurfaceStyleRendering is based on outdated rendering engine parameters, and do not apply to the multitude of modern rendering engines, which are fast moving targets.
  4. IfcSurfaceStyleLighting may not appropriately describe the material adequately for lighting simulation.

Issues about textures

  1. IfcSurfaceStyleWithTextures allows multiple textures to be applied, but the blend modes are unconventionally stored in the textures rather than the surface style. Furthermore, the blend modes are simplistic, and do not adequately represent the complex shader trees in use nowadays. I would argue that it is simply not worth it.
  2. Externally defined surface styles have no guidance on their implementation. This makes vendors hesitant on how to integrate it seamlessly for the user experience.
  3. Why do we have IfcPixelTexture? Why reinvent image formats? It does not seem useful to me.
  4. I would argue that IfcBlobTexture additionally adds unecessary complexity in (de)serialisation, given that IFC is expected to be used in a multitude of formats, not just IFC-SPF.
  5. IfcTextureCoordinateGenerator relies vendors to support X3D coordinate mapping, whereas the usecases most likely use other engines that do not rely on X3D and would prefer more modern coordinate systems. I would conclude that these coordinates are largely obsolete.
  6. IfcTextureMap needs investigation to determine whether or not the specification of UVs can be simplified or limited in scope.
  7. The coordinates described in IfcBlock, IfcRectangularPyramid, and all other primitive shapes and shape items that have coordinates prescribed, sound like edge-case specification. To prevent overcomplication for vendors, I would recommend that coordinates should be limited to shape geometries that are meshed, not parametric ones.

Issues about lights

TODO

Issues about object proxies

TODO

Issues about colour / texture assignment

TODO

  1. IFC materials are not rooted.
  2. The definition of material colours and arbitrary colours is blurred. Users expect a clear delineation between colours that represent a material, and an arbitrary colour that represents a property.
  3. The methodology and workflows of arbitrary colour assignments needs to be clearly defined.
  4. Parametric colours are really hard to implement.
  5. Procedural textures are really hard to implement.
  6. The currently chosen properties for CG colours / textures are outdated, and do not map well to modern industry expectations. It may never achieve this, due to the fast paced nature of the CG industry compared to the AEC industry.
  7. The currently chosen properties for lighting simulation colours / textures may not map well to modern industry expectations. This needs review, and guidance provided for the most popular validated engines.
  8. Same as previous point, but further review needs to be had on luminaire definitions, not just materials.
  9. 2D colours and 3D colours need consolidation.
  10. Explicit specifications need to be made on how to handle proxied geometry and how it interacts with colours.