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

Fri Sep 26 12:31:23 PDT 2025

Ups, errata: I see I wrote:

"""I would not recommend to have breaking change in X3D 4.0."""

-> but I meant to write:

"""I would not recommend to have breaking change in X3D 4.1. That is,
we should limit breaking changes to major releases, like X.0."

Regards,
Michalis

pt., 26 wrz 2025 o 21:28 Michalis Kamburelis
<michalis.kambi at gmail.com> napisał(a):
>
> Cool. Thanks for the good words, I also think it's a good change.
> Indeed, the situation you described (someone saves grayscale data into
> an image with 3, RGB, channels) was also one of the reasons behind it
> -- in X3D 4.x, this makes no difference (as both RGB and grayscale
> formats will be multiplied), so it's less surprising for authors.
>
> As for default: I'd say to keep Material.diffuseColor at 0.8.
>
> We just need to educate people about this change. You can refer them
> to https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent
> , we also did some webinars where I talked about this change, around
> the time when we released/officially approved X3D 4.0, they are
> hopefully somewhere on Web3d youtube :) The short statement would be
>
> """
> In X3D 4.x, the Material.diffuseColor multiplies your texture,
> regardless whether the texture is RGB or grayscale. If you previously
> relied on the fact that in X3D 3.x, RGB texture ignored
> Material.diffuseColor (and you used VRML / X3D 3.x browser honoring
> this), then you should change Material.diffuseColor to 1 1 1 to
> achieve the same look in X3D 4.x. The advantage is that new look will
> really work consistently in all X3D browsers, and you gain extra
> flexibility (extra ability to multiply).
> """
>
> Reasons to not change Material.diffuseColor default:
>
> - Even at X3D 4.0 release (which was already some time ago), changing
> Material.diffuseColor default to 1.0 would also break some
> compatibility.
>
>     - Grayscale textures would then be lighter,
>
>     - and RGB textures would behave differently in browsers that
> already ignored that part of spec. Recall: Per my tests from
> https://castle-engine.io/x3d_multi_texturing.php#section_Material_color_mixed_with_texture_color
> , only 1 browser (out of 6 tested, or out of 7 -- if you include my
> own Castle Model Viewer) actually honored the X3D 3.x spec rules
> perfectly.
>
> - And now it's, admittedly, also a bit too late :) We're drafting now
> X3D 4.1, and X3D 4.0 is officially supported in many browsers. I would
> not recommend to have breaking change in X3D 4.0.
>
> Neither of the above arguments is "definite", of course everything can
> change if there's a good enough reason, but together -> I think they
> point that it's better to just keep "Material.diffuseColor at 0.8"
> (unchanged from X3D 3.x, though the interaction with RGB textures
> differs) and talk about this change.
>
> Regards,
> Michalis
>
>
> pt., 26 wrz 2025 o 19:17 <microaaron at pku.edu.cn> napisał(a):
> >
> > 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