Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CompareAnisotropy seems to have conflicting normal and anistropy direction #153

Open
krohmerNV opened this issue Nov 11, 2024 · 5 comments

Comments

@krohmerNV
Copy link

This is about one Material in the CompareAnisotropy model, the grooved-anisotropy material.

The material looks like this:

{
      "extensions": {
        "KHR_materials_anisotropy": {
          "anisotropyStrength": 1,
          "anisotropyRotation": 1.6
        }
      },
      "name": "grooved-anisotropy",
      "normalTexture": {
        "extensions": {
          "KHR_texture_transform": {
            "rotation": 1.5707963705062866,
            "scale": [
              6,
              2
            ]
          }
        },
        "index": 2,
        "scale": 0.5
      },
      "pbrMetallicRoughness": {
        "baseColorFactor": [
          1,
          1,
          1,
          1
        ],
        "baseColorTexture": {
          "index": 1
        },
        "metallicRoughnessTexture": {
          "index": 3
        }
      }
    },

Note, it has a rotation of about 90 degrees on the normal texture.
It has also a rotation on the anisotropy direction.
To easier get the point of question, remove both, which should not do much other than rotating the grooves as well as the anisotropy highlight.

Next look at at the normal texture (img2.jpg). The grooves are aligned with the U-Axis or X-Axis
of the image. This axis is usually aligned with the tangent and based on the KHR_materials_anisotropy spec, also with the anisotropy direction (before applying any rotation).

This would also mean that the highlight should also be stretched along that direction, i.e. along the grooves, but it isn't in the reference image:

Note: The direction vector of the anisotropy is the direction in which highlights will be stretched. The direction of the micro-grooves in the material causing the anisotropy will run perpendicular.

My claim is that the normal texture and the anisotropy highlight do not match in the scene setup.
If the highlight stretching is to be aligned to the U-Axis of the texture frame, I would expect the groves in the normal map to be aligned with the V axis so normals and anisotropy highlights match visually.
When applying a 90 degree rotation to both, normal space and anisotropy, nothing changes. Rotating only one would fix the problem but it points to a bug in the reference renderer.

@echadwick-dgg3d
Copy link

Thanks for pointing this out, looks like my mistake! I'll see about correcting this.

@krohmerNV
Copy link
Author

Thank you! Apart from this inconsistency in the content I guess the more concerning part is the reference renderer which presumably ignored one of the transformations.

@emackey
Copy link
Member

emackey commented Nov 18, 2024

@krohmerNV It turns out that rotating normal maps is difficult. Our KHR_texture_transform spec talks about what happens to the UV coordinates, but does not mention a need to rotate the whole TBN matrix (tangent-bitangent-normal) and whether glTF expects renderers to be doing that or expects the underlying image to already take that rotation into account. That question remains unresolved at the moment.

Long story short, anytime one rotates the UV coordinates of a normal map, the whole tangent basis needs to rotate as well, otherwise the reflections in the map become decidedly unphysical. Specifically, the red and green channel values must rotate, so for example with a 90-degree rotation the red values swap places with inverted green values, such that the per-pixel X and Y vectors rotate along with the map. Otherwise the left side of a given bump in the map might reflect the top of the environment instead.

Anyway, take a peek at AnisotropyRotationTest and see if that works closer to expectation. The grooved sample is in the upper-right.

@krohmerNV
Copy link
Author

Okay, I would think that since rotations on normal texture are not explicitly excluded, they should be supported and rotating the entire tangent frame is the most natural and only valid consequence. I'm not sure it needs to be explicitly stated but If so, I would rather consider this an improvement of the spec or docs and NOT a change.

@krohmerNV
Copy link
Author

The RotationTest at least looks okay to me. (I do rotate the tangent frame).
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants