Skip to content

X3D version 4: New features of materials, lights and textures

Michalis Kamburelis edited this page Jan 26, 2020 · 2 revisions

This page strives to be a useful summary of my proposed changes to X3D v4 related to Physical Based Rendering (in particular, draft X3D specification prose is here) and Making RGB and grayscale textures consistent.

New X3DOneSidedMaterialNode node with emissive and normalmap textures

We add a new abstract node X3DOneSidedMaterialNode, which will be a basis for both Material and PhysicalMaterial nodes.

It allows to specify:

  • Emission (emissiveColor, emissiveTexture and emissiveTextureChannel)
  • Normal maps for bump mapping (normalTexture, normalTextureChannel)

Reasons: New useful features :) These are common features in modern 3D graphics.

Implementors note: emissiveColor is moved here, from Material.

Material node extended to specify textures

Material node now includes fields to configure all it's parameters by textures. The texture field names are deliberately consistent with the scalar/vector field names.

So you get new Material fields like:

  • ambientTexture and ambientTextureChannel
  • diffuseTexture and diffuseTextureChannel
  • specularTexture and specularTextureChannel
  • shininessTexture and shininessTextureChannel

Reasons: Ability to configure every material "slot" by a texture is a popular feature now in 3D graphics, present also in Blender, Unity materials, as well as CommonSurfaceShader. It is also consistent with new PhysicalMaterial.

Backward compatibility: 100%. You can still specify textures within Appearance.texture, they will work as before (will be applied to diffuse). And Material node still performs Phong shading, 100% compatible with X3D 3.

New PhysicalMaterial node

This node is an alternative to Material node (that is, you can place it within Appearance.material slot). It indicates we should use physical-based calculation for lighting.

It has different parameters (and equations) than Material node.

Reasons: This is a common feature on modern 3D graphics (Blender, Unity, Unreal Engine, glTF -- some examples of software/formats that embrace physical lighting model). Our PhysicalMaterial is also deliberately designed to "match" glTF 2.0 parameters, to allow converting glTF 2.0 into X3D nodes a straightforward process.

New TwoSidedAnyMaterial node

This an improved alternative to the existing TwoSidedMaterial node. It allows to use PhysicalMaterial for both mesh sides.

Reason: Without this, physical-based lighting would be "crippled" compared to Phong lighting. TwoSidedMaterial allows to make two-sided Phong lighting, but there's no reasonably way to extend it to include PBR parameters. So we need to invent a new node.

Under discussion -- an alternative is to just deprecate/remove TwoSidedMaterial node.

New EnvironmentLight node

New light node, that "casts" light from a surrounding specified like a cubemap.

Reason: This is a modern way to define surrounding light. While the existing lights (point, directional, spot) will also continue work (on both Material and PhysicalMaterial), but environment light allows to achieve much more impressive lighting.

Treatment of RGB and grayscale textures consistent

Since X3D 4, the specification will always treat the "grayscale texture" the same as an "RGB texture with the red, green and blue components equal, on all pixels".

Reason: The X3D 3 specification wanted something more complicated -- to detect whether a texture is grayscale or RGB (by looking at image header, ideally, although in practice some viewers do this by analyzing image contents) and treat them differently: grayscale texture is multiplied by color, while RGB texture replaces the color. I argue in Make RGB and grayscale textures treatment consistent why I consider this a bad idea -- it is not expected by X3D authors, it is not consistent with behavior of everyone other graphic software, it's an unnecessary limit on X3D authors. I think this rule was introduced in the ancient times, hoping that "replacing color with RGB texture" will be more efficient than "component-wise multiplication with RGB texture", but it really doesn't matter on modern GPUs that have this operation extremely optimized.

Backward compatibility: While theoretically it breaks X3D 3 compatibility, in practice the cross-browser compatibility of this in X3D 3 doesn't exist. See Make RGB and grayscale textures treatment consistent and tests here. Every browser now does something different here, and only 1 browser out of 7 manages to be 100% conforming to the X3D 3 specification.

The new rule can be applied by browsers conditionally, like if (X3D header indicates version >= 4) then (multiply texture with color) else (do whatever you were doing previously).

You can’t perform that action at this time.