Specification changes, to include PBR and related features - michaliskambi/x3d-tests GitHub Wiki

This page is the 3rd part (out of 3) of the Include PBR (PhysicalMaterial and related concepts) in the official X3D specification series. It describes the actual proposed X3D specification changes.

The up-to-date result of this is summarized here: X3D version 4: New features of materials, lights and textures.

The changes described in this page are grouped in "waves of changes".

  • Each "wave" is something that should be applied completely on the specification, as only when the complete "wave" is applied the specification remains consistent, that is: new features and old features make sense 100% and everything connects with each other.

  • "Waves" may also serve as a guideline (as iterations) for implementations. It makes sense to implement 1st wave, test it, then implement 2nd wave, and so on. It's not the only possible approach (you can e.g. implement PhysicalMaterial earlier, and enhance Phong Material later), so it's just a guideline, not a rule :)

Credits go to everyone with whom Michalis was speaking about PBR. In particular, Andreas Plesch contributed to this a lot, many things below are Andreas' propositions or were born in the discussion between Michalis and Andreas on the x3d-public mailing list.

Examples are in https://github.com/michaliskambi/x3d-tests/tree/master/pbr .

I will try to keep this page concise and precise, to resemble the actual specification text. A more in-depth discussion of alternative ideas, and why the ideas below were chosen, is on a separate page How to add PBR to X3D?.

Table of Contents:

1st wave: enhancements to materials and texturing

This enhances "Shape" component ( http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/shape.html ) and "Texturing" with new features. The enhancements bring:

  • Normalmaps, as important feature for all material calculation in 20th century (for both PBR and Phong lighting models).
  • Phong Material enhancements, that allows to vary all Phong material parameters (diffuse, specular, emissive...) across a surface. (This enhancements makes CommonSurfaceShader no longer useful, we effectively take some of CommonSurfaceShader ideas and add them to the existing Material).
  • Keep backward-compatibility of course, so old models using existing nodes and materials will keep working as-is, using Phong lighting model. Authors can (but don't have to) gradually use new features, adding new textures to existing materials, and/or converting Phong Material to PhysicalMaterial (there is no automatic conversion possible, this has to be done by a human, as the results are inevitably different).

New abstract node X3DSingleTextureNode

An abstract type that intuitively means "any texture except MultiTexture".

Details inside X3Dv4 spec now, in Web3d GitHub repo.

New prose (in the texturing component): Choosing texture coordinates / transformations (how the xxxTextureChannel works)

Details inside X3Dv4 spec now, in Web3d GitHub repo.

Some additional text about them is on https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#additional-clarifications-what-happens-when-there-are-too-few-entries-for-multitexturecoordinatetransform .

Historic Note: Earlier Michalis and Andreas were considering a different approach, where we would add "channel" field to X3DTextureCoordinateNode and X3DTextureTransformNode . After a lot of thinking (see here for a long list of arguments: https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#textures-in-materials-require-access-to-possibly-multiple-texture-coordinates-on-a-mesh-do-we-use-multitexturecoordinate-for-it-or-something-else ) I decided to not do this, for now.

New abstract node X3DOneSidedMaterialNode

This is now moved to PR on https://github.com/Web3DConsortium/X3D/pull/8

Not necessary to add to spec:

Note: emissiveColor and emissiveTexture defined this way are

  1. backward-compatible with existing X3D 3, that has emissiveColor (default zero) in Material
  2. trivially compatible with glTF 2.0, that has emissiveFactor (default zero) and emissiveTexture.

Enhanced Material node

This is now moved to PR on https://github.com/Web3DConsortium/X3D/pull/8

Comments left from it:

  • Note: The diffuseTexture is actually diffuseAlphaTexture, CommonSurfaceShader even has a name multiDiffuseAlphaTexture for it. But calling it as such seems to be more confusing than helpful.

  • This is consistent with glTF that says it's baseColorTexture alpha is just used for the final alpha used for rendering. PhysicalMaterial.baseTexture will be consistent with Material.diffuseTexture in this regard.

Clarify what happens with Appearance.texture and MultiTextureXxx nodes

This is now moved to PR on https://github.com/Web3DConsortium/X3D/pull/8

2nd wave: Add physical-based rendering (PBR) material

This adds a new feature (to "Shape" component):

  • PBR (physical-based rendering) in a way that is constent to the existing Phong lighting model, and that allows to convert glTF materials to X3D in straightforward fashion.

New PhysicalMaterial node

This is now moved to PR on https://github.com/Web3DConsortium/X3D/pull/8

Note: this node, deliberately, uses the same terms with the same interpretation as glTF 2.0 material. Converting glTF 2.0 material with model "pbrMetallicRoughness" to the X3D node PhysicalMaterial is a straightforward copy of the relevant fields.

Implementation notes: See X3DOM implementation, the shader (GLSL) code in

3rd wave: allow 2-sided materials to benefit from previous waves enhancements

New two-sided material

This is now moved to PR on https://github.com/Web3DConsortium/X3D/pull/8

In the end we decided Appearance.backMaterial to fullfill separateBackColor case.

4th wave: environment lights

This adds a new light source type (extending the "Lighting" component http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/lighting.html#DirectionalLight ), that uses a cubemap to define environment light (using X3DEnvironmentTextureNode defined by the "Cube map environmental texturing" component).

EnvironmentLight : X3DChildNode {

  # New fields
  SFNode [in,out] image # Allowed values: X3DEnvironmentTextureNode

  # TODO: the rest
}

TODO: Add the rest of necessary fields from https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Vendor/EXT_lights_image_based

TODO: Maybe it can derive from X3DLightNode, and reuse it's color, on and so on? We definitely want at least an on field here, for consistency with existing X3D light sources.

The environment light (just like all other light sources) affects all shapes, whether using Phong lighting model (Material node) or PBR (PhysicalMaterial node).