Proposal to align documentation to X3D and glTF standards for reflectance models

[Moult]

Credits to Ilkin, mentored by Jakob Beetz, and Michalis from X3D who have helped research, implement, and come to this proposal. However, I have just typed out this proposal, and they have not yet read it yet so do not assume they support this just yet :)

Further reading: https://community.osarch.org/discussion/877/understanding-how-textures-and-shaders-work-in-ifc

Current situation

The current IfcReflectanceMethodEnum used in IfcSurfaceStyleRendering references outdated, biased rendering techniques that provide limited value in the CG visualisation workflows. The current list is:

BLINN, FLAT, GLASS, MATT, METAL, MIRROR, PHONG, PLASTIC, STRAUSS, NOTDEFINED

This list of reflectance models (or lighting methods), were popular in the past when rendering was computationally expensive. Nowadays, they have limited value to artists, who have since moved on to physically based rendering workflows. For example, the last Blender release which supports these biased rendering workflows was in March 2018. Now, they are increasingly impossible to support.

Some of these reflectance models are also amgiuously defined. For example, "METAL" could refer to the proprietary 3DS Max "Metal" shader, or any other arbitrary app's implementation. Some have clearer definitions which can be replicated across applications: "BLINN, FLAT, PHONG, STRAUSS".

Proposal description

IFC currently references the VRML ISO standard for its rendering capabilities. VRML has been superseded by X3D v3.2 (which has already been referenced in IFC's texture classes). More recently, and what I will focus on, is that X3D v4 is now aligning its data model with glTF. I propose to update IFC's rendering and texturing capabilities to catch up and align to both X3D and glTF. This will make IFC compatible with modern artist workflows with existing ISO standards. IFC, X3D, and glTF will be compatible.

• https://www.web3d.org/x3d-vrml-most-widely-used-3d-formats
• https://www.web3d.org/news-story/x3d-version-40-iso-committee-draft-approved

Doing this alignment completely with X3D and glTF is a big change which involves new IFC classes and attributes. This big change can be delayed until after IFC4.3.

However, especially given that nobody has implemented this so far properly, we can make a number of docstring changes that will get us some of the benefits of modern X3D and glTF workflows in IFC4 and IFC4.3 today. This is the "lightweight" proposal I will focus on today. This can be further supplemented with a separate implementation guide that I can help write (similar to the georeferencing user-guide) to help implementers.

There are three reflectance models that X3D and glTF use: Material, PhysicalMaterial, and UnlitMaterial (Note: TwoSidedMaterial) is deprecated. (source)

• Material correlates to the IfcReflectanceMethodEnum of PHONG.
• PhysicalMaterial has no correlation, but it is the most widely used by artists. I propose to add a new enum value called PHYSICAL
• UnlitMaterial correlates to the IfcReflectanceMethodEnum of FLAT

Assuming we do not add any enums or attributes and are only limited to docstrings, here's what we can support.

X3D Material Attribute	IFC Attribute
ambientIntensity	No support (well, sort of, see below)
diffuseColor	DiffuseColour
emissiveColor	No support
normalScale	No support
occlusionStrength	No support
shininess	SpecularHighlight.IfcSpecularRoughness
specularColor	SpecularColour
transparency	Transparency

X3D PhysicalMaterial Attribute	IFC Attribute
baseColor	DiffuseColour
emissiveColor	No support
metallic	SpecularColour.IfcNormalisedRatioMeasure (closest possible thing)
normalScale	No support
occlusionStrength	No support
roughness	SpecularHighlight.IfcSpecularRoughness
transparency	Transparency

X3D UnlitMaterial Attribute	IFC Attribute
emissiveColor	DiffuseColour
normalScale	No support
transparency	Transparency

As you can see, there seems to be no equivalent X3D or glTF attribute for the IFC attributes TransmissionColour, DiffuseTransmissionColour, or ReflectionColour.

The lack of support for emissiveColor is not a deal breaker. IFC has existing lighting geometry for lights, and we can make the Tron building designs happy later. The lack of support for normal scale is also not a deal breaker. It simply means that artists cannot adjust the "bumpiness" of their normals. Artists can simply adjust the scale in their normal maps within the range of 0-1 for now. The lack of support for occlusion strenght has a similar workaround.

The existing docs also note how SurfaceColour could be treated as the ambient colour.

NOTE The inherited attribute SurfaceColour is treated as the ambient colour and specifies how much ambient light from light sources this surface shall reflect.

In practice, this does not make sense. The SurfaceColour is used in non-rendered real time viewport visualisations. This viewport colour and rendering attributes serve two different purposes, and IfcSurfaceStyleRendering and IfcSurfaceStyleShading are mutually exclusive due to the WHERE RULE, so this attribute cannot be reused in practice.

Also note the current entity description for IfcSurfaceStyleRendering refers to already removed IFC2X3 concepts like TextureType = bump. It needs to be revised.

Itemised list of docstring changes

Note: most of these docstrings are copy pasted from the X3D docs.

I propose to rewrite the entity description for IfcSurfaceStyleRendering as follows:

IfcSurfaceStyleRendering holds the properties for visualization related to a particular surface style. Three lighting models are supported:

• Phong lighting model
• Physically based lighting model
• Flat lighting model that ignores light sources

The X3D 17 Lighting component contains a detailed description of the lighting model equations.

The material parameters are specified as scalars or RGB colors. Every material parameter can be adjusted using a texture. This allows to vary this parameter across the surface. The information sampled from the texture is always multiplied by the simple scalar/color fields.

I propose to change the description of DiffuseColor to:

In a PHONG ReflectanceMethod, the DiffuseColour correlates to the diffuseColor attribute in the X3D Phong lighting model. The diffuse colour reflects all X3D light sources depending on the angle of the surface with respect to the light source. The more directly the surface faces the light, the more diffuse light reflects. In a PHYSICAL ReflectanceMethod, a physical based lighting model is assumed, and so the DiffuseColour correlates to the baseColor attribute used in the X3D physical lighting model. In a FLAT ReflectanceMethod, the DiffuseColour correlates to the emissiveColor attribute used in the X3D unlit lighting model.

I propose to mark the following attributes as deprecated:

• TransmissionColour
• DiffuseTransmissionColour
• ReflectionColour

I propose to change the description of SpecularColour to:

In a PHONG ReflectanceMethod, the SpecularColour correlates to the specularColor attribute in the X3D Phong lighting model. The specular colour determine the colour of the specular highlights ( e.g., the shiny spots on an apple). In a PHYSICAL ReflectanceMethod, a physical based lighting model is assumed, and so the SpecularColour is specified as a IfcNormalisedRatioMeasure, which correlates to the metallic attribute used in the X3D physical lighting model. In a FLAT ReflectanceMethod, the SpecularColour has no effect.

I propose to change the description of SpecularHighlight to:

In a PHONG ReflectanceMethod, the SpecularHighlight is specified as a IfcSpecularRoughness and correlates to the inverse of the shininess attribute in the X3D Phong lighting model. The SpecularHighlight determines the nature of the specular highlights ( e.g., the shiny spots on an apple). Lower shininess values produce soft glows, while higher values result in sharper, smaller highlights. In a PHYSICAL ReflectanceMethod, a physical based lighting model is assumed, and so the SpecularHighlight is specified as a IfcSpecularRoughness, which correlates to the roughness attribute used in the X3D physical lighting model. In a FLAT ReflectanceMethod, the SpecularHighlight has no effect.

I propose to change the description of ReflectanceMethod to:

Identifies the predefined types of reflectance method from which the method required may be set. PHONG correlates to the X3D Phong lighting model. PHYSICAL correlates to the X3D Physical lighting model. FLAT correlates to the X3D Unlit lighting model. The exact behaviour of other reflectance methods may be determined by view definitions or implementer agreements.

[Moult]

From a discussion, rather than misuse the "NOTDEFINED" enum value, it was proposed to instead add a new enum value called PHYSICAL. I have edited the original post.

[Moult]

Moving to proposal stage, with support from @aothms and @TLiebich

[coderextreme]

Note that glTF is getting PBR-Next. There was a press release last year. Here is the feature in Three.JS: https://threejs.org/examples/webgl_loader_gltf_transmission

This may help with your transmission and reflective colors.

Here's another good reference.

https://github.com/cx20/gltf-test/tree/master/tutorialModels/IridescentDishWithOlives

Good luck!

[coderextreme]

Here is press release:

https://www.twice.com/the-wire/new-gltf-extensions-raise-the-bar-on-3d-asset-visual-realism

[Moult]

Thanks @coderextreme ! This is great news! Ping @michaliskambi is X3D also aiming to get these new glTF toys? Would this constitute a new reflectance model / lighting model, or simply an extension of PhysicalMaterial?

My gut feel is that this may have to wait until after IFC 4.3 to be released if X3D doesn't already have these, since it will take some time to go through. Right now for IFC4.3 since we aren't adding new attributes / classes I think it is sufficient to cover the base cases, and there just isn't enough time (deadline in a month with a lot of other priorities).

[michaliskambi]

We do plan on incorporating them in X3D at some point, definitely :) Quoting from my mail to X3D working group some time ago:

