Redshift/Subsance ACES Workflow Limitations in Maya

Discussions - Using ACES
1

Hi

My first post on this amazing website resource. I am currently trying to confirm correct workflow between Substance and Redshift and would appreciate some help in that regard.

A big issue stems from Redshift currently not supporting ACES color rules within Maya. If I load ACES OCIO config through Maya’s color management, Redshift render viewer returns an error stating that it does not recognize any of the current rules as specified by the config in the file nodes of textures.

As such, I am looking around alternative workflows to avoid the error, and ensure Maya is behaving appropriately with regards to a correct ACES workflow.

I would appreciate if anyone could have a a look over the below workflow I am using, and let let me know what is right and what is perhaps wrong, that would be super helpful, as I want to be sure everything is set up correctly. The info has been gleaned from multiple resources online into what I think should work, but I may have missed something:

1. Maya Color Management
I set up Maya Color Management with rendering space = ACEScg. I do not load the aces ocio config file so that I avoid non-managed file texture color rules in (so I get Maya’s default color rules in file nodes and avoid any error feedback - I have read this still renders in the same ACEScg colorspace, regardless of the ocio config file being loaded…). I set the view transform in color management to the required setting - in this case rec 709 (not rec709(aces), which is not availble since I don’t have the ocio config loaded). I set the input color space to Raw since our textures will be pre-converted into ACEScg using a batch process after being saved from Substance. See diagram 1 below.

2. Redshift Render Viewer
In Redshift render viewer under Color Management, I set the display mode to OCIO, load the aces ocio config file and set the view transform to Rec 709 (ACES). I am now viewing the ACES scene-linear renders with a rec709 view transform. Diagram 2.

3. Textures
We are outputting texture from Substance. In substance, we are using an ACES LUT node to simulate an ACES workflow, which is currently unavailble in Substance. So all textures are saved out in either sRGB or linear and pre-converted into ACEScg color space. (currently, we doing our texture pre-conversion tests from Nuke but plan to batch-convert). The file nodes in Maya are then set to Raw since we don’t want it doing anything to the textures as they are already saved in ACEScg colour rule.

  1. Renders then appear accurate to expected output, and for all intents and purposes, seem good. Having done some tests, this is a surefire way that I can meet the same look between Nuke and Redshift render viewers (when comparing solid colours created in an ACEScg environment in Nuke, and trying to carry the texture across into Maya) and also with outputs from Substance in ACEScg.

However I am still concerned something may not be quite right, and worry the output is not 100% correct.
Please let me know if anything here seems of. I want to be sure that I am rendering and viewing the work-space correctly and achieving the benefits ACES. I’ve also worked with Arnold - which fully respects the ACES view transforms and makes things a lot easier! Redshift just limits the use of the automatic transformations of textures, and identifying the correct workflow is essential for me. I have tried to source answers through the Redshift forums, but the feedback is a little convoluted.

Thanks in advance!! Screen grabs below.

Craig

diagram1_colMan|690x253 diagram2_RedshiftRV

1 Like
2

Thanks Craig for your first post, and welcome!

Steve T
ACESCentral Admin

3

Hi Craig,

It sounds like you don’t have Maya configured to use ACES in the Maya viewport. I would expect that it looks totally wrong given what you posted, but maybe you don’t care since you are using the Redshift render view? Do you still get errors from Redshift if you set the texture node color space to “Raw” or “ACEScg” and check “Ignore Color Space File Rules”?

Doug Walker
Autodesk

4

Hi doug_walker

Thanks for your feedback.

I’ve checked your recommendation and I can confirm that yes, Redshift does not report any errors and ignoring the color space file rules works fine. Thanks for the note!

Craig

5

hi craig,

my workflow on avoiding this errors in redshift, is by modifying the config file. i created a “Raw” and a “sRGB” IDT color space (just by copy-paste existing and renamed them), so redshift can have some right names to work with…

another thing to be aware is that using such things as light color temperatures or physical sky still compute in srgb color space…and need some matrix transforms to bring them to acescg…

6

“another thing to be aware is that using such things as light color temperatures or physical sky still compute in srgb color space…and need some matrix transforms to bring them to acescg…”

I know this thread is a bit old, but I was wondering what the method is for bring color temo and the sky into acescg.

7

depends on your renderer and dcc you are in…
a matrix transform expression to the color input…

8

Hello,
For Redshift I don’t think that there is other option than using OSL shaders. (Official repo available here:
GitHub - redshift3d/RedshiftOSLShaders)
Having a quick look at it I don’t think the ACES output of the blackbody one is correct as the value is computed before and converted after. (I don’t know what colorspace OSL use for the blackbody() function)

9

yes i think you have to override redshifts temperature option and using your own algorithm to the color inputs…
OSL in redshift is an option. or maybe maya nodes…
here is a python function to convert kelvin to rgb…

concerning physical sky, there is a maya node on redshift forum to convert from srgb (or with a matrix) to acescg, which can be plugged to the physical sky output node. (or using the osl example from above)

10

Thanks for sharing this code but this looks very confusing to me. “RGB” means nothing alone so what is he converting the Kelvin to ?
Furthermore the code defined some hard clamps like you cannot enter temperature inferiors to 1000K and the output expressed in 8bit notation is also clamped.

I also wrote a snippet but it is using the colour-science library (so it will not explain the maths behind it but only get you a result):