Define unspecified BSDFs

[anderslanglands]

Currently diffuse and fuzz bsdfs are unspecificied. From our point of view, these would be much better explicitly specified as not doing so will necessarily lead to look differences between implementations.

[portsmouth]

In our most recent meeting we discussed this, and were all in general agreement that it would be best to do what you suggest and make very specific, clear recommendations about the implementation details (BSDFs, layering model, mappings, ..). As otherwise there is no clear "ground truth" that is unambiguously specified.

The specific recommendations can evolve over time (to incorporate better models as they appear, perhaps, or industry feedback), using versioning to manage this.

This deviates a bit from the currently stated philosophy:

We will generally remain agnostic about the actual specific functional form and details of the BSDFs (or VDFs), leaving it for the implementation to make reasonable assumptions given a verbal description of the slab physical properties and the described parameters. [...] we do not want to dictate specific implementations for the BSDFs since models may need to differ depending on the hardware constraints, and also tend to evolve over time. We hope the provided verbal description combined with the set of parameters is sufficient to make it reasonably unambiguous what a good implementation would look like.

So the spec will need to refactored to take this change into account.

This does mean that we will bake into the spec certain approximations which not all renderers may wish to make. For example, using "non-reciprocal albedo scaling" (equation 5) for the layering math. Perhaps this is reasonable though, since it is better to specify some concrete albeit crude approximation, than be unclear about what is supposed to be implemented.

[anderslanglands]

I think it’s better this way: if a particular implementation wants to use a different function because it’s “better” or “faster” for their particular renderer they at least do so knowing what the visual target is and the difference is easily quantifiable.

On Sun, 27 Aug 2023 at 01:00, Jamie Portsmouth @.***> wrote:

In our most recent meeting we discussed this, and were all in general agreement that it would be best to do what you suggest and make very specific, clear recommendations about the implementation details (BSDFs, layering model, mappings, ..). As otherwise there is no clear "ground truth" that is unambiguously specified.

The specific recommendations can evolve over time (to incorporate better models as they appear, perhaps, or industry feedback), using versioning to manage this.

This deviates a bit from the currently stated philosophy:

We will generally remain agnostic about the actual specific functional form and details of the BSDFs (or VDFs), leaving it for the implementation to make reasonable assumptions given a verbal description of the slab physical properties and the described parameters. [...] we do not want to dictate specific implementations for the BSDFs since models may need to differ depending on the hardware constraints, and also tend to evolve over time. We hope the provided verbal description combined with the set of parameters is sufficient to make it reasonably unambiguous what a good implementation would look like.

So the spec will need to refactored to take this change into account.

This does mean that we will bake into the spec certain approximations which not all renderers may wish to make. For example, using "non-reciprocal albedo scaling" (equation 5) for the layering math. Perhaps this is reasonable though, since it is better to specify some concrete albeit crude approximation, than be unclear about what is supposed to be implemented.

— Reply to this email directly, view it on GitHub https://github.com/AcademySoftwareFoundation/OpenPBR/issues/84#issuecomment-1694335769, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOYQXMX6BZPUI2AUYSDGWLXXHXN3ANCNFSM6AAAAAA3ZFBH7E . You are receiving this because you authored the thread.Message ID: @.***>

[jstone-lucasfilm]

Thanks for these key recommendations, @anderslanglands, and I believe these issues are now resolved in the main branch of OpenPBR.