Suggest separate parameters for diffuse and metal colours instead of "base_color" about openpbr HOT 4 OPEN

It must be true that the existing approach with a single base_color is less expressive than having separate colors, since obviously both the metal and diffuse base albedo must be scalar multiplies of this single color. If this impacts the ability to use the model for certain assets (so studios will reject the model specifically due to this problem), that seems really serious to me.

So in principle I'm in favor of changing this. Just I wish we had thought about this earlier as it's quite late to make such a change. I'm wondering what the minimal change we can make to the parameter set is to achieve it.

Possibly keeping base_color to mean non-metal base color, and adding a new parameter base_metal_color? If base_metalness is zero, in the UI this could be greyed out. At least then we are only adding 1 new parameter, with obvious meaning, that is consistent with the existing prefixes.

It seems not ideal to force users to dial in two colors if they want to work with an intermediate metalness. So another suggestion is to have base_metal_color default to black, then make the assumption that in this case (non-textured black) the metal F0 is taken from base_color. It is only if base_metal_color is textured, or constant and made non-zero in some channel, that we use it for metal F0. This would mean the existing OpenPBR behavior would be retained, and the custom metal color is "opt-in".

This would be a bit of a special case in OpenPBR though, since we don't currently have the notion of custom behavior depending on whether or not a parameter is textured. (Also possibly confusing when base_metal_color is black in the UI, but the metal is actually colored according to base_color. And you can't do a blend of diffuse and metal with constant black metal F0, but probably no-one ever wants that).

from openpbr.

I noticed this slide in the Unreal Substrate presentation. Is this "metalness limitation" the same issue?

from openpbr.

To test the effect of constraining the metal and diffuse base colors to be equal, I did renders with OpenPBR of "rust on top of shiny metal" in two ways:

• by making the base_color a blend of blue/rust weighted by base_metalness
• by altering the shader so that the metal F0 color (blue) is independent from the diffuse color (rust)

In both cases the specular_weight is driven by the base_metalness, so that the rust has a diffuse look.

The resulting renders are below. It seems the blending does have a fairly obvious effect in this case, i.e. it creates a halo around the rust, instead of a crisp transition:

Base blend	Separate diffuse/metal-F0

The base_metalness map used is close to a binary map, so the intermediate metalnesses (where the halo occurs) are presumably only due to texture filtering (in this case, though a map with larger areas of intermediate metalness is allowed of course in theory).

It seems there isn't any way to effectively get the version of the render without the halo currently in OpenPBR. This could be an issue in practical cases, since this use case of rendering a blend of diffuse on metal must be quite common (for e.g. rusty/painted metal) and the halo may not be wanted.

That said, there are other cases where such a halo occurs due to texture filtering (e.g. sharp transitions in roughness), so it could be considered to be a limitation fixed by higher texture resolution.

If we want to fix this, we need to be careful since we don't want to over-complicate the shader and proliferate parameters just for the sake of total control. We certainly don't want to disturb the very common "metalness" PBR workflow, where the base color is explicitly designed to contain both the dielectric and diffuse colors. (Which is obviously standard in various asset libraries etc.).

A possible approach then would be to add a specific override section for separate control over the metal F0, which would be opt-in (i.e. disabled by default). This could amount to a new metal_override checkbox (defaulting to off) and metal_color parameter (the particular names can be debated obviously). They could be seen as more advanced parameters for cases needing specific control over the metal F0 independent of the dielectric base. This would be minimally disruptive since it is strictly additive to the current model, and makes no difference by default. Though as noted, this does add some complexity to the parameter set, so we need to discuss it and agree it makes sense before moving forward.

We should also think about whether there are other such limitations introduced by the parametrization, that could similarly cause problems. For example to get the renders above, I had to make specular_weight equal to the base_metalness, as we want it to be 1.0 for metal, but 0.0 for dielectric, so the "rust" looks diffuse not shiny. In the transition region though, we will unavoidably get a blend of shiny metal and "shiny rust". Also, if there is metal edge-tint via specular_color (which models a physical effect in real metals), this will unavoidably produce tinted specular rust in the transition which probably isn't wanted. Fixing this could involve e.g., if metal_override is on having the specular_weight not apply to the metal and applying a specific metal_edge_tint parameter.

In theory all of the "specular" parameters could be duplicated into metal-specific optional overrides (though do we want to add all these, even if they are disabled by default?).

from openpbr.

I was aware of this limitation of the metal-roughness parametrisation, but I thought this was a generally accepted caveat.
If this happens to be a barrier to adoption, we should indeed address it, but remain very careful of not introducing another barrier (additional complexity and/or rendering cost) to other users in doing so.

I agree with your observations, and a strictly override type of control could be a solution indeed. That being said, it's not obvious how to define such a solution. In comparison, the F-82 tint model for example has the benefit of behaving like a Schlick model with a default value that makes sense with regard to that behaviour.

from openpbr.