The current OCIO integration/proposal was not acceptable that uses OCIO as a code inserter into MaterialX.
It is preferred to encapsulate OCIO into a transform node.
The changes to OCIO are being split up such that
The base changes worth keeping can be found here:
https://github.com/kwokcb/MaterialX/pull/3. This mostly just does some isolation so that color transform node addition is handled by the CMS.
The proposed next step would be to create the transform node definition and update the existing non-OCIO implementations (the default set) to use the new definition. Code gen would be generalized to create have a generic color transform Shader node which would insert different implementations based on input and render colorspace.
OCIO can be considered as a node implementation provider.
Removing OCIO for now to better align with main.
Also remove Look::append and Document::mergeLooks API as it is not required.
hodoulp
commented
2 years ago
The current OCIO integration/proposal was not acceptable that uses OCIO as a code inserter into MaterialX. It is preferred to encapsulate OCIO into a transform node. The changes to OCIO are being split up such that
The base changes worth keeping can be found here: https://github.com/kwokcb/MaterialX/pull/3. This mostly just does some isolation so that color transform node addition is handled by the CMS.
The proposed next step would be to create the transform node definition and update the existing non-OCIO implementations (the default set) to use the new definition. Code gen would be generalized to create have a generic color transform Shader node which would insert different implementations based on input and render colorspace.
OCIO can be considered as a node implementation provider.
Removing OCIO for now to better align with main. Also remove Look::append and Document::mergeLooks API as it is not required.