OpenPBR: Road to Expressive and Interoperable Material Models — BCON26

Main ideas and lessons

• Interoperable material models are needed for collaboration across tools

  • Working in teams is easier and faster when everyone can share assets without rework.
  • If everyone uses the same software and material model ecosystem, collaboration is straightforward (swap files, keep identical materials/rendering assumptions).
  • In heterogeneous workflows (different DCC apps / renderers), sharing breaks down because:
    • Different apps use different material models, renderers, and scene/file formats.
    • Converting assets often becomes one-way, forcing manual “hand tuning” to match the look again.
    • Iteration gets painful: changes must be redone after conversion.

• The solution is standardized material/asset representation

  • The talk positions interoperability as an “asset exchange” problem and highlights three related open standards/projects:
    • openPBR: standardizes physically based material appearance layering.
    • MaterialX: packages shading networks (node graphs) so look definitions can move between applications.
    • USD: a scene/asset representation that can bundle geometry, materials (e.g., MaterialX), and lighting/workflow components.
  • The talk focuses mainly on the first step toward better Blender interoperability: openPBR integration, plus an outline of upcoming steps (MaterialX authoring and rendering).

---

What openPBR is (conceptual model)

• openPBR is a standard specification for a physically based material model

  • Origin: initiated in 2023 by Adobe and Autodesk as a subproject of MaterialX.
  • Adoption: supported by multiple renderers/apps (examples mentioned: Adobe, Karma, Arnold, V-Ray, Octane, and “soon also Cycles and EV”).
  • Designed to enable consistent material appearance across renderers.

• Layered material model

  • The material is built from layered “slabs” that can be mixed/weighted.
  • Base layer options:
    • Metallic base (for metal-like materials)
    • Dielectric base, split into:
      • Translucent base (glass/crystals/liquids)
      • Opaque base, split into:
        • Subsurface base (skin, plants)
        • Glossy diffuse opaque (wood/granite/plastic)
  • Additional stacked layers:
    • Thin film layer (e.g., oil/grease) to produce color shift and colorful reflections
    • Coat/code layer (clear-coat-like behavior; can be smooth or rough)
    • Fuzz layer (cloth-like sheen from fibers; “sheen” effect)

• Capabilities mentioned

  • The model can represent many physically plausible appearances including:
    • pearls, skin, glass, lights/emission, and more.

---

Relationship to Blender’s Principled BSDF

• They are similar but not identical

  • Principled BSDF influenced openPBR; however, openPBR is constrained to its specification for cross-renderer interchange.
  • The Blender team notes they do not want to fully replace Principled BSDF with openPBR because conversion is not perfectly lossless.

• Minor parameter/behavior differences (examples)

  • Color inputs:
    • Principled uses base color to drive multiple color aspects (diffuse, transmission, subsurface).
    • openPBR uses separate color inputs for finer control.
  • Specular control:
    • Principled has specular IOR level.
    • openPBR has specular weight (described as similar, with a factor/renaming).
  • Subsurface parameterization changes:
    • float vs color inputs; described as effectively multiplicative relationships.
  • Sheen naming:
    • “Sheen” in Blender corresponds to openPBR’s “fuzz” concept (same appearance controlled via roughness).
  • Anisotropy rotation:
    • Principled has additional control for tangent/anisotropic rotation; openPBR spec (as described) does not, so mapping may require extra handling.

• Visual conversion limits

  • Converting from Principled to openPBR yields very similar results, but not a perfect “round trip” without loss—hence compatibility caution.

---

New openPBR features highlighted (artist/renderer controls)

• Transmission depth

  • Motivation: real glass color varies with thickness/path length due to absorption.
  • openPBR introduces transmission depth:
    • Defines the depth at which the transmission color is “reached.”
    • Short path ⇒ brighter transmission; longer path ⇒ darker transmission.
  • Also includes:
    • volume absorption and (separately) volume scattering color and anisotropy.

• Dispersion

  • Motivation: wavelength-dependent refractive indices cause rainbow effects.
  • Parameters and approach:
    • Start with refractive index at a middle wavelength.
    • Use an Abbe number to derive refractive index across wavelengths (referenced as a measurable real-world term).
    • Result: higher Abbe number ⇒ less dispersion.
  • Artist control:
    • Dispersion scale:
      • 0 ⇒ no dispersion
      • 1 ⇒ “full effect” where Abbe number takes effect
      • Allows artistic tuning beyond measured physical settings.

• Thin world mode

  • Motivation: real-world thin glass/panels are difficult/noisy to render accurately using two close surfaces and multiple internal reflections.
  • openPBR “thin world”:
    • Summarizes reflection/transmission events as if they happened through one surface.
    • Produces similar look with less noise.
  • Notes/limitations:
    • Accurate for smooth glass (analytic summation).
    • Approximate for rough glass (speed over accuracy).
  • Related approximation:
    • For thin materials with subsurface scattering (leaves/paper), approximate with:
      • diffuse reflection + diffuse transmission
      • anisotropy controls reflection vs transmission ratio.

• Negative anisotropy for subsurface

  • Blender had only positive anisotropy previously (as described here).
  • openPBR extends anisotropy range to include negative values:
    • More backwards scattering behavior (more diffuse-looking appearance).

• Coat/code darkening

  • Code layer darkening models physically correct darkening from multiple reflections and absorption.
  • Artist override:
    • At 0: color is essentially the specified code color.
    • Allows modulating physically correct intensity.

• Anisotropic roughness extended

  • Anisotropy already existed for glossy materials in Blender.
  • openPBR extends anisotropic roughness to:
    • coat layer and glass.

• Thin film weight

  • openPBR adds a weight/blend controlling influence of thin film:
    • Lets artists tone down a thin film look even when IU/thickness values create the right color.

