Initial render comparison in GitHub CI by jstone-lucasfilm · Pull Request #2908 · AcademySoftwareFoundation/MaterialX

jstone-lucasfilm · 2026-05-10T22:28:32Z

This changelist takes a step toward broader render validation in our GitHub CI, adding an extended job that generates a downloadable HTML/PDF report comparing rasterized (MSL) and ray-traced (OSL) renders of the test suite side-by-side with per-pixel differences, allowing contributors to validate shading updates in their fork without building OSL locally. The following specific changes are included:

Add an extended CI job that builds OSL v1.14.10.0 from source, runs MSL and OSL render tests at reference quality, and uploads an HTML/PDF comparison report as an artifact.
Add the OpenPBR and UsdPreviewSurface example folders to the render test suite, replacing the less-critical pbrlib/surfaceshader folder, and adding a renderTestExcludeFiles option to skip individual files.
Tune reference-quality sample counts to fit within the render capabilities and time budget of GitHub CI: rasterization supersample factor 8 -> 2, OSL lit -aa 32 -> 16 (1024 -> 256 spp), OSL unlit -aa 8 -> 2 (64 -> 4 spp).
Centralize reference quality parameters in getRasterEnvSampleCount and getRasterSupersampleFactor helpers, removing duplicated constants across hardware shading targets.
Replace the MATERIALX_RENDER_MSL_ONLY flag with MATERIALX_TEST_RENDER_GLSL for clarity, and replace the enableReferenceQuality test flag with a MATERIALX_TEST_REFERENCE_QUALITY build option.

