Blue channel of anisotropyTexture causing odd behavior

[echadwick-artist]

Description

When the blue channel of an anisotropyTexture is set to zero, three.js seems to exhibit odd rendering behavior.

Maybe related to #25701 ?

anisotropyTexture looks like this. Both spheres are assigned a vertical direction (.5,1), left sphere has full aniso (blue 1.0), right sphere has zero (blue 0))

Other renderers:

This issue can also be seen in the glTF Sample Asset AnisotropyBarnLamp. Notice the shading differences on the flat knob at the top, knurled ring grip at middle, and 3 shade screws at the bottom. Viewers both use the IBL Wide Street 01 from Poly Haven.

anisotropyBarnLamp's anisotropyStrength (blue channel):

Reproduction steps

1. Go to https://threejs.org/editor/
2. Drag-n-drop attached glTF.
3. Set the Environment to MODELVIEWER.

Code

glTF material:

    {
      "name": "Copper",
      "pbrMetallicRoughness": {
        "baseColorFactor": [
          0.8,
          0.25,
          0.1,
          1.0
        ],
        "metallicFactor": 1,
        "roughnessFactor": 0.2
      },
      "normalTexture": {
        "index": 0
      },
      "extensions": {
        "KHR_materials_anisotropy": {
          "anisotropyStrength": 1.0,
          "anisotropyTexture": {
            "index": 1
          }
        }
      }
    }

Live example

Sample model using KHR_materials_anisotropy. Both spheres are in a single mesh, using same material, and the normalTexture is flat 128,128,255.
anisotropyTexture-v-Metalness.zip

Screenshots

No response

Version

r156

Device

Desktop

Browser

Chrome, Firefox

OS

Windows

[mrdoob]

/ping @elalish

[GitHubDragonFly]

I would have a simple question related to the ShaderLib.js file and its Anisotropy declarations:

	anisotropyVector: { value: /*@__PURE__*/ new Vector2() },
	anisotropyMap: { value: null },
	anisotropyMapTransform: { value: /*@__PURE__*/ new Matrix3() },

Are these actually correct, specifically the anisotropyVector?

Should there be anisotropy as used in three.js (or as the specs call it anisotropyStrength) and possibly anisotropyRotation?

Not really an expert in these but am just using a common sense logic and comparing these to let's say the clearcoat declaration of clearcoat: { value: 0 }.

[Mugen87]

anisotropyVector is computed based on anisotropy and anisotropyRotation. Only anisotropyVector exists as a uniform in the shader.

[echadwick-artist]

Shouldn’t it be using Matrix2 instead? This is a 2d vector stored only in red and green. The blue channel needs to be omitted from the vector.

[elalish]

No, that transform is applied to the UVs, not the vector - it's Matrix3 because it's an affine transform for 2D; same reason we use Matrix4 on 3D vectors.

[elalish]

The lamp difference might be related to #26967, which I need to look into. Regarding your spheres, can you double check your model? I don't see your blue/green texture in there, and it also has a uniform normal map texture? Also, both spheres are in a single mesh, which makes it a bit hard to see what's happening. Do you get different results when you set the strength factor to zero?

[WestLangley]

@elalish Tracking this down, one problem is this line:

three.js/src/renderers/shaders/ShaderChunk/lights_physical_fragment.glsl.js

Line 127 in bf7d99e

vec2 anisotropyV = anisotropyMat * normalize( 2.0 * anisotropyPolar.rg - vec2( 1.0 ) ) * anisotropyPolar.b;

The blue channel of the texture cannot be zero in the three.js implementation, although zero is a valid value according to the spec.

[elalish]

Thanks, I just noticed that too. However, I think there's a bigger problem. I removed all the textures besides anisotropy from the lamp, and it appears that when anisotropy strength => 0, then decreasing roughness darkens the result (loses specular energy?):

I need to look at those D and V terms I got from Filament; I probably messed something up, unless there's an energy conservation term I didn't realize was having an effect somewhere.