Tweak SpatialMaterial's default metallic and roughness texture channels

[Calinou]

To follow the glTF 2.0 specification in all cases (including outside of imported glTF scenes), the blue channel is now used for metallic and the green channel is now used for roughness. This way, less clicks are required when setting up new materials using ORM-packed textures (occlusion, roughness, metallic). This should have no effect on materials using grayscale maps, as the R/G/B channels are identical.

This also removes the need to set channels specifically in the glTF scene importer code.

[fracteed]

Good idea. I always use an ORM texture, so this saves a few extra clicks!

[kaadmy]

To add to this, should this be a project-wide setting for newly created materials? (And maybe for GLTF import etc.)

Edit: Offtopic, but maybe a default SpatialMaterial much like the default environment would be helpful.

[Calinou]

To add to this, should this be a project-wide setting for newly created materials? (And maybe for GLTF import etc.)

Since the glTF 2.0 specification mandates this format, is there any significant usage of a different packing model? I'd rather not add more project settings than we need.

That said, the ability to define a custom default SpatialMaterial sounds good to me, but that's for later 🙂

[reduz]

I am planning to make an ORM mode for the material in 4.0..

[akien-mga]

I am planning to make an ORM mode for the material in 4.0..

So what should we do until then?

[akien-mga]

Let's merge for 3.2. If reduz wants to make a difference system for 4.0, that can be done later on.

[akien-mga]

Thanks!

[akien-mga]

On second thought, does this break compat with 3.1? I thought it only impacted glTF import, but re-reading I see that it's the other way around, it makes SpatialMaterial use the same channels as glTF import.

[Calinou]

@akien-mga I suppose it can be considered a breaking change in theory, but in practice, most people I know currently use grayscale textures for roughness/metallic/ambient occlusion. In these textures, the RGB channels are equal, so there's no visual difference.

Therefore, it shouldn't be cherrypicked to 3.1.x, but making it available in 3.2 sounds fine to me (as long as the change is documented in the changelog).

[reduz]

@akien-mga This is a significant breaking change by the way and many projects will break. It's also not done good enough because they are multiplied by roughness and metalness which are not 1.0 by default, so the intended effect will not be achieved anyway.

I suggest reverting this and doing it properly in Godot 4.0. In there, I plan to introduce a proper dedicated ORM material, that only does one texture tap (opposed to now 3 taps).