[Merged by Bors] - bevy_pbr: Support flipping tangent space normal map y for DirectX normal maps

[superdump]

Objective

• Normal maps authored for DirectX use a left-handed convention and have their tangent space normal in the texture inverted from what we need. Support this.
• Details here: https://doc.babylonjs.com/divingDeeper/materials/advanced/normalMaps

Solution

• Add a StandardMaterial flip_normal_map_y boolean field
• Add a STANDARDMATERIAL_FLIP_NORMAL_MAP_Y flag to StandardMaterialFlags and in the PBR shader
• Flip the y-component of the tangent space normal just after sampling it from the normal map texture

Screenshots

Before

After

---

Changelog

• Added: Support for flipping the normal map texture y component for normal maps authored for use with DirectX

[cart]

This is a reasonable fix, but ultimately this feels like a job for an asset preprocessor. A conversation for another day (once we have asset preprocessing).

[superdump]

This is a reasonable fix, but ultimately this feels like a job for an asset preprocessor. A conversation for another day (once we have asset preprocessing).

I agree, though maybe this kind of image processing at runtime is undesirable. Imagine wanting to load Bistro as-is from an fbx, and you want to use compressed textures, and compressing each texture takes at least 10s of seconds, and decompressing and compressing is lossy (though maybe there's a way to work around that and do this manipulation in compressed space)... that's pretty infeasible for an online runtime task. Then you would rather just have a .meta file that sets a toggle to flip the y component in the shader. I suppose it could be shader deffed out but then you incur the shader rebind cost when using a mix.

[cart]

Yeah there would likely be cases where "ahead of time" preprocessing wont be viable. But I do think thats probably the direction we should encourage people to go down generally (once thats an option).

[superdump]

Yeah there would likely be cases where "ahead of time" preprocessing wont be viable. But I do think thats probably the direction we should encourage people to go down generally (once thats an option).

Yup. I agree. I was looking at image processing stuff in blender/imagemagick first in order to conform the textures first but then decided it was worth doing like this for other reasons too. I agree that we should order preprocessing where possible to avoid runtime costs.

[cart]

bors r+

[bors]

Timed out.

[mockersf]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• build-android
• build (nightly, ubuntu-latest)
• build (stable, macos-latest)
• build (stable, ubuntu-latest)
• build (stable, windows-latest)
• build-wasm (nightly, ubuntu-latest)
• build-wasm (stable, ubuntu-latest)
• check-benches
• check-doc
• check-markdown-links
• check-missing-examples-in-docs
• check-unused-dependencies
• ci
• markdownlint
• miri
• run-examples