Updates to Support PhysicallyBased V2 : Part I. by kwokcb · Pull Request #37 · kwokcb/materialxMaterials

kwokcb · 2026-03-03T16:55:55Z

Changes

Handle color and specular color JSON changes in V2. Including specular_color format, and colorspace additions.
Choose F82 correct specular color format for glTF vs SS vs OPBR. Default of Gulbrandsen is used for Standard Surface. This would also work for Disney and USDPreview if conversion support were to be added .
Re-run translation for each shading model. Basically no change except colorspace is made explicit now. i.e. all color inputs set lin_rec709.
Update physically_based nodedef and translation graphs. Note that some parameters are bypassed since the parameters have different formats for different materials. To be addressed on input data side.

Example Output:

SS Cobalt: (explicit linear colorspace, Gulbrandsen format for specular color)

<standard_surface name="Cobalt_SS_SHD_PBM" type="surfaceshader" uiname="Cobalt" uifolder="Metal" doc="Reference: https://raw.githubusercontent.com/AntonPalmqvist/physically-based-api/main/images/renders/cycles/300/cobalt.avif">
    <input name="base_color" type="color3" value="0.699, 0.704, 0.671" colorspace="lin_rec709" />
    <input name="metalness" type="float" value="1" />
    <input name="specular_color" type="color3" value="0.731, 0.775, 0.715" colorspace="lin_rec709" doc="Format: Gulbrandsen" />
    <input name="specular_roughness" type="float" value="0" />
  </standard_surface>

OpenPBR Cobalt: (explicit linear colorspace, F82 format for specular color)

  <open_pbr_surface name="Cobalt_OPBR_SHD_PBM" type="surfaceshader" uiname="Cobalt" uifolder="Metal" doc="Reference: https://raw.githubusercontent.com/AntonPalmqvist/physically-based-api/main/images/renders/cycles/300/cobalt.avif">
    <input name="base_color" type="color3" value="0.699,0.704,0.671" />
    <input name="base_metalness" type="float" value="1" />
    <input name="specular_color" type="color3" value="0.727,0.772,0.823" doc="Format: F82" />
    <input name="specular_roughness" type="float" value="0" />
  </open_pbr_surface>

glTF Cobalt: (explicit linear colorspace, F82 format for specular color)

  <gltf_pbr name="Cobalt_GLTF_SHD_PBM" type="surfaceshader" uiname="Cobalt" uifolder="Metal" doc="Reference: https://raw.githubusercontent.com/AntonPalmqvist/physically-based-api/main/images/renders/cycles/300/cobalt.avif">
    <input name="base_color" type="color3" value="0.699, 0.704, 0.671" colorspace="lin_rec709" />
    <input name="metallic" type="float" value="1" />
    <input name="specular_color" type="color3" value="0.727, 0.772, 0.823" colorspace="lin_rec709" doc="Format: F82" />
    <input name="roughness" type="float" value="0" />
  </gltf_pbr>

…lorspace and format (for specular) is to take the first entry which preserves the previous values but now with proper colorspace tagging.

…srgb_texture.

…iseny and USDPreview are not currently supported but the default is Gulbrandsen. There is no BSDF for Lama nodes but the default should work there as well. - Fix colorspace specification. It was being used for all inputs instead of just ones where specifeid. - Fix transmission color colorspace setting. - Rerun translation for each shading model.

…r does not write lin_rec709 unless specified by option.

AntonPalmqvist

OpenPBR assumes ACEScg by default , so the color space needs to specifically be set to lin_rec709 when using that color space. For ACEScg it can be left empty.

StandardSurface doesn't seem to have a default color space, so the color space should always be set explicitly there.

… set for clariity.

kwokcb · 2026-03-03T21:21:56Z

OpenPBR assumes ACEScg by default , so the color space needs to specifically be set to lin_rec709 when using that color space. For ACEScg it can be left empty.

StandardSurface doesn't seem to have a default color space, so the color space should always be set explicitly there.

I've made colorspace always explicit.
OpenPBR in MaterialX never specifies a default colorspace. The only nodes that do so are Lama nodes.

I have patched custom phybased definition but it won't work since there is no 1 interface that can be used for multiple targets. i.e. you can't store 1 value when different values are required per backend.

kwokcb · 2026-03-03T21:25:02Z

+                colorspace = ''
+                input_doc = ''
+
+                if key in ['viscosity', 'density', 'thinFilmThickness']:


