Using ACES with VRAY, MAYA and Substance Painter (First time)

Hi all, I’m a student currently and am trying to understand exactly how to use ACES for my color space in CG. I understand WHY I would want to use it but the technical part is getting me in a couple areas. I have gained great insight through Christophe Brejon’s posts and online book but I’m still wrapping my head around the whole thing.

First off, I use Vray but it DOES NOT allow rendering in actual ACEScg as far as I know. This topic has come up in other posts for similar render engines like Redshift and Octane but the “solution” is really just to use a LUT in the VFB after rendering. So here is my first question. Do I have to CONVERT all my textures to ACEScg in NUKE before bringing into MAYA or do I NOT CONVERT because the rendering will be done in linear sRGB EXR anyways so it won’t matter. I have seen some posts on here discussing different workflows and some were saying that they would render in sRGB EXR (basically do everything the same way they used to work before aces, and then convert the render to ACEScg in NUKE to do any compositing. I understand that Arnold works with ACES fully but I don’t really want to learn a different render engine…
Next, from what I found, it seems like most people do their color grading in Resolve. What format should you export out of NUKE then to go to the color grading stage. Can I do the grading in NUKE? just a thought to save a step. Anyway, if my final goal is to display my work on the internet or sRGB, how should I convert the ACEScg (or whatever format is used to grade…Ive heard of ACEScc but have no idea what the difference is) to be seen back correctly in sRGB?

Here’s another question I had. Is sRGB and Rec-709 virtually interchangeable? I ask this because in this post by Christophe Brejon, he described a process for making a LUT to be used in Substance painter.


EDIT: I just found this ACES workflow by Jose that uses two filters and a LUT that supposedly converts my textures to ACEScg colorspace. https://gumroad.com/l/ZsGoG
So my question is does this hold up after exporting from substance? So I don’t need to preconvert textures in NUKE anymore before bringing them into MAYA?

It shows an Output-Rec709 (my monitor can display either 709 or sRGB but does it matter which one I use?) Thanks for any help in advance and sorry for the long post. I’m primarily self taught and just need some guidance.

Sky Waters

I saw your thread in the mail bulletin, surprised no one answered yet.

What you actually need is feed ACEScg textures and apply an ACES sRGB viewer transform. That’s basically rendering in ACES.

Arnold for example allows feeding whatever to the renderer, define a color space (IDT) in the texture node so it auto converts to working space (Rendering Space in Preferences) with OCIO. But that’s just a convenience not a need.

Rendering in sRGB and convert to ACEScg for compositing defies the whole premise of ACES, since it’s not only a color space but a pipeline. In such case it wouldn’t be much different than converting to bt.2020.

You can skip the conversion of textures to ACEScg in Nuke when using my filters. The problem is that Substance Painter if I’m not wrong always exports Base Color as Gamma encoded 2.2. You can do two things prelinearize in Substance Painter (add a sRGB to linear filter on top) which is a bit destructive, or load as is in Maya and add a gamma correct node for Base Color with a value of 0.454. I even think you can get away without the gamma node tricking the renderer, set the texture node to gamma 2.2 Rec.709.
I think this is more correct because the mipmapping conversion needs proper linear textures for the resizing algorithm and you are just telling it it’s a 2.2 gamma encoded file in the texture node.
Check both options below.

For grading you need your images to be in log space with a known and manageable dynamic range between 0.0 and 1.0, the ACES log flavour is called ACEScc so convert to that in an ACES pipeline.

Rec.709 and sRGB share color primaries but differ on gamma. This is because the target use of Rec.709 is video where it’s supposed to be viewed on a dim surround.
Regarding which ACESfilm lut to use choose the one that matches the calibration target of your display.

Hope that helped!

Thanks so much for the help.
Now when I import my textures that are already in ACEScg, can I set the color space to RAW so that they aren’t changed in any way?


This workflow I saw on another post and I think it makes sense. [quote=“craigskane, post:1, topic:2515”]
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.
[/quote]
Also, I figured out how to use your filters and they seem to be working. Now, here my question. When working in ACES my colors become more desaturated, which I understand is because of the larger gamut but can/should I re-edit the colors on the textures to get the saturation back that I liked or should I leave it knowing that it’s only because of the change in color space…my textures had correct colors before I applied the ACES workflow.
Next, my monitor is working in sRGB so is it ok that the default OCIO color picker is in Rec.709? In a thread from a VRAY Developer, he answered that if you “set your rendering colour space to ACEScg from Maya’s colour management options, all colour pickers will output ACEScg values”. Correct?
Capture10

Finally, I have a question about the conversion process. When in Substance Painter, should I PRE-CONVERT any sRGB image I am using for the base color to ACEScg?(assuming Im not using your filters)
I know that in NUKE one would use an IDT to correctly view an sRGB image in ACES but in Painter I don’t think there is a way to do that…

Thanks again for all the help!

Yes, I didn’t make a video with only the viewer lut because in my opinion it’s flawed specially on color rendition, it does nothing to your textures and makes you think to be in an ACES pipeline.
In any case there’s only one lut called “ACESFilm 2.0.exr” and it uses sRGB as the intended display output transform.

You have to convert all the textures that contribute to the color component of the material. So Base Color, Light colors, Emission color, SSS Color, HDRI’s, etc even for black, grey, or white color textures because the change on illuminant to D60. RAW is fine as default.

I don’t know the internals of Maya but if a Vray developer said so it would be safe to assume that’s correct and color picker is presented under the Output - Rec.709 ODT which is nice for video oriented programs, in the case of Maya if you calibrated to sRGB you might want to change that to Output - sRGB under config.ocio roles. But for that you need OCIO enabled in Preferences (needed for viewport viewer transform but not for render), otherwise set the Mixing Color Space to Display Space.

No, in Substance Painter there’s no way to convert color spaces as far as I’m concerned, that’s why I made the filters. If you feed preconverted ACEScg maps directly to Substance Painter you still need a viewer transform lut, I made three in the ACESFilm pack depending on display target (sRGB, Rec.709 or P3-D60).

Ok thanks. Can you speak on weather the desaturation is fine once in ACES with your filters. Can or should I change my initial colors to look darker now that they look more washed out? Is the ACES workflow meant to help shape your creative decisions throughout so that it looks good in ACES?

Hello, I thought I might jump in because this topic quite interests me as well. :wink: Especially the Maya part. I’ll let Jose handle the Substance questions. :wink:

I am just curious about this. If you load an ACES OCIO config into Maya, is Vray having issues ? Do you have access to any IDT ? I know for a fact that a famous parisian studio uses ACES and Vray. So there must be some way to make it work I guess.

Since render engines are agnostic, you could totally convert your color textures to ACEScg in Nuke, load them as linear and that would still be considered an ACEScg render with Vray

. You could export as ACEScg as long as your IDT is ACEScg in Resolve. You can totally grade in Nuke on ACEScg renders or (even better) convert with an OCIOColorSpace to ACEScct, do the grading and then convert back to ACEScg. ACEScc and ACEScct are logarithmic formats for grading purposes.
.

You should set your Write node to Output - sRGB or Output - Rec.709 which I like personally more for its softer look.

Hope this helps ! I see that Jose already answered most of your questions anyway. :wink: All the best, Chris

1 Like

Hi, thanks for the response!

To be honest I’m not sure of another way. Online, there was a post by an VRAY developer stating the possible ways of getting ACES working through VRAY. As far as I know this is what it looks like in the VFB.

Ok but if you use Output-Rec.709 do I have to change my monitor to display in that color space throughout the texturing/ entire process?

Also how do I know/ ensure that any lights I use in Maya/ Vray are in the ACEScg color space?

Last from my other post…

I know ideally you would do the Aces workflow from the beginning but still wondering… Also this could be because all my reference images are probably sRGB
Thanks!

Sorry for the late reply. I have investigated a bit further our topics.

  • Use of OCIO nodes (e.g. VRayTexOCIO) for color space conversions is not recommended for performance reasons.
  • There is a couple of posts on the topic : https://forums.chaosgroup.com/forum/v-ray-for-maya-forums/v-ray-for-maya-general/72630-render-colour-primaries
  • You should use an ODT matching your monitor setup. Forget about the Rec.709 softer look (it is actually confusing, sorry about that.)
  • I suppose you load the OCIO config in Maya, for your lights which color picking role are you using ? I know Chaos group has done a pretty good job on Skylight and kelvin temperatures in ACEScg.
  • V-Ray 5 (which beta has been released recently) has a much better OCIO/ACES integration with proper IDTs apparently.

There is a lot of confusion on the desaturation of the textures. You can check this topic for a pretty much complete explanation : Linear-sRGB not behaving as expected.

This part is particularly interesting : The RRT is not really neutral and has some sweeteners that can be annoying depending on the context, i.e. glow modifier, red module and global desaturation.

I hope this makes sense and I am not confusing you more. Sorry for the delay in replying.

Chris

Hi all,

Thanks for this thread. The internal rendering space for the different renderers is a little puzzling.

Chris you mentioned this:

Am i righting in thinking, if all the data we supply to the renderer is in acescg we are essentially rendering in acescg?

It’s probably my lack of understanding of how renderers work but I wondered if you could give a bit more detail when you say render engines are agnostic. The internal calculations don’t take into account a rendering space?

thanks,
Jeremy

Yes, you are right to think that. But I will try to be as accurate as I can so I do NOT mislead you.

From the tests we have made on the Cornell box, this is 100% true. The data (textures in this case) were manually converted to ACEScg and in this specific example, your assumption is correct. We only used one white area light in the render, so it is a pretty simple setup.

But things get more complicated if you use a Physical Skylight or kelvin temperatures in your lights since they are a spectral representation that have been most likely converted to sRGB/Rec.709 primaries.

In most render engines, setting the rendering space to ACEScg is only useful for IDT. So the conversion process"knows" to which gamut convert (most likely ACEScg). Very few render engines have actually developed an ACEScg Physical Sky which could be triggered by the choice of rendering space (or as a separate option). I think the chaos group is ahead of any render rengine on this particular topic.

I know some Maya artists use a 3D Matrix to convert the Physical Sky to ACEScg in the hypershade. But ideally this would be a developer’s task. It really depends on the OCIO integration in the software really.

I hope this makes it clearer for you,

Chris

Hi,

Yes and no! :slight_smile: From a technical standpoint they are, but the result is certainly not!

Cheers,

Thomas

I think this quote from you sums it pretty well :wink:

On a strictly technical point of view, rendering engines are indeed colourspaces agnostic. They just chew through whatever data you throw at them without making any consideration of the colourspace the data is stored into.

However the choice of colourspace and its primaries is critical to achieve a faithful rendering.

Chris

Thanks Chris and Thomas. Really helpful. I had to take a second look at your article Thomas but I’m pretty sure I understand it.

1 Like