[PBR extension] Parameter Set

[mlimper]

Initially, we have proposed two parameter sets: "Specular-Glossiness" (short: "glossiness") and "Metallic-Roughness" (short: "roughness"). One the one hand, this allows for more freedom, as assets may be given in one or the other format. On the other hand, it might be better to have only one parameter set, for increased simplicity, ease of implementation and portability.

If we agree to use only one parameter set, we will have to decide which one that should be. The roughness model might be popular and easy to use with several existing systems. The glossiness model allows for a bit more freedom, as the proposed specular component has three channels.

[FslNopper]

From my side, I prefer the metallic/roughness approach and should be standard to be glTF compliant. The specular/glossiness could/should be done as an extension.

I suggest to store the following PBR values. I do not go into the ambient, normal and other texture maps, as I think the approach is clear:

baseColor metallic roughness f0_metal f0_nonMetal

Furthermore, each of the above values can either be:

value (scalar, vector and so on) or texture

Regarding the texture, there are several access / sample methods:

Channels: r, g, b, a rgb, rgba luminance

[mlimper]

Looks like Metallic-Roughness is really the most popular approach, and that it would allow us to cover the very most use cases directly: https://github.com/KhronosGroup/glTF/issues/699#issuecomment-253219927

My main point is that specular/glossiness is not an energy-conserving system in any real way, which to my mind disqualifies it from being called a PBR-based model.

And that's another good point.

The specular/glossiness could/should be done as an extension.

Agreed!

So, if no one will strongly protest within the next few weeks, we will consider this issue as closed and proceed by limiting ourselves, for now, to the metallic-roughness parameter set. We will figure out the exact set of maps for this model (https://github.com/KhronosGroup/glTF/issues/699). Specular/Glossiness could be added later on, as an(other) extension.

[jeffdr]

I can see the appeal to sticking with one or the other instead of supporting both, and I can buy that a majority of artists are using the Metalness workflow, so going with that simple approach makes some sense. You're shutting out some existing content from automatic conversion by doing this, but maybe that doesn't matter.

My main point is that specular/glossiness is not an energy-conserving system in any real way, which to my mind disqualifies it from being called a PBR-based model.

This is false, as I've stated before in this thread. The spec/gloss model does energy conservation just fine, and algebraically in almost the exact same way metalness does (the diffuse contribution is simply masked by the inverse of the reflectivity in the shader, and no special treatment by the artist is required). A PBR specular/gloss shader is sometimes confused in this way with "pre-PBR" shaders that also used spec and gloss maps without energy conservation.

[cedricpinson]

Agree with @jeffdr it's clearly easy to support both, not need to discard one.

[mlimper]

Alright, thanks for the quick feedback.

As we initially proposed to support both, we are, of course, also fine with that ;-) I'd just like to make a decision soon, so that we can close this one.

@pjcozzi @erich666 Any thoughts?

[emackey]

+1 for both.

[pjcozzi]

Whatever folks decide is fine with me; doing one is clean, but doing both doesn't sound like an implementation burden.

I believe @sbtron has a demo showing the two shading models, and the difference was not significant. @sbtron can you comment and share a link?

[sbtron]

@bghgary has an example showing conversion between the two workflows: https://bghgary.github.io/glTF/convert-between-workflows/ Heres some example assets created with both workflows - https://sbtron.github.io/BabylonJS-glTFLoader/

@bghgary can comment on this more?

[bghgary]

@bghgary can comment on this more?

