Add "Flexibility of implementation" section by virtualzavie · Pull Request #248 · AcademySoftwareFoundation/OpenPBR

virtualzavie · 2025-02-04T18:42:03Z

This PR is an attempt at addressing requests for some guidance from the real-time community, including #241.

The proposal is to state clearly, in one place that is easy to identify and refer to in the document, what is expected from implementations and what they are allowed to do while still complying to the specification.

Ideally, an annex would propose some approximations they can use, with code snippets ready to use.

dgovil

Thanks for explicitly calling out that approximations are permitted. This will be a very useful clarification.

I left a couple small typo notes as I was going through.

meshula

this PR seems to include much unrelated history. does it need to be rebased?

virtualzavie · 2025-02-07T17:47:52Z

this PR seems to include much unrelated history. does it need to be rebased?

Yes, most likely. I think I either didn't branch off the right point, or didn't open the PR towards the proper branch.

virtualzavie · 2025-02-11T12:34:57Z

this PR seems to include much unrelated history. does it need to be rebased?

I've rebased the branch on top of main, excluding the commits from the 1.x branches that were unrelated to the PR.

meshula · 2025-02-11T21:10:55Z

Thanks! The diff is so much easier to look at now :)

meshula

This is looking good to me. I've suggested that we should more explicitly direct the reader to the named sections ~ but maybe that's not necessary because the document gets published in a way where the sections are immediately obvious?

meshula · 2025-02-11T21:15:34Z

