[x3d-public] Should Material.diffuseColor be updated to 1.0 1.0 1.0? & Should normalTexture be removed from UnlitMaterial?

Fri Sep 26 03:25:44 PDT 2025

Hello,

As for diffuseColor making texture darker: this is indeed the case (by
default, texture gets multiplied by 0.8), but this is equal in X3D 3.x
and 4.x. *For grayscale textures*. For RGB textures, we did one other
change, that may cause darkening -- see below.

1. Material.diffuseColor default and which textures it affects:

- In X3D 3.x, the "Material.diffuseTexture" did not exist. Providing
the texture in "Apperance.texture" served the same purpose. And
"Material.difuseColor" is by default 0.8, so it did multiply texture
in "Apperance.texture" by 0.8 (by default).

- In X3D 4, we added "Material.diffuseTexture". "Apperance.texture"
can also be still used to provide effectively diffuse texture,
following rules in "12.2.5 Coexistence of textures specified in
material nodes with the "Appearance.texture" field". Regardless of
whether you specify texture in "Material.diffuseTexture" or
"Apperance.texture" -- it will get (by default) multiplied by 0.8,
since Material.difuseColor is 0.8 by default.

So, all valid X3D 3.x models -> will render the same in X3D 4.x, no
more/less darkening. That was our goal :)

2. ... But my above statements are really 100% true only for
*grayscale* textures. For them, nothing changed. For RGB textures
there is one change in X3D 3->4 that indeed may cause different look.
Whether it affects you, depends on what X3D browser you use:

- We made RGB and grayscale treatment consistent in X3D 4.x, see
https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent

- Namely, in the X3D 3.x, RGB diffuse texture was supposed to replace
colors (although not many browsers actually did implement it, see page
linked above). In X3D 4.x RGB diffuse texture will multiply colors,
component-wise.

- So this is a change is spec... but for good reasons, see
https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent
for explanation why I think this was a very good change. In short,

    - Many browsers never implemented that part of X3D 3.x correctly
anyway (only 1 in 6, from my tests, actually was correct).

    - And it was problematic for authors (1. surprising: people don't
expect RGB vs grayscale to differ, no other format does it, 2. and
less functional -- multiplication is useful, for both RGB and
grayscale textures).

    - Things are simpler and more consistent in X3D 4.x, and up to my
knowledge -- all browsers that support (at least part of) X3D 4.x now
handle it in consistent way.

- But, indeed, this means that in some cases, with some browsers,
things may get darker. If an X3D browser honored that bit of X3D 3.x
spec, and thus ignored Material.diffuseColor when an RGB texture in
Appearance.texture was provided -> in X3D 4.x it gets darker, as
Material.diffuseColor (default 0.8) is now multiplied by the texture.

    I realize this is some compatibility break, and I hope this
message and https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent
help explaining why "we needed to do this, and it's all better now" :)

Regards,
Michalis