---

Current integration status in Blender (implementation + roadmap)

• New node: “openPBR shading node”

  • Fully feature complete with respect to openPBR 1.11 spec (as stated).
  • openPBR is ongoing; future spec versions will lead to future Blender updates.

• Release timing

  • Planned release: Blender 5.4
  • Current focus: optimization and bug fixing.

• Renderer support

  • Cycles:
    • Full support with described features, via SVM and OSL backends.
  • Eevee/EV:
    • Partial/approximate match due to rasterization limits.
    • Some effects missing or approximated (noted: volumetric absorption not fully available yet; thin film supported closely; glass color behavior not fully identical).

• USD import/export integration (initial)

  • Blender’s USD capabilities are used to export/import openPBR materials:
    • Export as MaterialX/ USD nodes representation (as described).
    • Enables parameterized materials to be exchanged with apps like Cinema 4D, Houdini, Blender.
  • Example workflow:
    • Convert a shading setup from Principled to openPBR.
    • Export to USD.
    • Render with Karma and Houdini to compare results.
  • Status caveat:
    • MaterialX support in exporter is incomplete for some full graphs; the team is improving import/export.

---

Accuracy across renderers (why matching isn’t automatically perfect)

• They measured differences

  • Reported use of image metrics (e.g., FLIP metric) to evaluate render-to-render appearance consistency.

• Root cause

  • Two independent implementation approaches by the team:
    • Convert shading graph to OSL
    • Or implement spec “one by one” following the written spec
  • Discovered spec ambiguities/unclarities lead to implementation differences between renderers.

• Ongoing effort

  • Collaboration with openPBR community (including contacts from Adobe, side effects, etc.) to:
    • clarify spec wording
    • converge appearances more tightly
    • accept that small differences may remain but should be minimal.

---

openPBR future versions mentioned (1.2 and 1.3 and beyond)

• openPBR 1.2

  • Specular haze
    • Dual specular lobe concept (micro scratches): one sharper lobe + a broader rough secondary lobe.
    • Added parameters:
      • amount of specular haze
      • specular haze spread (shape of secondary lobe)
  • Retro refractivity
    • Reflects light back toward the source (use cases: night streets, security vests, etc.).
    • Said to already be in development and also previously done before Blender’s involvement.

• openPBR 1.3

  • Thin material / thin world improvements based on feedback:
    • Issue described: thin world mode can disable subsurface radius input, limiting leaf-like materials that need different reflection vs transmission colors.
  • Solution direction:
    • Inspired by a rendering paper:
      • model leaves with diffuse reflection + diffuse transmission + a specular layer on top
    • Discussed in openPBR meetings; community responded positively.
  • Encouragement:
    • Blender has a future package ready for testing; expects community feedback.

---

“After openPBR”: next interoperability step = MaterialX support in Blender

• openPBR is only the first of three steps

  1. openPBR for standardized material appearance
  2. MaterialX for portable shader graph authoring
  3. USD for packaging assets/scenes/workflows

• Google Summer of Code project (MaterialX shader authoring)

  • A student (Olly) implemented MaterialX shader graph import/export:
    • import MaterialX graphs into Blender’s shader graph editor
    • allow editing/rebuilding
    • export MaterialX graphs back out
  • Rendering support path used:
    • leverage MaterialX OSL code generation
    • connect to Cycles’ OSL backend to render MaterialX graphs directly
  • Example mention:
    • Nvidia-related complex MaterialX test asset (with Andrea Vri) intended “to break a renderer,” yet rendered in Cycles successfully.
  • Ongoing plan:
    • Continue work to bring the workflow into Blender more fully (not complete yet; “hoping to hear next year” about further progress).

---

Methodology / process described

• Why interoperability matters (problem framing)

  • Identify collaboration friction caused by:
    • differing material models/renderers/scene formats
    • one-way conversions and manual tuning
    • hard iteration when assets must round-trip back to the source tool

• How openPBR aims to fix it

  • Use a standard layered physically based material model
  • Align parameterization to spec so assets can be exchanged across renderers

• How Blender integrates openPBR

  • Implement an openPBR shading node (complete for openPBR 1.11 spec)
  • Support rendering via:
    • Cycles (SVM + OSL backends)
    • Eevee with approximate matches
  • Add USD-based import/export to exchange openPBR/MaterialX representations

• How they improve cross-renderer matching

  • Implement openPBR in Blender (and compare)
  • Run image metric comparisons between renderers
  • Identify spec ambiguities causing mismatches
  • Coordinate with the openPBR community to:
    • clarify spec language
    • converge behavior across implementations

• How they plan future feature evolution

  • Track openPBR spec versions (1.2, 1.3, …)
  • Implement new parameters/features (dispersion, thin film, retroreflectivity, etc.)
  • Use real user feedback and testing packages to guide updates (e.g., thin world/leaf rendering issues)

---

Speakers/sources featured (as named)

• Sebastian Holds (speaker; senior developer and researcher at Blender; works on Cycles; background in path guiding/light transport)
• Way (speaker; rendering developer at Blender; works on Cycles materials/lightning; ex researcher)

---

Additional referenced external entities (not speakers)

• Adobe
• Autodesk
• MaterialX
• USD
• Karma, Arnold, V-Ray, Octane
• Cycles and Eevee/EV
• ASWF (mentioned in meeting context)
• Google Summer of Code (GSoC)
• Olly (student mentioned as implementing MaterialX authoring)
• Nvidia (referenced via an asset collaboration)
• Andrea Vri (mentioned regarding a test asset / expertise in materials)
• a rendering conference paper on leaf rendering (described; not named in the subtitles)
• FLIP metric (mentioned as an image comparison method)