Pixel format for roughness and metal-ness textures? Topic is solved

[jwwalker]

I was informed in another topic that the preferred pixel format for a normal map is PFG_RG8_SNORM. How about PBSM_ROUGHNESS and PBSM_METALLIC textures? I don't see any sample programs that call setTexture for those texture types. Some sample programs call setSamplerblock using PBSM_ROUGHNESS, but I don't know why you'd want to set a sampler block without a texture. I guessed that PFG_R8_UNORM might be an appropriate pixel format, so I tried that. I don't get any error messages, but the rendered output doesn't look right.

[jwwalker]

Experimentally, I seem to get better results for roughness and metal-ness using PFG_RGBA8_UNORM, and just using the same roughness or metal-ness value in the R, G, and B bytes. But I may also be misunderstanding something about how roughness is supposed to work. In the glTF sample viewer, when the CompareRoughness model is selected, I see something like this with the default display setting:

An oval area around the logo looks quite shiny, but the rest of the ball looks moderately dull. However, if I go to the display settings and turn off Image Based Lighting, then the area around the logo has no specular highlights at all:

I would have expected the area in which the roughness map is 0 to look some kind of shiny in both cases.

[dark_sylinc]

Roughness & Metalness only use the R channel, so PFG_R8_UNORM is the ideal one. With RGBA_UNORM you're just wasting memory as the other channels are never used (unless you're customizing the shaders to take advantage of those unused channels).

By the way, CommonTextureTypes addresses these issues for you, as it selects the right parameter / filters for the textures you are trying to load based on your intention.

I was informed in another topic that the preferred pixel format for a normal map is PFG_RG8_SNORM. How about PBSM_ROUGHNESS and PBSM_METALLIC textures? I don't see any sample programs that call setTexture for those texture types. Some sample programs call setSamplerblock using PBSM_ROUGHNESS, but I don't know why you'd want to set a sampler block without a texture. I guessed that PFG_R8_UNORM might be an appropriate pixel format, so I tried that. I don't get any error messages, but the rendered output doesn't look right.

Roughness / Metalness has two issues when moving between different apps:

1. Some apps expect rough/metalness to be sRGB. Most don't. We don't. Loading the texture as RGBA_UNORM_SRGB would fix it.
2. Regarding roughness, most apps go with "perceptual" roughness while a few don't. We do (it's on by default see HlmsPbs::setPerceptualRoughness, it's marked for deprecation as in the future the setting will be forced on). Perceptual roughness just means that actual_roughness = perceptual_r * perceptual_r;

A few more things that are relevant:

1. If using Metallic workflow, make sure you're in the Workflows::MetallicWorkflow.
   2, If you're not in the Metallic workflow, "shininess" depends on both roughness and fresnel. Play with the fresnel setting.

I would have expected the area in which the roughness map is 0 to look some kind of shiny in both cases.

You're not misunderstanding. You're just missing a simple fact: the only source of lighting is a punctual light.

This is easier to understand with an example with no textures:

You have a sphere with roughness near 0 across the entire ball. And a single sun light. Notice that bright spot (circled in red)?
That's it, that all the power of the sun accumulated in that single bright spot due to the low roughness.

But if you set roughness to 1 in that area, and roughness to 0 in the center; you won't see the spot.

If you had a 1000 lights all over the sphere, then you would see something. And an environment map is light having millions of light sources all around.

Without GI (global illumination), a sun light is very artificial because it's like you're in space being illuminated by the sun and no bounce from anywhere else.

[jwwalker]

Roughness & Metalness only use the R channel, so PFG_R8_UNORM is the ideal one. With RGBA_UNORM you're just wasting memory as the other channels are never used (unless you're customizing the shaders to take advantage of those unused channels).

It seems that I was testing a rather unusual situation. In the model I tried, the material specified a metallic texture, but also an overall metallic factor of zero, which I would expect to make the metallic texture have no effect. Due to the metallic factor of 0, I was not setting MetallicWorkflow. In that situation, using PFG_R8_UNORM for the metallic texture gave me red specular highlights. I've changed my code so that if the metallic factor is 0, I won't set the metallic texture in the datablock.

By the way, CommonTextureTypes addresses these issues for you, as it selects the right parameter / filters for the textures you are trying to load based on your intention.

I see, CommonTextureTypes is a parameter of some versions of createOrRetrieveTexture, but I was using createTexture.