6 glTF PBR-related extensions that I want to familiarize with, and consider "how I would do this in X3D", are listed in these 2 pages:

https://www.khronos.org/news/press/khronos-releases-wave-of-new-gltf-pbr-3d-material-capabilities

KHR_materials_clearcoat
KHR_materials_transmission
KHR_materials_sheen

https://www.khronos.org/news/press/new-gltf-extensions-raise-the-bar-on-3d-asset-visual-realism

KHR_materials_ior
KHR_materials_volume
KHR_materials_specular

The 2 Khronos press releases linked above contain a nice 1-paragraph summary of each extension.

They are all extensions to the existing glTF 2.0 metallic-roughness model (not e.g. to KHR_materials_pbrSpecularGlossiness, which presents a different PBR approach). Which is good news for X3D, as they'll be extensions to our PhysicalMaterial then.

I do not yet have a timeline for when it will happen though. At least if it will be on my head -- I need time to play with them first, to understand the details of API and implementation, to decide how to express them in X3D.

I started speaking on one of our talks "these things, like transmission, are not available in real-time... oh wait, actually they are available, just not so easy" -- I was not able to go into details as I don't know them yet :) But it's definitely on my TODO list, both for X3D and CGE, to learn them :)

[Moult]

OK, given that X3D currently does not support them, and IFC references X3D, I'd say it's good to know they exist but we very likely won't consider them until at least after IFC 4.3 due to time constraints :)

[TLiebich]

+1 from my side

[Moult]

Upgrading this to decided from the verbal discussion on Monday. Also agreed upon that after IFC4.3 we can revisit this and take an even closer look. I've tracked this in the big issues thread so we don't forget :)

[aothms]

Schema changes:

• IfcReflectanceMethodEnum.PHYSICAL
• ...

Doc changes:

• ...

What am I missing?

[Moult]

I've done all the doc changes, just need to add PHYSICAL and that's it! :)