The format for these differs between materials now. No idea how to map to a single definition input. Sometimes it is float, vec2, or vec3.

I can appreciate this causes some friction.

I wanted to give every implementer a chance to display the value they think is most useful, or all values if they prefer that. However in the case of MaterialX, only one value can be used of course.

For example, the Thin Film Thickness for Soap Bubble can be between 10-1000, with 500 being the most common thickness.
I would check if [2] in the array is present, and if not, choose either [1] or [0]. You could also calculate the average of [0] and [1] and use that.

Hope it makes sense.

For the nodedef, this can't be dynamic as there is only 1 definition not a definition per material.

So if a parameter can be specified with 1, 2 or 3 values, then if the parameter is specified with the highest ordinal, the assigned value would have to have "dummy" values added
to "pad" it.

The current possible validation errors are as follows, without "padding"

Invalid value: <input name="viscosity" type="vector3" value="1.7"> Invalid value: <input name="viscosity" type="vector3" value="46"> Invalid value: <input name="viscosity" type="vector3" value="0.6"> Invalid value: <input name="viscosity" type="vector3" value="1.552"> Invalid value: <input name="viscosity" type="vector3" value="2"> Invalid value: <input name="thinFilmThickness" type="vector3" value="20, 300"> Invalid value: <input name="viscosity" type="vector3" value="1.002">

- Delete acescg translations

AntonPalmqvist

I've tested the different .mtlx outputs in both MaterialXViewer and Unreal Engine 5.7 without issues.

AntonPalmqvist and others added 6 commits February 28, 2026 09:28

Started work on updating the Physically Based API call to v2.0

bf09888

Add in colorspace tagging and handle specular color. The choise of co…

f9845b1

…lorspace and format (for specular) is to take the first entry which preserves the previous values but now with proper colorspace tagging.

Merge branch 'pr-36-local'

cec7663

Leave a Q. Is srgb-linear lin_rec709 or srgb_texture. Current set to …

21a637d

…srgb_texture.

Fix to colorspace writing. Choose based on option. Default srgb-linea…

0fde00a

…r does not write lin_rec709 unless specified by option.

kwokcb requested a review from AntonPalmqvist March 3, 2026 19:09

AntonPalmqvist reviewed Mar 3, 2026

View reviewed changes

kwokcb added 2 commits March 3, 2026 15:15

Fix up mapping of colors, colorspace for custom definitions.

f4b5104

Remove "default" colorspae behaviour. Colorspace is always explicitly…

23158f4

… set for clariity.

kwokcb commented Mar 3, 2026

View reviewed changes

kwokcb force-pushed the main branch from 21a637d to 456508f Compare March 3, 2026 21:28

kwokcb changed the title ~~More Updates for PhysicallyBased V2~~ Updates to Support PhysicallyBased V2 Mar 3, 2026

- Remove colorspace option for now. Will always choice linear.

16bf39e

- Delete acescg translations

kwokcb changed the title ~~Updates to Support PhysicallyBased V2~~ Updates to Support PhysicallyBased V2 : Part I. Mar 4, 2026

kwokcb requested a review from AntonPalmqvist March 4, 2026 04:00

AntonPalmqvist approved these changes Mar 4, 2026

View reviewed changes

kwokcb merged commit c8f0d9c into main Mar 4, 2026

kwokcb deleted the pb_v2_translation_fixes branch March 4, 2026 04:56

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Updates to Support PhysicallyBased V2 : Part I.#37

Updates to Support PhysicallyBased V2 : Part I.#37
kwokcb merged 9 commits intomainfrom
pb_v2_translation_fixes

kwokcb commented Mar 3, 2026 •

edited

Loading

Uh oh!

AntonPalmqvist left a comment •

edited

Loading

Uh oh!

kwokcb commented Mar 3, 2026

Uh oh!

kwokcb Mar 3, 2026

Uh oh!

AntonPalmqvist Mar 4, 2026

Uh oh!

kwokcb Mar 4, 2026 •

edited

Loading

Uh oh!

AntonPalmqvist left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

kwokcb commented Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Uh oh!

AntonPalmqvist left a comment • 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!

kwokcb commented Mar 3, 2026

Uh oh!

kwokcb Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

AntonPalmqvist Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

kwokcb Mar 4, 2026 • 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!

AntonPalmqvist left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

kwokcb commented Mar 3, 2026 •

edited

Loading

AntonPalmqvist left a comment •

edited

Loading

kwokcb Mar 4, 2026 •

edited

Loading