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

microaaron at pku.edu.cn microaaron at pku.edu.cn
Fri Sep 26 10:16:12 PDT 2025


Thanks for your reply.

Many people don't save grayscale images as a single-channel format. They're actually still RGB three-channel. X3D 4.x no longer distinguishes between RGB and grayscale textures, which is great.
But the question now is whether it is necessary to adjust the default diffuseColor to 1.0 1.0 1.0.(Keep it consistent with UnlitMaterial.emissiveColor and PhysicalMaterial.baseColor.)
If it remains at 0.8 0.8 0.8, then users should be clearly informed that they need to manually change it to 1.0 1.0 1.0 to maintain the texture's brightness. (This is different from X3D 3.x.)

Thanks


> -----Original Messages-----
> From: "Michalis Kamburelis" <michalis.kambi at gmail.com>
> Send time:Friday, 26/09/2025 19:38:56
> To: "Holger Grahn" <hg at snafu.de>
> Cc: "Extensible 3D (X3D) Graphics public discussion" <x3d-public at web3d.org>, 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?
> 
> > No no, if you look at the origingal VRML97 spec eg. at
> > https://www.bitmanagement.com/developer/spec/vrml97specification.pdf
> > Material diffuseColor is ignored (i.e. white) for texture types RGB RGBA
> > See table 4.6. ODrgb = ITrgb, so diffuseColor in this case is ignored !
> 
> Yes indeed -- I mean my intention was to write exactly this :) Sorry
> if my previous message was not clear. It is exactly as you write, and
> my previous message (esp. AD 2) there is aligned with what you say
> (except I talked about X3D 3.x, and didn't remember to mention that
> VRML 97 == X3D 3.x equations in this matter).
> 
> With RGB textures, in X3D 3.x (and VRML 97), the diffuseColor was
> ignored. But with grayscale textures, it was used for multiplication.
> At least, that was a theory -- my tests on
> https://castle-engine.io/x3d_multi_texturing.php#section_Material_color_mixed_with_texture_color
> show how it was inconsistently applied in practice.
> 
> In X3D 4.x, diffuseColor multiplies the texture, always (regardless if
> it is RGB or grayscale). I think that's better and more universally
> supported now.
> 
> As for AdvanceMaterial, we thought about this, just like we considered
> CommonSurfaceShader. But the issue would be then that it introduces
> complexity (of the spec, implementations) so it would introduce
> confusion even more. If browsers already implement RGB/grayscale
> inconsistently, and we (at least I) think that X3D 3.x approach
> (behave differently for RGB vs grayscale texture) is not very useful,
> then we'd have a complicated situation having in spec something like
> "basic Material" and "AdvancedMaterial" and explaining to people that
> AdvancedMaterial has somewhat different equations and actually
> everyone is recommended to upgrade to AdvancedMaterial.
> 
> In the end, it is easier to just make "Material in X3D 4.x" extended
> and as good as we can. Easier for spec and for implementors and for
> model authors, hopefully :)
> 
> Regards,
> Michalis
> 
> pt., 26 wrz 2025 o 13:01 Holger Grahn <hg at snafu.de> napisał(a):
> >
> >
> > Hi Michalis,
> >
> > > 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.
> >
> > No no, if you look at the origingal VRML97 spec eg. at
> > https://www.bitmanagement.com/developer/spec/vrml97specification.pdf
> > Material diffuseColor is ignored (i.e. white) for texture types RGB RGBA
> > See table 4.6. ODrgb = ITrgb, so diffuseColor in this case is ignored !
> > diffuseColor is still useful in this case to modualate with
> > GRAY/Intensity textures.
> >
> > In general I am glad about the new features of Material and
> > PhysicalMaterial in X3D 4
> > My concern would be to have the new Material texture fields as a derived
> > node (AdvanceMaterial) from the classical Material, for many scenes with
> > simple Materials X3D 4.0 Material implementation needs much more memory
> > and code, even for simple shapes.
> >
> > Many Greetings
> > Holger
> >
> >
> >
> >
> >
> > --
> > Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
> > www.avast.com


More information about the x3d-public mailing list