Chaos Corona Forum
Chaos Corona for 3ds Max => [Max] General Discussion => Topic started by: ProxyFuel on 2025-08-06, 10:21:15
-
Is there an official or recommended workflow for using the new Color Management system in 3ds Max 2025+ with Corona Renderer 13? I've looked around and find answers that conflict.
So far, I’ve stuck with the legacy Gamma 2.2 setup because it gives me predictable results. But I know it's time to get familiar with the newer ACES/OCIO-based color management and how it integrates across the viewport, materials, rendering, and saving.
Out of the box, I often run into issues where what I see in the viewport doesn’t match the render, and both differ from the saved image. I’m trying to establish a consistent, predictable workflow—ideally where what I see is what I get when saving a standard JPG (let’s leave 32-bit linear workflows aside for now).
Example of the issue:
Using the legacy Gamma 2.2 workflow:
I import a JPG street photo—looks good in the viewport.
It renders correctly, matches the original.
Saved output is accurate.
Using the new Color Management workflow:
The same image looks washed out in the viewport.
The render comes out darker than the original.
If I tweak the color management settings to fix the background, then my 3D elements look wrong—as if they no longer match the photo.
This inconsistency is making it hard to transition. Has anyone found a solid setup or workflow to ensure predictable results from viewport → render → saved image, especially with standard 8-bit JPGs?
-
The plot thickens...
I’ve discovered something odd: if I add a JPG as a background using a Tonemap Control node, disable ACES in the tone mapping settings, and hit render — everything looks correct.
But here's the catch:
As soon as I hit Stop and render again, the image goes dark. It won’t return to the correct look until I restart 3ds Max. Then it behaves — but only for the first render. After that, same issue.
This happens consistently across multiple machines, all running the same version of Max and Corona. I’ve tried different scenes and different JPGs — same result every time.
Right now, I can’t get things to render correctly with the new color management system. Anyone else seeing this?
-
The first question is - do you need to work in a color managed environment? If the answer is "I dont know" then you probably don't.
If you are working in a pipeline that is color managed then its useful since everything can be unified/delivered as expected. You will then need to understand how to use the transforms and workflow - or learn it from/with the studio that requires this (usually the fastest way since they have a workflow they can teach you - which gives you a way to connect the dots).
I’ve discovered something odd: if I add a JPG as a background using a Tonemap Control node, disable ACES in the tone mapping settings, and hit render — everything looks correct.
The ACES tone-mapper is just curve basically, its not recommended to use this in conjunction with color management.
Is there an official or recommended workflow for using the new Color Management system in 3ds Max 2025+ with Corona Renderer 13? I've looked around and find answers that conflict.
Try reading these first.
https://help.autodesk.com/view/3DSMAX/2026/ENU/?guid=GUID-DA8CE2F5-1400-45A9-BFCF-A4A8968175CF
https://help.autodesk.com/view/3DSMAX/2026/ENU/?guid=GUID-9FDA8D1F-1285-49F4-B025-D505D40FD24D
https://help.autodesk.com/view/3DSMAX/2026/ENU/?guid=GUID-2440635A-3E84-4215-AB09-9B3F4AB772D4
If you want to understand it more thoroughly at some point, test things for yourself etc read this by Chris:
https://chrisbrejon.com/cg-cinematography/chapter-1-5-academy-color-encoding-system-aces/
Example from Chris' page of a simplified view of the workflow:
(https://i.ibb.co/Q7bKZygs/aces.png) (https://ibb.co/V0jqdf1X)
-
I second what James said:
If you need the ACES workflow - use it.
If you don't - use the legacy gamma 2.2 workflow.
If you like the ACES "look", but you don't want to deal with all the color management stuff - use the legacy gamma 2.2 workflow and enable the ACES OT operator in the VFB Post tab.
-
Thank you for the answers. As I expected, if there’s no explicit need for this feature, then it’s not necessary to use it.
My main concern is more about why this isn't an advanced option that can be enabled and configured by those who actually need it—instead of being a default setting applied to everyone out of the box.
I’ve been using Corona since the beta days and have always appreciated how easy it is to use while still delivering great results. But small things like this can be frustrating. I can imagine how many new users might struggle to understand why their renders look off or incorrect.
I realize this is more of a 3ds Max issue than a Corona one, but I still think it's worth bringing up
-
My main concern is more about why this isn't an advanced option that can be enabled and configured by those who actually need it—instead of being a default setting applied to everyone out of the box.
Odd, in max2024 the default option is Gamma Workflow, has this changed in 2025?
I’ve been using Corona since the beta days and have always appreciated how easy it is to use while still delivering great results. But small things like this can be frustrating. I can imagine how many new users might struggle to understand why their renders look off or incorrect.
Heh, reminds me of the fun we had back in 2009 when we switched to the Gamma Workflow. People have been requesting color management in 3dsmax for a long while, if you need to streamline your pipeline then ocio is a useful wrapper for and end to end workflow. This way the artist doesnt have to think about LUTs, transforms, color spaces, rules etc the project lead can set this up and the artists can just work - in theory.
If you dont need this then you can just go about your business as usual - the intent was to reduce frustration from my understanding.
-
Yep, ACES/OCIO is the default in Max 2025 and newer.
-
We've found AGX to be a better solution than ACES anyway. So for us it was a case in 2026 of having to switch back to legacy Gamma 2.2 workflow so we continue using AGX and having consistency with old projects. It's a shame AGX is more complex/cumbersome to work with, but the results are worth it.
-
Yep, ACES/OCIO is the default in Max 2025 and newer.
Ah k.
So for us it was a case in 2026 of having to switch back to legacy Gamma 2.2 workflow so we continue using AGX and having consistency with old projects.
Im confused, you are using the Gamma Workflow with AGX? Have you tried @piotrus3333 upload of the ocio for Agx (by Troy Sobotka) ?
https://forums.autodesk.com/t5/3ds-max-color-management-forum/alternative-ocio-config-for-max-and-maya-because-there-is-more/m-p/13192991#M27
-
Yep, ACES/OCIO is the default in Max 2025 and newer.
Ah k.
So for us it was a case in 2026 of having to switch back to legacy Gamma 2.2 workflow so we continue using AGX and having consistency with old projects.
Im confused, you are using the Gamma Workflow with AGX? Have you tried @piotrus3333 upload of the ocio for Agx (by Troy Sobotka) ?
https://forums.autodesk.com/t5/3ds-max-color-management-forum/alternative-ocio-config-for-max-and-maya-because-there-is-more/m-p/13192991#M27
not so far - just doing it the original old-school way with manually-loaded LUTS on cams. this looks great, cheers!
-
not so far - just doing it the original old-school way with manually-loaded LUTS on cams.
Curious, if you are just using an LUT how is it more complex/cumbersome?
this looks great, cheers!
Dont thank me yet lol, using an LUT is the easiest method. @piotrus3333 Would know more than me about this stuff, I was just curious if you were using Agx through ocio.
-
Yes you're right, it might not actually be *more* cumbersome, but I guess our main issue at the moment is that we can't access the coronacamera's tonemapoverride via scripting, where we'd love to make a simple button script that will load in the 2 x LUTs required to get it working on the selected camera(s). We were hoping that had changed in corona 12/13 but I don't believe it has.
Can a Corona dev chime in on that maybe?
-
we'd love to make a simple button script that will load in the 2 x LUTs required to get it working on the selected camera(s).
If I understand you correctly you want to combine LUTs? If so have you heard of 3D LUT Creator (https://3dlutcreator.com/)? It might be worth looking into since its pretty powerful, among other features you can do your tonemapping then put both the original image and final image in then create a LUT based on the changed values.
I wrote a short article on it here (https://jamesvella.net/2019/02/18/2019-2-18-3dlut-creator-not-just-for-photographers/) if you are interested in a quick run down. Unless ive totally misinterpreted your post
edit:
A secondary option is stack the LUTs in vray, save out a small image, then you can use the command line ocio tools to build a .cube (LUT) for the current setup. GPT could build it for you but you need to test it and when its good you have a solid combined LUT moving forward. I did this recently for a client who needed all the layers in vray vfb as an LUT, worked out well.
-
Yes you're right, it might not actually be *more* cumbersome, but I guess our main issue at the moment is that we can't access the coronacamera's tonemapoverride via scripting, where we'd love to make a simple button script that will load in the 2 x LUTs required to get it working on the selected camera(s). We were hoping that had changed in corona 12/13 but I don't believe it has.
Can a Corona dev chime in on that maybe?
Not a dev, but I don't think this is currently possible. I have logged a feature request on your behalf at https://chaoscorona.ideas.aha.io/ideas/CMAX-I-223
(as usual, it won't be visible for some time, until Tom accepts it)
-
Yes you're right, it might not actually be *more* cumbersome, but I guess our main issue at the moment is that we can't access the coronacamera's tonemapoverride via scripting, where we'd love to make a simple button script that will load in the 2 x LUTs required to get it working on the selected camera(s). We were hoping that had changed in corona 12/13 but I don't believe it has.
Can a Corona dev chime in on that maybe?
Not a dev, but I don't think this is currently possible. I have logged a feature request on your behalf at https://chaoscorona.ideas.aha.io/ideas/CMAX-I-223
(as usual, it won't be visible for some time, until Tom accepts it)
Cheers, thanks for doing that. Just for the sake of clarity, we're just looking for a really quick and simple way to load in custom ToneMapping setups, mostly just to get the AGX workflow going (which requires two LUTs to be loaded and other things to be present in the stack). But currently this isn't accessible via scripting. That's the goal - just a dead simple script button we can hit to whack a TM stack onto selected cams.
-
It's visible for voting :)
-
Interested to hear what other TM setups are you using (since you've mentioned that slapping AGX TM is only necessary for certain cameras)?
I'm also a big fan of 2 LUT AgX tonemapping setup that was shared in this forum, and I believe combined with Tone Curve it pretty much works in any kind of scenario (at least visually speaking). I also hear that some people use ACES / AgX interchangeably, depending on lighting situation, so I'm always very eager to know what other TM setups are people using out there (of course, if it's not a company secret or something).
And I guess to relate to the thread, I would also assume that most studios / artists who mainly produce archviz don't need to mess with color management settings besides simply keeping their monitors calibrated and using those profiles correctly.
-
Cheers, thanks for doing that. Just for the sake of clarity, we're just looking for a really quick and simple way to load in custom ToneMapping setups, mostly just to get the AGX workflow going (which requires two LUTs to be loaded and other things to be present in the stack). But currently this isn't accessible via scripting. That's the goal - just a dead simple script button we can hit to whack a TM stack onto selected cams.
Hi Alex,
Given that you have saved the custom tone mapping to a file (btw it is possible since Corona 12 via maxscript by:CoronaRenderer.CoronaFp.savePostSettings <filepath> command), you can use this script to load it first to global tonemapping, then copy to selected cameras. This is a quick and simple way, as you mentioned :) Probably the ultimate thing will be a button in toolbar, which adds the two LUTs of yours to selected cameras. For this a bit more complex code is needed.
--Save current global tone mapping, just in case
initColorMap = renderers.current.colormap_pipeline
initColorMapFile = CoronaRenderer.CoronaFp.savePostSettings "path\to\test_post.conf"
--load saved custom config file to global tone mapping
newCoronaMap = CoronaRenderer.CoronaFp.loadPostSettings "path\to\cam_post.conf"
toCopy = renderers.current.colormap_pipeline
--copy to selected CoronaCameras
for cam in selection do (
if classOf cam == CoronaCam then (
cam.colorMappingPipeline = toCopy
cam.colorMappingOverride = true
)
)
just change the paths and it's ready.
Hope this works for you.
-
Cheers! We're going to give this a try.
-
We've managed to get this working, but only when VFB2 is used. Unfortunately not under VFB1 (which is preferred by some of our artists). Just something to be aware of. We really hope to see some good UI changes to VFB2 so we can fully move to it.
-
We are trying to address the biggest issues with the VFB 2 for Corona 14, and we look forward to your feedback once we get that out in a daily build!
-
We've managed to get this working, but only when VFB2 is used. Unfortunately not under VFB1 (which is preferred by some of our artists). Just something to be aware of. We really hope to see some good UI changes to VFB2 so we can fully move to it.
It is the file saving that brings the limitation. Not sure about your workflow, but if you have the desired tone mapping loaded to a single camera (or global tone mapping), it should be very easy to duplicate that to the rest.
-
And I guess to relate to the thread, I would also assume that most studios / artists who mainly produce archviz don't need to mess with color management settings besides simply keeping their monitors calibrated and using those profiles correctly.
it's not about the subject but the delivery technology: most phones nowadays have P3 screens. this means that non colour managed Corona UNDERSTANDS only 67% of colours a small device in your pocket is able to DISPLAY. that does not sound very PBR, does it?
-
And I guess to relate to the thread, I would also assume that most studios / artists who mainly produce archviz don't need to mess with color management settings besides simply keeping their monitors calibrated and using those profiles correctly.
it's not about the subject but the delivery technology: most phones nowadays have P3 screens. this means that non colour managed Corona UNDERSTANDS only 67% of colours a small device in your pocket is able to DISPLAY. that does not sound very PBR, does it?
No it does not and perhaps I assumed wrong.
Please share your opinion and expertise on this matter - since we're living in times where media is consumed on all kinds of screens - should archviz studios bother with color managing their workflow? Again, my knowledge is very limited on this topic but I'm always eager to learn.
-
heh, I was hoping the phone display example will put things into perspective more clearly.
P3 HDR displays will be a new standard at some point. like displays bigger than HD did.
and when displays got bigger we started to render bigger images. same with colours. just a loop of progress - adoption - standard.
if you don’t see the need today - no point in worrying about it. it’s enough to be aware of the progress part.
-
comparison of rec709 vs acescg as rendering spaces for P3 displays.
use P3 capable apple device (apple should be simple and fool proof, I have no idea how android handles icc profiles, if you know what you're doing any P3 display will do)
save images in Files app (to avoid displaying in web browser)
compare.
albedos are samples from Pointers' gamut (80's study for Kodak, measuring most vibrant natural colours)
Pointer's gamut was pretty much a base for rec2020 and acescg colour spaces and it is wider than P3 - so what you see on your iphone is still not "PBR enough".
be mindful of the fact that this test shows only a slice of what wide gamut rendering is able to offer (vibrancy of natural surfaces, presented as low roughness samples lit by fairly muted enviro map) - but it should be fairly representative of what is common within context of archviz.
-
albedos are samples from Pointers' gamut (80's study for Kodak, measuring most vibrant natural colours)
This is a bit late but I see your point. It's also now more relevant than ever as I have purchased an OLED monitor and trying to figure all of this color managed workflow out. And since you made this beautiful comparison - do you mind sharing this test scene? I'm not sure if I know how to set the exact same albedo values and would like to do some of my own tests with different rendering spaces and view transforms, and just have a good scene to test it with.
-
this scene was definitely not rendered in Corona. all I can offer is albedo texture in ACEScg:
https://forums.chaos.com/forum/chaos-common/chaos-common-public/1196875-pointer-s-gamut-in-acescg
file named:
mP_PointersGamut_MaxSaturaton_acescg.zip
-
Amazing, thank you. Should we input this as Raw (or un-tonemapped, not sure which is better) to get the correct results if rendering in Aces color space?
-
Amazing, thank you. Should we input this as Raw (or un-tonemapped, not sure which is better) to get the correct results if rendering in Aces color space?
as acescg.