Support for PBR material parameters, auto shader

Pipeline
1

Experimenting with my exporter, I found that the auto shader supports the metallic parameter.

metallic
metallic1185×1000 32.7 KB

Maybe I missed the information about it…

1 Like
2

You can specify a material’s colours as either a pair of (diffuse, specular) colours, or in the new-fangled manner, as a “base color” with a “metallic” boolean parameter. The former is more in line with natural properties and with how shading equations are written. This latter model is considered more artist-friendly, making it more difficult to generate unrealistic materials, because:

  1. People tend to think of materials as having only a single colour.
  2. Specifying both colours can lead to conservation of energy being violated.
  3. Metals do not have a diffuse colour, only a specular colour.
  4. Dielectrics (non-metals) have a constant but dim specular colour, usually a grayscale 0.04, determined from the refractive index (which should be 1.5 for most materials, but is 1.0 by default for compatibility).

If you pass a material specifying a base color and metallic value to a shader that takes a diffuse and specular colour, then Panda will automatically generate diffuse and specular colours based on the above.

1 Like
3

This feature is understandable from one angle, but from another it can cause confusion. Users may want to use some parameters for their own purposes for shading, but they will encounter the fact that one parameter overrides another.

It would be ideal to create a subtype of the material that is relevant for a particular technique.

4

So how should a model loaded from glTF 2.0 be rendered using a legacy shader, or the auto shader, or the FFP? Pure white?

5

I am sure that this is the correct behavior if each shader system uses the parameters that are intended for it. Inter-compatibility should be implemented differently, there should be a convenient function for converting one type material into another.

At the moment, this functionality is built right into the material class, which seems to me too difficult to understand and unmanageable. I think the material should consist of general static parameters.

And so transform: material.convert_to(Material.type.PBR)