X3D version 4: New features of materials, lights and textures
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.
X3DOneSidedMaterialNode node with emissive and normalmap textures
We add a new abstract node
X3DOneSidedMaterialNode, which will be a basis for both
It allows to specify:
- Emission (
- Normal maps for bump mapping (
Reasons: New useful features :) These are common features in modern 3D graphics.
emissiveColor is moved here, from
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:
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
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.
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
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.
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
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
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).