+
+- [#McAuley15] describes a simpler and cheaper method based on [#Revie2011], consisting in modifying normals and offering a very crude approximation of anisotropic reflection.
+
+- Finally, the crudest approximation would be to ignore entirely the `specular_roughness_anisotropy` for the base layer specular lobe (respectively `coat_roughness_anisotropy` for the coat specular lobe), as the anisotropy parametrization in designed to preserve the average roughness regardless of the anisotropy (see the Microfacet model section for details).


since the Microfacet model section is not a named section in this document, can we link or otherwise direct the reader somehow?

portsmouth · 2025-02-18T20:58:48Z

As proposed in the meeting, perhaps we can repurpose this into two PRs, with:

just the wording change that permits approximations, more explicitly. This could maybe just go into the introduction?
a separate document that will be the skeleton of the guidelines? This could also move chunks that are essentially just approximations, into the guidelines. Some candidates for moving out of the spec are (these might be better as sub-PRs though):
- the "Reduction to a mixture of lobes" section, is essentially detailing derivation of one approximate form of the model, that looks like Standard Surface. (This is the main task arguably for an implementer -- i.e. mapping the layer structure to a weighted BSDF combination). It would be interesting to know for example the process that Adobe took, to map the OpenPBR layer structure to a concrete implementation with individual BSDFs.
- the coat darkening/roughening/TIR math, that amounts to a choice of approximation. (Not the part that specifies what the darkening parameter does).
- more SSS remapping choices could be stated.

virtualzavie · 2025-04-15T20:49:35Z

I've reduced this PR to the wording change, with a section in index.html.
I've removed the guidelines part, and will reintroduce it with a separate PR.

meshula · 2025-04-16T20:58:22Z

What's the current status? The latest revisions look good from my perspective. I'm looking forward to the proposal being merged.

portsmouth · 2025-04-29T13:18:13Z

+Flexibility of implementation
+=============================
+
+We want this material model to be renderable on a wide range of platforms, from offline path tracers all the way to real-time game engines on mobile devices.


Not sure this really needs to be a separate section. It could just be paragraphs added to the "objectives" section, so the high-evel objectives/policies are all stated in one place.

I would argue this consideration is important enough to warrant its own section[1] and appear in the table of contents, as it directly addresses an entire industry.

One reason that prompted this discussion is that even though the information was present to an extent, it was not obvious without reading through the document. As a section, it is easy to locate for the reader, and also indicates to future contributors where remarks on this topic should be, to prevent them from being scattered.

1: section or sub-section, if we prefer a different ordering or structure.

portsmouth · 2025-04-29T13:19:35Z

+
+The Historical background and objectives section explains how the goal of this specification is to provide an ideal, reference appearance. Complete conformance to the specification is defined as reproducing all the physical light transport effects of that ideal appearance.
+
+However, a number of features can be computationally expensive and therefore impractical to support under certain constraints. Enforcing a specific implementation would tailor the material model to a particular set of constraints, limiting its versatility, which would ultimately make it less useful. For this reason, the specification focuses solely on defining the target appearance. The choice of the final BSDF implementation and its associated trade-off is left entirely to the implementer, allowing them to best suit it to their needs.


Maybe worth detailing what "constraints" means in this context. Presumably hardware constraints, like CPU/GPU speed and memory? What else, things like choice of graphics API/language?

portsmouth · 2025-04-29T14:07:36Z

+
+Each implementation must decide what level of approximation to use, trading off accuracy for efficiency according to its own particular use case. As a guideline, we suggest approaching those approximations conceptually like different level of detail (LOD) variants of an asset. Just like such an asset would become coarser with distance while retaining as much detail as necessary to remain faithful to the original, an implementation of OpenPBR may decide to make simplifications, as long as the result remains reasonably faithful to the intent given the practical constraints. In the most extreme hypothetical case, the model might even get reduced to as little as a single Lambert BRDF.
+
+This means the implementer must carefully consider the handling of parameters they do not plan to fully support. A parameter that drastically modifies the appearance of a material should not be discarded just because the corresponding effect is not supported. As an example, in a renderer that doesn't have subsurface scattering, the subsurface color might be used as the albedo of a diffuse BRDF.


The general quantitative approach would be to try to make an "as faithful as possible" mapping from the full OpenPBR model to whatever the "target" model is.

For example if the target is the Lambert model, there is one parameter to fit -- the albedo color. The natural thing to do is then set that color to the "diffuse albedo" color of the full OpenPBR model, which would be sum of the albedos of the various lobes which are considered to be diffuse (i.e. rough) enough, e.g. diffuse/subsurface/fuzz, and metal (if rough). That would then automatically account for e.g. the subsurface color, with the correct subsurface weight.

A function which computes those albedos could look something like this.

As an example, in a renderer that doesn't have subsurface scattering, the subsurface color might be used as the albedo of a diffuse BRDF.

That is less clear, since in general you want to use a mix of the colors (i.e. albedos) of the various lobes, according to the lobe weights.

I like the idea of reasoning with albedos. I'll do another pass.

AdrienHerubel

Ready to be merged.

* Update OpenPBR default example (#216) This changelist updates the OpenPBR default example, matching its values to the latest default values of the shading model. * Change thin film IOR default (#211) From 1.5 to 1.4. As this won't make much difference to the look in implementations that ignore the adjacent IORs of the film. But for those that take it into account, this will make the film visible rather than invisible by default (since `specular_ior` is 1.5 by default, and `coat_ior` 1.6). * Add note about dark fuzz (#207) Addressing #176 * Enable Zeltner sheen (#217) This changelist enables Zeltner sheen in the reference implementation of OpenPBR, leveraging the new functionality in MaterialX 1.39. Additionally, the open_pbr_velvet.mtlx example has been updated to account for the visual differences between Conty-Kulla and Zeltner sheen. * Add a "resources" section to the front page (#215) With links to - MaterialX web viewer running OpenPBR default material - OpenPBR-viewer project and web app * Clarify formula for emission color (#209) Following the discussion of #85. * Update subsurface color types (#220) This changelist updates the types associated with physical color values for subsurface scattering in OpenPBR, aligning with the conclusions of recent threads on ASWF Slack channels. - Change `subsurface_radius_scale` from a `vector3` to a `color3` in the specification, aligning with the MaterialX implementation of OpenPBR. - Change the `radius` input of `subsurface_bsdf` from a `vector3` to a `color3` in the MaterialX implementation, aligning with the current definition of the `subsurface_bsdf` node in MaterialX 1.39. * Update specification and reference to v1.1 (#221) * Add "Flexibility of implementation" section (#248) * Add page to propose real-time approximations * Mention layering and mixing approximation * Mantion specular reflection approximation * Mention anisotropic reflection approximations * Fix typos * Wording * Reword the section, move it to the main document, remove the annex * Subsurface in thin-walled mode, small clarification (#258) * Merge v1.1 development to main (#222) This changelist merges v1.1 development from dev_1.1 to main, in preparation for marking the release of OpenPBR v1.1. * Subsurface in thin-walled mode, small clarification * Subsurface in thin-walled mode, small clarification --------- Co-authored-by: Jonathan Stone <jstone@lucasfilm.com> * Allow emission_color components to exceed 1 (#260) * Add more material examples (#257) * Merge v1.1 development to main (#222) This changelist merges v1.1 development from dev_1.1 to main, in preparation for marking the release of OpenPBR v1.1. * Adding more material examples - Bumped MaterialX version from 1.38 to 1.39 on existing examples - Added new examples * - Added MIT Black * Color updates: - Updated all colors to ACEScg - All metals now have F82 as specular_color - Added a few more metals from Portsmouth's chart * Material updates: - Added SSS to Sclera and made it less red - Added LCD Display material - Added two variations of Light Bulb with different CCT * Material updates: - Added base_diffuse_roughness to Brick, Charcoal, and Sand - Made Velvet purple so it's more convincing * Updated roughness values * Removed a few materials that were less useful as examples * Renamed Polyurethane * Updated Blood material * Added Abbe value to Blood material * Updated IOR of Blood * - Updated coffee material * Split Honey into two materials, liquid and crystallized * - Updated Honey (Crystallized) roughness value --------- Signed-off-by: Adrien Herubel <AdrienHerubel@users.noreply.github.com> Co-authored-by: Jonathan Stone <jstone@lucasfilm.com> Co-authored-by: Adrien Herubel <AdrienHerubel@users.noreply.github.com> * Integrate OpenPBR update from MaterialX project (#265) * Integrate OpenPBR updates from MaterialX project This changelist integrates two post-1.1 updates to OpenPBR Surface from the MaterialX project: - Optimizations to OpenPBR graph (AcademySoftwareFoundation/MaterialX#2459) - Add code generation hints support (AcademySoftwareFoundation/MaterialX#1954) The more substantial update is the graph optimization, and I've copied the performance measurements from the original change for reference: Performance tests were conducted on an NVIDIA RTX A6000 at 4K resolution, and the following timing improvements were seen: OpenPBR Carpaint: 16ms -> 7ms OpenPBR Glass: 27ms -> 11ms OpenPBR Pearl: 16ms -> 12ms OpenPBR Aluminum: 14ms -> 5ms * Omit hardware shading optimizations * Move anisotropy figure before Multiple Scattering section * Revert CHANGELOG.md to upstream/dev_1.2 (belongs in separate PR #295) --------- Signed-off-by: Adrien Herubel <AdrienHerubel@users.noreply.github.com> Co-authored-by: Jonathan Stone <jstone@lucasfilm.com> Co-authored-by: Julien Guertault <9511025+virtualzavie@users.noreply.github.com> Co-authored-by: Anton Palmqvist <13031779+AntonPalmqvist@users.noreply.github.com> Co-authored-by: Adrien Herubel <AdrienHerubel@users.noreply.github.com> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

dgovil approved these changes Feb 5, 2025

View reviewed changes

Comment thread approximation.md.html Outdated

Comment thread approximation.md.html Outdated

Comment thread approximation.md.html Outdated

AdrienHerubel self-requested a review February 5, 2025 13:44

meshula reviewed Feb 7, 2025

View reviewed changes

Comment thread approximation.md.html Outdated

virtualzavie added 6 commits February 11, 2025 13:31

Add page to propose real-time approximations

65418e2

Mention layering and mixing approximation

a26ca21

Mantion specular reflection approximation

d13d2c9

Mention anisotropic reflection approximations

54631b0

Fix typos

c621842

Wording

a3e56a1

virtualzavie force-pushed the real-time branch from fdd20b3 to a3e56a1 Compare February 11, 2025 12:32

meshula reviewed Feb 11, 2025

View reviewed changes

Reword the section, move it to the main document, remove the annex

f40b79a

virtualzavie changed the title ~~Propose guidelines and approximations for real-time implementation~~ Add "Flexibility of implementation" section Apr 15, 2025

virtualzavie marked this pull request as ready for review April 17, 2025 17:12

portsmouth reviewed Apr 29, 2025

View reviewed changes

AdrienHerubel changed the base branch from main to dev_1.1.1 June 10, 2025 15:17

AdrienHerubel added the 1.1.1 label Jun 10, 2025

AdrienHerubel approved these changes Jun 10, 2025

View reviewed changes

AdrienHerubel merged commit 8753966 into AcademySoftwareFoundation:dev_1.1.1 Jun 10, 2025
1 check passed


		- [#McAuley15] describes a simpler and cheaper method based on [#Revie2011], consisting in modifying normals and offering a very crude approximation of anisotropic reflection.

		- Finally, the crudest approximation would be to ignore entirely the `specular_roughness_anisotropy` for the base layer specular lobe (respectively `coat_roughness_anisotropy` for the coat specular lobe), as the anisotropy parametrization in designed to preserve the average roughness regardless of the anisotropy (see the Microfacet model section for details).


		The Historical background and objectives section explains how the goal of this specification is to provide an ideal, reference appearance. Complete conformance to the specification is defined as reproducing all the physical light transport effects of that ideal appearance.

		However, a number of features can be computationally expensive and therefore impractical to support under certain constraints. Enforcing a specific implementation would tailor the material model to a particular set of constraints, limiting its versatility, which would ultimately make it less useful. For this reason, the specification focuses solely on defining the target appearance. The choice of the final BSDF implementation and its associated trade-off is left entirely to the implementer, allowing them to best suit it to their needs.


		Each implementation must decide what level of approximation to use, trading off accuracy for efficiency according to its own particular use case. As a guideline, we suggest approaching those approximations conceptually like different level of detail (LOD) variants of an asset. Just like such an asset would become coarser with distance while retaining as much detail as necessary to remain faithful to the original, an implementation of OpenPBR may decide to make simplifications, as long as the result remains reasonably faithful to the intent given the practical constraints. In the most extreme hypothetical case, the model might even get reduced to as little as a single Lambert BRDF.

		This means the implementer must carefully consider the handling of parameters they do not plan to fully support. A parameter that drastically modifies the appearance of a material should not be discarded just because the corresponding effect is not supported. As an example, in a renderer that doesn't have subsurface scattering, the subsurface color might be used as the albedo of a diffuse BRDF.

Conversation

virtualzavie commented Feb 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dgovil left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

meshula left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

virtualzavie commented Feb 7, 2025

Uh oh!

virtualzavie commented Feb 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

meshula commented Feb 11, 2025

Uh oh!

meshula left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

meshula Feb 11, 2025

Choose a reason for hiding this comment

Uh oh!

portsmouth commented Feb 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

virtualzavie commented Apr 15, 2025

Uh oh!

meshula commented Apr 16, 2025

Uh oh!

portsmouth Apr 29, 2025

Choose a reason for hiding this comment

Uh oh!

virtualzavie May 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

portsmouth Apr 29, 2025

Choose a reason for hiding this comment

Uh oh!

portsmouth Apr 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

virtualzavie May 15, 2025

Choose a reason for hiding this comment

Uh oh!

AdrienHerubel left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

virtualzavie commented Feb 4, 2025 •

edited

Loading

virtualzavie commented Feb 11, 2025 •

edited

Loading

portsmouth commented Feb 18, 2025 •

edited

Loading

virtualzavie May 15, 2025 •

edited

Loading

portsmouth Apr 29, 2025 •

edited

Loading