[Remote rendering problem] material.normalTextureInfo.scale not respected in GLTF material definition

[WikkidEdd]

It appears that converted models aren't respecting the GLTF material property for material.normalTextureInfo.scale. I've attached a model as an example of the problem.

Normal_Map_StrengthTest.zip

This screenshot shows what is should look like, but in ARR both quad render like the one on the right.

Is this something that you can add support for? The GLTF spec for it can be found here.

[jakrams]

Hey @WikkidEdd, if I understand this correctly, this is used to basically reduce the roughness of a surface, right? I think this is a runtime feature, ie. has to be done per pixel while rendering, rather than being part of the conversion process. I'll have to ask our rendering team, whether they want to support such a feature, it's not entirely trivial to add it.

How important is this to you? What are the desired use cases and are there other ways you could achieve what you want?

[WikkidEdd]

Not quite, it adjusts the strength of the normal map. In the example case it's reducing the effect of a brushed metal normal map, which in turn looks to reduce the roughness, but more generally this is used to embellish or reduce detail provided by a normal map.

Our app allows users to upload and view their own models in ARR easily, the desire is that the visuals from their source content package are reproduced faithfully in remote rendering. Given that it takes time and costs money to convert models, we want the number of iterations to get the visual look the user wants to be as low as possible. Extra iterations because of missing features cost time and cause frustration.

There are workarounds to this specific issue which is to bake the adjusted normal map into a new texture, but that adds further iteration time and our users need to a) know what the fix is and b) have the skills to be able to fix it.

More generally though it would be useful to have some documentation on which features of the GLTF spec are/are not supported and have the conversion process give warnings if features are being used which aren't supported. This would save our users (and us) a lot of time diagnosing the problem.

In terms of importance, since we can provide a workaround it's perhaps not the highest priority anymore, but we would suggest providing documentation and warnings on the GLTF spec shortfalls become a reasonably high priority because that would reduce the frustration factor quite significantly.

One final aside. We appreciate adding this feature may not be desirable from a performance point of view, but we are seeing more and more users wanting to display high-quality visual representations of their products (Watches, clothes, trainers, etc). For these use cases, the poly count isn't as high as complex CAD models, but the need for rendering quality is much more important. Having a flag for conversions that lets a user specify "Quality" over "Performance" could be one way to tackle this trade-off. Enabling "Quality" would enable higher quality shaders which enable extra features such as normalmap scale, clear coat, etc, at the user decision of reducing performance.

[jakrams]

We'll definitely update our documentation shortly. We are also discussing adding this as a per-material parameter in general. So this is on our backlog now. We'll update this ticket, once we can say more.

[FlorianBorn71]

Hi, good news, this feature has been added to the new release 1.1.28: https://github.com/Azure/azure-remote-rendering/releases/tag/1.1.28 The PBR material API has a new NormalmapScale parameter and furthermore this scalar is properly converted from the gltf (tested with the model in this ticket). The gltf needs to be re-exported.