I agree with having both for PBR as an extension. However, when considering putting PBR into the core spec (#733), we should pick a workflow that is the min-bar to maximize adoption, which in this case is metallic-roughness. Specular-glossiness workflow can be an extension.

There are low-resource devices out there that will only support metallic-roughness since they have a hard requirement on the number of channels passed to the shaders to limit resource usage. These devices will not be able to support specular-glossiness without implementing a slow conversion on load.

Consider these scenarios:

1. Runtime implementation supports both. Anything we chose is fine.
2. Runtime implementation supports specular-glossiness only. Runtimes for low-resource devices can be modified to support metallic-roughness. It is relatively cheap to add support for metallic-roughness without introducing more resources.
3. Runtime implementation supports metallic-roughness only. Runtimes for low-resource devices cannot be easily modified to support specular-glossiness since it cannot handle the extra channels. The only other option I see is to convert to metallic-roughness on load. This will result in lossy conversion and longer load times if spec supports both and specular-glossiness is used, or the spec supports specular-glossiness only.

If only metallic-roughness is part of the core spec, we can require all runtimes to implement the core spec (metallic-roughness) and get consistent adoption. For scenarios that require specular-glossiness, which may not be implemented by all runtimes, they can use a specular-glossiness extension.

[pjcozzi]

Just so everyone is on the same page: we do intend to make PBR core spec ASAP.

@bghgary's proposal of metallic-roughness in core + specular-glossiness extension (that would come out at the same time) sounds pragmatic. I expect the extension would become widely supported.

I don't have the domain knowledge to contribute meaningfully here, but I'd like to ask that we aim to converge on this by next Monday, Jan 9 (just the core/extension decision, smaller spec details can converge later) so the Khronos folks can get all the spec work lined up.

@mlimper @jeffdr @erich666 @cedricpinson @emackey @FslNopper @vorg and anyone else?

[jeffdr]

I'm onboard with metallic/roughness + spec/gloss extension. The virtue of its simplicity probably outweighs the drawbacks.

[mlimper]

Fine with that!

[pjcozzi]

Given everyone's feedback above, we are going with @bghgary's proposal of metallic-roughness in core + specular-glossiness extension (that would come out at the same time) sounds pragmatic.

@mlimper let's finalize all the work in your current extension then we will cut-and-paste-ish part of it to core spec. OK?

[mlimper]

Yes, let's do it like that.

[xelatihy]

@pjcozzi @mlimper One more opinion on this.

While I realize that this is close, there is a significant problem with using metallic-roughness in that many materials cannot be represented this way, while the can be represented using specular-glossiness.

For example all models saved as OBJ cannot be converted to PBRT with metallic-roughness, so I am not sure that adoption is better if we have very little models as input.

I agree with @bghgary about the low performance devices, but the question is how many of those devices will around in a couple of years when glTF will become (I hope) mainstream. Also consider that to render PBR materials accurately there are many more resources needed for shadowing computation compare to material shading.

Furthermore, although this might not be the of interests here, most academic literature as shown that diffuse-specular cover a significant space of useful materials, while metallic-roughness is only halpful for editing at the price of subsetting the representable materials substantially.

For example, many materials fitted from real measurement cannot be projected onto metallic-roughness without loosing some look.

I hope this decision is not finalized yet.

[xelatihy]

I would pur both parameter set and have the asset author choose which one. This has the benefit of @bghgary for metallic-roughness, as well as can represent most materials using spcular-glossiness, without subsetting the materials types supported.

[emackey]

@xelatihy point of clarification. It's been explained (to me, among other people) a few times in the PBR discussions in this repo that the PBR version of albedo/spec/gloss is not at all the same shading model as a traditional diffuse/ambient/spec/gloss. To support things like classic OBJ models, we would use the KHR_materials_common extension, with the traditional shading model, not PBR's spec/gloss extension.

[emackey]

Perhaps this warrants a non-normative note in the spec, as I imagine many folks encountering PBR would initially scratch their heads wondering why spec/gloss was relegated to an extension.

[FslNopper]

@xelatihy Low power (in any meaning) devices will probably always be around. In automotive, there will be still a lot of such devices. Also, some Internet of Things devices will also have displays and they will be for sure low power devices.

[ghost]

I agree with all people pushing to support both metal + spec workflow by default. All big player like UE / Unity / Sketchfab / Marmoset / Substance support both. Pushing by default in one direction, is not the best way imo to build a good agnostic specs.

[pjcozzi]

We are collecting requirements for next-gen PBR in glTF, please chime in to #1442.