As a logical next step, we might consider publishing the HTML artifact as a MaterialX Fidelity Suite (in the spirit of https://github.com/bhouston/material-fidelity), allowing any member of the community to view the current state of MaterialX render parity at a glance.

This changelist takes a step toward broader render validation in our GitHub CI, adding an extended job that generates a downloadable HTML/PDF report comparing rasterized (MSL) and ray-traced (OSL) renders of the test suite side-by-side with per-pixel differences, allowing contributors to validate shading updates in their fork without building OSL locally. The following specific changes are included: - Add an extended CI job that builds OSL v1.14.10.0 from source, runs MSL and OSL render tests at reference quality, and uploads an HTML/PDF comparison report as an artifact. - Add the `OpenPBR` and `UsdPreviewSurface` example folders to the render test suite, replacing the less-critical `pbrlib/surfaceshader` folder, and adding a `renderTestExcludeFiles` option to skip individual files. - Tune reference-quality sample counts to fit within the render capabilities and time budget of GitHub CI: rasterization supersample factor 8 -> 2, OSL lit -aa 32 -> 16 (1024 -> 256 spp), OSL unlit -aa 8 -> 2 (64 -> 4 spp). - Centralize reference quality parameters in `getRasterEnvSampleCount` and `getRasterSupersampleFactor` helpers, removing duplicated constants across hardware shading targets. - Replace the `MATERIALX_RENDER_MSL_ONLY` flag with `MATERIALX_TEST_RENDER_GLSL` for clarity, and replace the `enableReferenceQuality` test flag with a `MATERIALX_TEST_REFERENCE_QUALITY` build option. As a logical next step, we might consider publishing the HTML artifact as a MaterialX Fidelity Suite (in the spirit of https://github.com/bhouston/material-fidelity), allowing any member of the community to view the current state of MaterialX render parity at a glance.

kwokcb

This looks like a great step to getting reference compares up.
There are a few points left in the code, with the most noteworthy is the time to build OSL which looks like it will occur for every check-in.
Also just wanted to check that a regular Mac render test run will still by default render out both GLSL and Metal but the safeguards are in place for MaterialXView.

kwokcb · 2026-05-11T14:31:40Z

        C:/vcpkg/vcpkg install mdl-sdk --triplet=x64-windows-release
        Add-Content $env:GITHUB_PATH "C:/vcpkg/installed/x64-windows-release/bin"

+    - name: Install OSL


I'm curious if any caching can be done here to not have to rebuild on every check-in ? I assume it's a noticeable amount of time and could gate the time for getting back CI results.

Another point of note is could this be put into a script file for maintenance and reuse. e.g. if a local dev wants to build OSL, this would be a useful script.

Although caching is a valid option for the future, the OSL build step only occurs in nightly/manual builds of MaterialX, rather than per-commit builds. Additionally, the OSL install/build step is remarkably fast on MacOS, taking just 3 minutes and 16 seconds in the latest run!

If we wanted to add caching in the future, we should be careful about the increased cache-invalidation surface area of this approach, where subtle changes in dependencies can lead to caching errors that are hard to track down.

That’s what I was wondering. Could we leave a comment for clarity, otherwise looks good.

kwokcb · 2026-05-11T14:33:24Z

    - name: Install Python Dependencies
      if: matrix.python != 'None'
-      run: pip install setuptools
+      run: pip install setuptools ${{ env.IS_EXTENDED_BUILD == 'true' && matrix.extended_build_osl == 'ON' && 'Pillow' || '' }}


Might be better to create a requirements.txt file and install that. Then it's flexible and reusable.
e.g. Switching to use OpenImageIO instead of Pillow would only require changing the requirements file.

For now, since this is just a single line, and the Pillow dependency isn't repeated in other steps or scripts, I'd recommend staying with the explicit statement here. If our set of render dependencies grows beyond just Pillow, though, I'd say you're right, and that an independent list of requirements would be worthwhile.

having an external requirements.txt would make it a little more straight forward to replicate the setup of these tests locally?

I think it would be good to move in a direction where the environment curation and launching of the CI tests are managed by scripts that can also be run locally - that would improve the developer experience.

@ld-kerley I'm very open to the local reproducibility argument that you make here, though it seems slightly premature to introduce a requirements.txt file for the single install of Pillow for render testing. Perhaps we should wait until there's a second requirement and then take this step?

I think it’s still better to setup this in a file, even if it’s one dependency. I doubt anyone would look at ci for dependicies she running locally.

Got it, and I've made the change.

kwokcb · 2026-05-11T14:34:53Z

          compiler_version: "14"
          python: 3.14
-          test_render: ON
+          render_captures: ON


No big deal. This just sounds a bit strange to me.
Maybe something like render_reference_images instead ?

I'm very open to ideas on improving this name, though render_captures is the flag associated with our Viewer/Editor frame captures, not with the render test suite. Naming it render_reference_images might blur this distinction, making it sound like this flag is associated with the render test suite.

I'm with Bernard here - when I read captures it wasn't immediately obvious to me what these were. Perhaps render_refernce_tool_images?

Thanks @ld-kerley, and I'm open to coming up with a better name in this thread.

My hesitation with render_reference_tool_images is the use of the word "reference", which overlaps our usage of MATERIALX_TEST_REFERENCE_QUALITY and other terminology in the render test suite.

This flag actually gates a mix of render captures across Python and C++ tools -- baketextures.py, translateshader.py, MaterialXView, and MaterialXGraphEditor -- so perhaps tool_captures would strike the right balance?

capture_tool_renders ? Btw, won’t hold up the or for the naming :).

Got it, thanks @kwokcb, and I've proposed tool_render_captures in the latest update to the PR.

kwokcb · 2026-05-11T14:40:41Z

+          -l1 msl -l2 osl -d \
+          --order-from "$GITHUB_WORKSPACE/resources/Materials/TestSuite/_options.mtlx" \
+          -o MaterialX_RenderComparison.html
+        CHROME="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"


Seems a bit strange to use Chrome print to convert. Suggest to use something like Playright CI action or install something like Pandoc.

Also I seems for ability to view easily it could just be left as html.

I tried a few different approaches before settling on Chrome, and here are the advantages that I found with Chrome:

Chrome comes pre-installed on MacOS environments, while Playwright/Pandoc have additional dependencies that require separate installation.

Chrome handles colors more accurately than the other approaches I tried, and honors the print-color-adjust: exact setting in CSS.

Some alternatives (e.g. weasyprint) failed to handle the formatting in our HTML, while Chrome handles them well.

On your note about providing HTML directly, this workflow uploads the full HTML and source images as well, giving developers the choice of which they prefer to view.

relying on chrome being delivered from the MacOS GitHub image feels like we're exposing ourselves to changing changes in the future - as opposed to installing some explicitly versioned package - as Bernard requests. The GitHub CI images seem to change a worryingly frequent amount.

@ld-kerley I'm open to adding an explicit brew install --cask google-chrome here if that sounds valuable, but it's worth noting that a missing Chrome is not fatal to the workflow, and the GitHub CI would simply generate HTML only and emit a warning. Let me know if you'd like me to add a command along these lines.

Perhaps we can iterate on this. As said, I think it’s fine to just leave as html.

kwokcb · 2026-05-11T14:47:37Z

    fh = open(args.outputfile,"w+")
    fh.write("<html>\n")
    fh.write("<style>\n")
+    # Preserve inline background-color when printing to PDF, so transparent renders


Is the background color for the image not set when rendering ? Or is it set to be transparent ?

Yes, the PNGs have alpha and the table cells supply a black backdrop.

jstone-lucasfilm · 2026-05-11T17:37:27Z

Thanks for your notes above, @kwokcb!

To answer your question about MacOS default behavior, there are two distinct cases worth separating out:

Render tests: MATERIALX_TEST_RENDER_GLSL defaults to ON, so a default Mac build still runs both the GLSL and MSL render-test paths. Only the extended MacOS CI job opts out by passing -DMATERIALX_TEST_RENDER_GLSL=OFF. It's the same effective behavior as the old MATERIALX_RENDER_MSL_ONLY=ON, just renamed.
MaterialXView: Removing the MSL_ONLY branch is a no-op for the standard Mac build, as USE_OPENGL_BACKEND_ON_APPLE_PLATFORM defaults to OFF on macOS ≥ 10.14, which already selects the Metal backend. Anyone who hasn't explicitly opted into OpenGL continues to get Metal.

ld-kerley · 2026-05-18T21:20:06Z

-    -->
-    <input name="enableReferenceQuality" type="boolean" value="false" />
+    <!-- List of document base names to exclude from render tests -->
+    <input name="renderTestExcludeFiles" type="string" value="standard_surface_look_brass_tiled.mtlx,standard_surface_look_wood_tiled.mtlx,standard_surface_chess_set.mtlx" />


why are these files being excluded - would be good to include a comment explaining why - so we don't change this in the future without understanding the thought process here.

Good point, and done!

kwokcb

Talked with Jonathan offline about requirements.txt. Rest is good enough to go for this initial change

hybridherbst · 2026-05-19T17:28:37Z

Is there a place where I can look at the rendered images already? (I couldn't find it)

jstone-lucasfilm · 2026-05-19T18:12:39Z

@hybridherbst GitHub has a size limit for files posted in comments, so I'll post it in the Slack thread for today's TSC session. Going forward, I'd love to post the HTML directly as an ASWF-hosted site, which would work around this issue in a compelling way.

kwokcb · 2026-05-19T18:36:42Z

The metal images in resources are packaged as part of ci. I think you'll also get the osl images now. It can be downloaded, though I think with this pr you don't get the comparison html output. Guess when an aswf repo is available the results can automated to be put there along with preview html or markdown.

jstone-lucasfilm · 2026-05-19T18:38:50Z

@kwokcb The generated artifact includes both HTML and PDF versions, so you can choose which you'd like to view. Once this PR is merged, we should see these new artifacts generated in every nightly build, but for now they're only in the fork of MaterialX associated with the in-progress PR.

kwokcb · 2026-05-19T18:43:16Z

That's great. Should be pretty trivial to automate grabbing artifacts.

@jstone-lucasfilm

* Improve handling of top-level inputs in Graph Editor (AcademySoftwareFoundation#2830) - Fix setting of interface names on connection - Copies logic from commit: [PR](AcademySoftwareFoundation#2785) - This is a general logic fix. AcademySoftwareFoundation@09f66bb - Fix connection renaming setting on input rename. Was not considering nodegraph to upstream connections * Improve build configuration in GitHub CI (AcademySoftwareFoundation#2861) This changelist improves the build configuration in GitHub CI, reducing duplication across the build matrix and adjusting parallelism per platform. The following specific changes are included: - Consolidate extended build configuration as a local `extended_cmake_config` field on each matrix row, reducing the CMake Generate step to a single call. - Adjust build parallelism per platform through the CMAKE_BUILD_PARALLEL_LEVEL environment variable, defaulting to 4 and reduced to 1 on Windows, as the MSVC `/MP` flag already handles file-level parallelism within each project. - Simplify the MacOS rendering setup to setting a debug flag in extended builds, as the `MTL_HARDWARE_RENDERING` and `LIBGL_ALWAYS_SOFTWARE` overrides are not actually supported in Metal rendering. * Update changelog for latest work (AcademySoftwareFoundation#2862) * Omit `specular_weight` from metal edge tint in OpenPBR (AcademySoftwareFoundation#2863) This changelist removes `specular_weight` from the computation of metal edge tint in OpenPBR Surface, aligning the behavior of this shading model with a [proposed fix](AcademySoftwareFoundation/OpenPBR#240) for OpenPBR 1.2. As described in the proposed fix, the edge-tint color for the `generalized_schlick_bsdf` should not be multiplied by `specular_weight`, as the whole lobe is multiplied by `specular_weight` as well. * Update OpenPBR to v1.1.1 (AcademySoftwareFoundation#2867) This changelist updates the version string of OpenPBR Surface to `1.1.1`, aligning the MaterialX project with the latest release of OpenPBR at https://github.com/AcademySoftwareFoundation/OpenPBR/releases/tag/v1.1.1. * Update changelog for latest work (AcademySoftwareFoundation#2868) * Fix crash on exit with a debug Python (AcademySoftwareFoundation#2866) Under the hood (in both before and after code), this statement is adding the Exception instance as an attribute to the module. Other examples found using the pattern, suggesting the static variable scope was not needed: - py::register_exception<mx::ExceptionOrphanedElement>(mod, "ExceptionOrphanedElement"); - py::register_exception<mx::ExceptionFoundCycle>(mod, "ExceptionFoundCycle"); - py::register_exception<mx::ExceptionParseError>(mod, "ExceptionParseError"); - py::register_exception<mx::ExceptionFileMissing>(mod, "ExceptionFileMissing"); Fixes AcademySoftwareFoundation#2749 * Unify environment light texture handling in MaterialXRenderMsl (AcademySoftwareFoundation#2870) This PR seeks to address AcademySoftwareFoundation#2851. The core issue is that the Metal rendering code wasn't honoring the indirect lighting property of the light handler. However, changing the logic to match that of the implementation in `bindLighting()` in [GlslProgram](https://github.com/AcademySoftwareFoundation/MaterialX/blob/d69fcb10283f0bbc5f17415c33a6f2e6b63622ad/source/MaterialXRenderGlsl/GlslProgram.cpp#L585-L600) isn't quite enough. There were actually two independent paths for binding IBL textures in the Metal implementation, one in `bindLighting()` and one in the lower-level `bindTextures()`. This change unifies those two paths into a single path relying on the _explicit bound texture_ mechanism currently used for shadow mapping. * Add specification proposal for maxcomponent and mincomponent nodes (AcademySoftwareFoundation#2876) ## Summary Add specification proposal for `maxcomponent` and `mincomponent` nodes to the Math Nodes section of the Specification Proposals document. Closes AcademySoftwareFoundation#2802 ## Description Per the discussion in AcademySoftwareFoundation#2802 with @jstone-lucasfilm : - These nodes support **all vectorN and colorN types** (`vector2`, `vector3`, `vector4`, `color3`, `color4`) - Output type is **float** The proposal format follows existing nodes such as `magnitude` and `dotproduct` in the Standard Nodes document. ### Use Cases As mentioned in the issue, two places in the MaterialX data libraries currently use verbose 5-node patterns (3 `extract` + 2 `max`/`min`) that these nodes would simplify to a single node: 1. **Sheen intensity for glTF PBR** (`libraries/bxdf/gltf_pbr.mtlx`) — uses `maxcomponent` pattern 2. **Absorption coefficient for OpenPBR Surface** (`libraries/bxdf/open_pbr_surface.mtlx`) — uses `mincomponent` pattern ### Scope This PR addresses the specification proposal only. I can work on the follow-up implementation via graph definitions as a separate PR once the proposal is reviewed and merged. * Refactor runRenderer to use structured types (AcademySoftwareFoundation#2869) Replace the 10-parameter runRenderer signature with RenderSession, RenderItem, and RenderProfileResult value types. Each call now returns isolated profiling data that the caller accumulates. Test run is now decoupled, so in future, we would be able to introduce some parallelism in these tests if needed. Minor fixes: - correct ScopedTimer scoping in validate(), - fix a copy-paste timer name in the Slang renderer. * Stabilize flake `id` across floating-point precisions (AcademySoftwareFoundation#2877) This changelist reduces the scale factor for flake `id` from `INT32_MAX` to `2^24 - 1`, providing a stronger guarantee of consistency between 64-bit and 32-bit shading environments. * Fix uninitialized member variable in MetalState (AcademySoftwareFoundation#2884) This PR seeks to address issue AcademySoftwareFoundation#1518. I believe the first part of this issue to be obsolete. The CMake targets have changed substantially since the issue was reported, and I was able to build with Xcode 12.4 on macOS Catalina 10.15.8 without errors. The second part of the issue is still relevant. When compiled on a system with a macOS 11+ SDK but running on an OS version prior to macOS 11, the `supportsTiledPipeline` member variable is not initialized by the constructor or the `initialize()` method, and can hold an invalid value. This doesn't cause a crash because of further runtime checks in `initLinearToSRGBKernel()`, but it does raise a runtime issue when compiled with UBSAN. These changes ensure that the `supportsTiledPipeline` variable is always initialized, regardless of SDK version or OS version. Tested on macOS Catalina 10.15.8 with Xcode 12.4 and macOS Tahoe 26.4.1 with Xcode 26.4.1. * Fix tiling/scaling order in OSL hextiling to match GLSL (AcademySoftwareFoundation#2888) This fix addresses the bug outlined here: AcademySoftwareFoundation#2885 * Use `windows-2022` for VS2022 in GitHub CI (AcademySoftwareFoundation#2907) This changelist updates GitHub CI to use `windows-2022` consistently for VS2022 builds, as an upcoming change to GitHub Actions will replace `windows-2025` with a VS2026-focused environment. * Fix incorrect transpose in Metal inverse world matrices (AcademySoftwareFoundation#2904) The world inverse matrix uniforms in metal are incorrectly transposed. This removes this incorrect transposes You can tell pretty clearly that this is incorrect because when it sets the WORLD_MATRIX just a few lines above, it doesn't transpose it, so why transpose the inverse? https://github.com/bhouston/MaterialX/blob/fe92050e77f6f64984958abf0461747369c713b4/source/MaterialXRenderMsl/MslPipelineStateObject.mm#L1163 This was found via the fidelity test suite. * Fix edge case behavior of `dielectric_bsdf` in MDL (AcademySoftwareFoundation#2910) Address an issue that was discovered with OpenPBR. The specular lobe was still visible with specular_weight=0 and specular_ior=1. Improved the comment that explains the reasoning for chosing custom_curve over fresnel in the dielectric_bsdf. * Optimize GLSL/OSL `rotate3d` using Rodrigues' rotation formula (AcademySoftwareFoundation#2890) While fixing some issues with the rotate3d for my blender importer, I noticed that we can replace the matrix44 construction for just rotating a vector with Rodrigues' formula: https://en.wikipedia.org/wiki/Rodrigues%27_rotation_formula This PR makes that change. Fidelity test passes with successful results so there was no degradation. * Align OSL implementation of `cellnoise3d` with GLSL (AcademySoftwareFoundation#2906) Prior to this fix cellnoise3d looked different for OSL as compared to Metal/GLSL. After this fix they match. * Fix ND_UsdTransform2D implementation (AcademySoftwareFoundation#2924) Addresses AcademySoftwareFoundation#2901 Reversed the direction of the transformations applied - aligning the MaterialX implementation with the USD implementation. * Fix createValidChildName for Documents with referenced data libraries (AcademySoftwareFoundation#2923) * Fix createValidChildName for Documents with referenced data libraries Document::createValidChildName previously only considered local children, so name generation could produce collisions with elements in a data library attached via setDataLibrary (the reference path), while importLibrary (the copy path) worked correctly. Make Element::createValidChildName virtual and override it in Document to also consult the referenced data library when uniquifying names. Add tests covering both the imported and referenced data library paths, including collisions with library-defined nodedef names. * Make Element::getChild data-library-aware Prior commit fixed Document::createValidChildName by overriding it to also check the attached data library, but left two issues: the override duplicated the base name-uniquification logic (risking drift if the base ever changes), and a latent API inconsistency where Element::getChild did not consult the data library while getChildOfType and getChildrenOfType already did. Push the data-library lookup into Element::getChild itself (mirroring the asA<Document>() + hasDataLibrary() pattern already used by getChildOfType). With getChild now library-aware, the base createValidChildName naturally handles both local and referenced libraries by switching its loop condition from _childMap.count to getChild, so the Document override is removed and createValidChildName no longer needs to be virtual. * Add iridescence support to Standard Surface to glTF PBR translation (AcademySoftwareFoundation#2892) This PR maps the thin_film_thickness and thin_film_IOR to the glTF iridescence, iridescence_ior, and iridescence_thickness outputs. The iridescence weight is derived from the thickness being non-zero, as Standard Surface has no separate iridescence weight input. * Update StbImage dependencies (AcademySoftwareFoundation#2917) There's a known issue where StbImage hangs when loading an invalid HDR nothings/stb#1224 which is used by `ImageHandler.acquireImage()`. Currently Fixed in v2.28. MaterialX is using v2.23 [MaterialXRender/External/StbImage/stb_image.h](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/source/MaterialXRender/External/StbImage/stb_image.h). I've upgraded std_image to latest v2.30 and std_image_write to v1.16 which resolve this. And added a regression test that triggers this StbImage issue that hangs indefinitely if this issue re-occurs * Fix alpha handling in HSV/RGB conversion in GLSL/OSL (AcademySoftwareFoundation#2926) `mx_rgbtohsv` and `xm_hsvtorgb` had hardcoded output alpha set to `1.0`. The alpha channel should forward the preexisting alpha value `_in.a` unchanged. Changes made in - `/libraries/stdlib/genglsl/mx_hsvtorgb_color4.glsl` - `/libraries/stdlib/genglsl/mx_rgbtohsv_color4.glsl` - `/libraries/stdlib/genosl/mx_hsvtorgb_color4.osl` - `/libraries/stdlib/genosl/mx_rgbtohsv_color4.osl` This fixes AcademySoftwareFoundation#2765 * Fix material switching in the MaterialX Web Viewer (AcademySoftwareFoundation#2931) This changelist fixes a regression in the MaterialX Web Viewer, where switching to any example material other than Standard Surface Default would fail to update the rendered material. Since the update to `Element::getChild` in AcademySoftwareFoundation#2923, calling `Element::getDescendant` on a Document with a referenced data library can resolve uniform paths _into_ the library, returning elements such as NodeDef inputs whose parent is not a Node. The Web Viewer's property editor then throws a `TypeError` when calling `getNodeDef` on the NodeDef parent, preventing materials other than Standard Surface Default (which declares all inputs explicitly) from displaying. The fix is to skip descendants whose active source URI differs from that of the working document, ensuring the property editor only processes elements from the content document. * Make mxvalidate autoload std libraries (AcademySoftwareFoundation#2932) Make mxvalidate autoload std libraries * Fix nullptr dereference in MaterialNode (AcademySoftwareFoundation#2927) Fixes AcademySoftwareFoundation#2918 ## Summary - Add `isAGraph()` guard in `MaterialNode::emitFunctionCall` to return early with default output variables when the `surfaceshader` input is bound through a graph interface with no upstream shader node, preventing a null dereference on `ShaderNode::getImplementation()` - Add `isAGraph()` guard in `MaterialNode::addClassification` to skip classification inheritance in the same case ## Test Regression test added by @seang-ilm in the linked branch covering the case where a `<surfacematerial>` is placed inside a `<nodegraph>` whose `surfaceshader` input is bound via `interfacename` to a graph interface input with no upstream node. * Initial render comparison in GitHub CI (AcademySoftwareFoundation#2908) This changelist takes a step toward broader render validation in our GitHub CI, adding an extended job that generates a downloadable HTML/PDF report comparing rasterized (MSL) and ray-traced (OSL) renders of the test suite side-by-side with per-pixel differences, allowing contributors to validate shading updates in their fork without building OSL locally. The following specific changes are included: - Add an extended CI job that builds OSL v1.14.10.0 from source, runs MSL and OSL render tests at reference quality, and uploads an HTML/PDF comparison report as an artifact. - Add the `OpenPBR` and `UsdPreviewSurface` example folders to the render test suite, replacing the less-critical `pbrlib/surfaceshader` folder, and adding a `renderTestExcludeFiles` option to skip individual files. - Tune reference-quality sample counts to fit within the render capabilities and time budget of GitHub CI: rasterization supersample factor 8 -> 2, OSL lit -aa 32 -> 16 (1024 -> 256 spp), OSL unlit -aa 8 -> 2 (64 -> 4 spp). - Centralize reference quality parameters in `getRasterEnvSampleCount` and `getRasterSupersampleFactor` helpers, removing duplicated constants across hardware shading targets. - Replace the `MATERIALX_RENDER_MSL_ONLY` flag with `MATERIALX_TEST_RENDER_GLSL` for clarity, and replace the `enableReferenceQuality` test flag with a `MATERIALX_TEST_REFERENCE_QUALITY` build option. As a logical next step, we might consider publishing the HTML artifact as a MaterialX Fidelity Suite (in the spirit of https://github.com/bhouston/material-fidelity), allowing any member of the community to view the current state of MaterialX render parity at a glance. * Fix translation of semi-transmissive Standard Surface materials to glTF PBR (AcademySoftwareFoundation#2912) This PR address translation of semi transmissive standard surface materials to gltf_pbr. It closes AcademySoftwareFoundation#2898. A mix node has been added taking the transmission weight into account. The weight have been square as it better matches the final result. The translation is not perfect, the base color will be more influence by either **transmission color** (if **transmission_depth**=0) or white color, when transmission weight approaches 1. It would be nice if its more correct, and I would love some input from anyone with more knowledge about standard surface and **gltf_pbr** how to mix it to get a better result. For anyone reconstructing this issue, note that **attenuation color** in **gltf_pbr** is not implemented, so use white **transmission color**/**attenuation color** when comparing the materials. * Finalize changelog for 1.39.5 (AcademySoftwareFoundation#2945) --------- Co-authored-by: Bernard Kwok <kwokcb@gmail.com> Co-authored-by: Jonathan Stone <jstone@lucasfilm.com> Co-authored-by: Mark Final <31315860+foundry-markf@users.noreply.github.com> Co-authored-by: Warren Moore <39937547+warrenm@users.noreply.github.com> Co-authored-by: Chinmay <chinmay.cc.06@gmail.com> Co-authored-by: Ashwin Bhat <1727158+ashwinbhat@users.noreply.github.com> Co-authored-by: Ben Houston <ben@ben3d.ca> Co-authored-by: Ben Houston <neuralsoft@gmail.com> Co-authored-by: krohmerNV <42233792+krohmerNV@users.noreply.github.com> Co-authored-by: Lee Kerley <154285602+ld-kerley@users.noreply.github.com> Co-authored-by: Ben Beilharz <b@ben.graphics> Co-authored-by: seang-ilm <sgilligan@ilm.com> Co-authored-by: Payton Gilbertson <45208074+paytonGilbertson@users.noreply.github.com> Co-authored-by: zychen8 <152906171+zychen8@users.noreply.github.com> Co-authored-by: Suriya D Murthy <surya.dakshina@gmail.com> Co-authored-by: Johan Bowald <johan.bowald1@inter.ikea.com> Co-authored-by: Ashwin Bhat <ashwin.bhat@autodesk.com>

jstone-lucasfilm requested review from kwokcb, lgritz and niklasharrysson May 10, 2026 22:41

kwokcb reviewed May 11, 2026

View reviewed changes

jstone-lucasfilm added 2 commits May 11, 2026 15:49

Merge branch 'main' into dev_render_comparison_ci

aeccbbb

Merge branch 'main' into dev_render_comparison_ci

b24152b

ld-kerley reviewed May 18, 2026

View reviewed changes

Add comment for excluded materials

8a55e2a

kwokcb approved these changes May 19, 2026

View reviewed changes

jstone-lucasfilm added 2 commits May 19, 2026 11:53

Move Pillow to requirements.txt

0947512

Rename render_captures to tool_render_captures

0a94077

jstone-lucasfilm merged commit ed2235c into AcademySoftwareFoundation:main May 20, 2026
36 checks passed

jstone-lucasfilm deleted the dev_render_comparison_ci branch May 20, 2026 03:05

Conversation

jstone-lucasfilm commented May 10, 2026

Uh oh!

kwokcb left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jstone-lucasfilm commented May 11, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kwokcb left a comment

Choose a reason for hiding this comment

Uh oh!

hybridherbst commented May 19, 2026

Uh oh!

jstone-lucasfilm commented May 19, 2026

Uh oh!

kwokcb commented May 19, 2026

Uh oh!

jstone-lucasfilm commented May 19, 2026

Uh oh!

kwokcb commented May 19, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!