Occlusion/Roughness/Metalness texture packing rethink #258
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey all! First off, thanks for writing this super handy converter. Great stuff!
This PR is a little rethink about how to pack the ORM textures in the Stingray material pipeline. Right now, the code assumes that each texture will be a grayscale single channel input, and attempts to build a packed RGB ORM texture out of each texture's red channel. This unfortunately precludes using an ORM already built elsewhere, if you assign the same ORM texture to all 3 slots, you get the AO red channel from all 3 sources copied into the R, G, and B of the remixed texture!
My suggested pivot in this PR:
Outside of that, I have two questions/comments:
Why does the texture packer premultiply the uniform roughness and metalness values into the texture? Given that the uniforms are passed forward too, this may surprise some downstream users. This should probably at least be documented.
It's relatively rare in my experience, but it's not super unlikely that some artists may want to use separate maps for ORM. Specifically, it's possible you may need a higher resolution occlusion map, and can happily accept much lower resolution metallness & roughness maps. Given that both FBX and gltf can handle this definition, it may be nice to support it in the future.
Thanks!
Chris.