śr., 24 wrz 2025 o 19:50 <microaaron at pku.edu.cn> napisał(a):
>
> That doesn't seem right either. In the Phong lighting model there is this description: "diffuseParameter = mixTexture(applyColorPerVertex(diffuseParameter), diffuseTextureParameter)" . This seems to mean that the default Material.diffuseColor 0.8 0.8 0.8 will still reduce the brightness of the diffuseTexture.
>
>
>
>
> -----Original Messages-----
> From: "microaaron via x3d-public" <x3d-public at web3d.org>
> Send time: Thursday, 25/09/2025 01:32:22
> To: "Extensible 3D (X3D) Graphics public discussion" <x3d-public at web3d.org>
> Cc: microaaron at pku.edu.cn
> Subject: Re: [x3d-public] Should Material.diffuseColor be updated to 1.0 1.0 1.0? & Should normalTexture be removed from UnlitMaterial?
>
> Sorry, I misunderstood. In the Phong lighting model, diffuseTexture is not multiplied by diffuseParameter. diffuseParameter affects ambientParameter.
>
>
> -----Original Messages-----
> From: "microaaron via x3d-public" <x3d-public at web3d.org>
> Send time: Thursday, 25/09/2025 01:00:58
> To: x3d-public at web3d.org
> Cc: microaaron at pku.edu.cn
> Subject: Re: [x3d-public] Should Material.diffuseColor be updated to 1.0 1.0 1.0? & Should normalTexture be removed from UnlitMaterial?
>
> Thanks for your reply.
>
> Material.diffuseColor is specific to the Phone lighting model. The default value of 0.8 0.8 0.8 may darken diffuseTexture.
>
> For Unlit lighting model, the default value of UnlitMaterial.emissiveColor is 1.0 1.0 1.0, and multiplying it by emissiveTexture does not darken emissiveTexture.
>
> Similarly, for Physical lighting model, the default value of PhysicalMaterial.baseColor is 1.0 1.0 1.0, and does not darken baseTexture.
>
> In the older X3D V3.3, diffuseTexture is not multiplied by diffuseColor. Once diffuseTexture is enabled, diffuseColor or vertexColor is useless. This is effectively equivalent to multiplying diffuseTexture by 1.0 1.0 1.0. DiffuseTexture does not darken.
>
> (I haven't found a test case yet.)
>
>
>
> > -----Original Messages-----
>
>
> > From: "Michalis Kamburelis" <michalis.kambi at gmail.com>
>
> > Send time:Wednesday, 24/09/2025 16:27:02
>
> > To: "Extensible 3D (X3D) Graphics public discussion" <x3d-public at web3d.org>
>
> > Cc: microaaron at pku.edu.cn
>
> > Subject: Re: [x3d-public] Should Material.diffuseColor be updated to 1.0 1.0 1.0? & Should normalTexture be removed from UnlitMaterial?
>
> >
>
> > Hello,
>
> >
>
> > Let me answer these two points (as I was designing them in X3D 4.x:) ):
>
> >
>
> > > 1.The Unlit lighting model formula has changed in v4.0/4.1: fragmentColor = applyFog(mixTexture(applyColorPerVertex(emissiveParameter), emissiveTextureParameter)). This differs from the definition in v3.3. However, the default value of Material.diffuseColor remains 0.8 0.8 0.8, which may results in a darkened diffuseTexture.
>
> >
>
> > The unlit lighting formula should be equivalent to how things worked before.
>
> >
>
> > In X3D 3.x there was no UnlitMaterial, but we had capability to make
>
> > unlit stuff e.g. when apperance=NULL or apperance.material=NULL or
>
> > when Material has all things except emissiveColor set to zero. All
>
> > these things should still work in equivalent way to X3D 4.x . The new
>
> > equations account for new things introduced (like emissiveTexture that
>
> > can multiply component-wise with emissiveColor).
>
> >
>
> > That's also why we left Material.diffuseColor = (0.8,0.8,0.8). So
>
> > things here behave like before. Things should not be darker / lighter
>
> > compared to X3D 3.x.
>
> >
>
> > It's of course possible I miss something or made a bug in some
>
> > thinking :) If you have a testcase where things are different
>
> > (darkened) but they should not, let me know.
>
> >
>
> > >
>
> > > 2.normalTexture should be useless for UnlitMaterial. Should it be removed from UnlitMaterial?
>
> >
>
> > It's a bit surprising, but UnlitMaterial also has use for normalTexture.
>
> >
>
> > See https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#does-it-make-sense-that-unlitmaterial-also-has-normaltexture
>
> > , section "Does it make sense that UnlitMaterial also has
>
> > normalTexture?" . In short: TextureCoordinateGenerator with some modes
>
> > (CAMERASPACENORMAL, CAMERASPACEREFLECTIONVECTOR) can use normals, from
>
> > geometry and them modified by normalTexture, and this makes sense
>
> > regardless of the material type and being lit.
>
> >
>
> > IOW, normals (and thus, also normalTexture) are *not* only for
>
> > lighting interaction (even though that's their only purpose in most
>
> > cases).
>
> >
>
> > Regards,
>
> > Michalis