2023-06-12

June 12, 2023

Host: Carol Payne

Secretary: Carol Payne

Attendees:

Apologies:

OCIO TSC Meeting Notes

Virtual town hall scheduled for Weds Aug 2 @ 8am PT. Will be recorded. Let us know if you’d like to present something/participate

For MatX, color transforms and their definitions has been a core aspect from the beginning of the library
Solution so far is to take the ACES 1.2 ocio config colorspaces and generate code for the shader languages
Would prefer to have a solution that doesn’t require staying in sync manually
Possibly some format that OCIO can output, which MatX can ingest and output shader graphs for such that all the GPU shader languages supported in MatX can be used without issue or direct dependency on OCIO
Doug:

The OCIO config file is central to all of this. It’s been really successful to have a compact user-defined document to exact describe what colorspaces exist is and how they are named and then how they are defined (what exactly are the transforms)
Ideal world: one which an OCIO config could always be used in conjunction with a MaterialX document
What are the roadblockers to this? Would like to understand this first
Second, what is this set of colorspaces? How are they prioritized and tracked currently?
As long as there are different groups (especially in OS for VFX/Anim and in the ASWF) there will be mismatches

Jonathan: we want to stop maintaining colorspaces in MatX. For sure.
MatX doesn’t just support DCCs - it supports lightweight libraries just as three.js and Apple’s new VisionOS. Big selling point is that it is incredibly lightweight and therefore dependencies on OCIO is a non-starter
Kevin: our company doesn’t have a single OCIO config that is completely standard. Concern is two different modes of operating: pre-canned minimalistic config that is static and default, and custom support for any OCIO config out there
Jonathan:

Definitely they are separate. Start with the static set of common, and go from there.

Carol: so if a user doesn’t have access to OCIO, they are “stuck” with the set of colorspaces as defined in the version of MatX that they are using.
Doug: is there an API on the materialX side that can do this?
Jonathan: there would need to be a new API needed to convert the format from OCIO to MatX Graphs
Kevin: so we’re really talking about a small bridging library that depends on both OCIO and MatX
Carol: what are the explicit reasons MatX can’t depend on OCIO?
Jonathan: OCIO doesn’t support all the shading languages that MatX does currently.
Jonathan: also, versions come into play - and OS integrations, etc
Also, some DCCs use non-public shading languages (such as Houdini)
Kevin: we’d need to figure out what MatX can/should support vs. what OCIO supports, and how to make sure the user can get what they need.
Jonathan: we can only support what shading languages universally support

Doug: we are also looking at OCIO in a web browser possibilities independently of MatX - been speaking on that for awhile. And a thing we will likely do regardless
Jonathan: if OCIO was a javascript library, that would definitely change the calculus. It would need to be well integrated and supported, but it would definitely be more of an option.
Carol: we want to be the best partner to the other projects in the ecosystem and prioritize our roadmap to suit those needs.

Disallow 1D Textures
Not merged yet because it will be a 2.3 feature, had been focusing on getting one more 2.2.x release out
Doug wants Patrick’s input on the changes to the GPU API, but will definitely be out for 2.3
Will follow up with Eric Renaud-Houde separately