Feature request: One click ACES scene conversion button please

[Karol.Osinski]

OK so heres my experience with above mentioned plugins/scripts

1.
Aviz AColor Manager
-
works but it makes the render about 4 times longer!!!!! Tried all sorts of material conversion mechanisms it offers. Some crash the scene when it starts rendergin, some take ages to render. Applying more layers on top of it in VFB produces some weird results too.
DONT BUY/DOWNLOAD!!!!

2.
VrayMat Converter
Doest seem to have done the conversion at all, although it was crunching something...no idea whats going on in the background but maps remained unchanged in terms of the setup


I really hate using 3rd party plugins for something that could be done by developers inside vray as a tool especially for major payed release - no offence. Spent almost 100 dollars today for nothing :-/

Is there really nothing you can do about this feature guys???
Wanna convert? Use another plugin tool principle doesnt cut it really.

M

I agree, on the top of being unreliable. You never know for how long those plugins will be supported. They might already not work with Max 2024.
I think Chaos is not putting enough effort to push forward ACES workflow. I am waiting for ACES for Maya's clunky documentation update since few months now.

[atanasbak]

So a simple material with fully saturated red in diffuse, gets converted to V-RayColor node attached to a V-Ray material?
If your tool does that now, congrats!
Just ditch OSL and this could be a viable solution in production

Thanks, this is the problem that we have if we do not use OSL map with complex materials:



The example scenes are attached to the post.

If you convert the color in the input node (as recommended in docs), the result is darker color in diffuse filter.

However we can optimize the tool to apply OSL map only for such complex maps and use V-Ray Bitmap for simple textures in the color slots of a material.

[Karol.Osinski]

^Lele^ Can you please, for god's sake, stop using your technical mumble and ovewordy problem descriptions in order to mask the mistakes that has been done by the company you work for. I get it man, this is the way you are and communicate with others but you gotta consider that most of people on this forum won't even bother to read through your posts. I am a rather technical person and I usually really enjoy reading geeky stuff but c'mon! Wherever I see you around here, all I see is a million words post that doesn't really leave much space for arguing against cuz for the typical user is just overcomplicated. And from what I see you tend to you use it on purpose to just shut up people who have all the rights to complain about the product.


Aces workflow is not explained well enough by Chaos and it is not out of the box, easy solution as the company presents it - IT IS AS SIMPLE AS THAT

We are tired of the endless explanations of WHY something is not working properly. If it doesn't work properly JUST DO NOT INCLUDE IT IN THE PRODUCT.

God damnit, I am really tired of your posts, if there is some "mute" function to not see them I would gladly make use of it.

[Muhammed_Hamed]

As there is no direct way to match an incoming sRGB color rendition (i.e. the way it looks on an sRGB display under LWF conditions.) under ACEScg -that i know of-, this is a show-stopping problem for anyone working under strict directions (a brand, f.e., wanting a specific color exactly represented. Not "prettier", or "more saturated", but exactly as expected.).

Yes, one of the biggest challenges to adapting ACES. Wanting to match a Logo or a brand color is a complicated task
Not possible with ACES ODTs in V-Ray
The user will need to drop the ACES ODTs and do their tonemapping manually, excluding the brand colors/logo with a mask
This is on the academy to fix, there are no answers so far

A second issue about the ACES ODTs is color clamping, when it converts the image from Linear ACEScg to the gamut of the Display Device. It is a big mess
A third issue is hue skews, when over-exposing an ACES EXR, looking at the result through the ACES ODTs.. colors will shift in unpredictable way

Pretty much all issues are related to the ACES Output Transforms, being aware of these should be helpful I think
I still use ACES for my personal projects, I like the filmic look of the ACES ODTs. It is usually my starting point for shading and lighting

I don't think it is necessary to stick to all those rules either, it is art after all

[Muhammed_Hamed]

If it doesn't work properly JUST DO NOT INCLUDE IT IN THE PRODUCT.

Hey Karol,

The color matching issues are on ACES, not specific to V-Ray. All other renderers deal with the same issues I mentioned
There is no definite answer to matching brand colors or a logo, if you wanna use the ACES Output Transforms in the frame buffer. It is just not possible
It is one big hole in the workflow sadly..

The only way around this is to do the tonemapping manually and use a mask for this logo/brand colors

I fixed some things in the docs, it should be better now. Probably not enough details either

[piotrus3333]

Karol.Osinski
we are at ACES 1.3 and you are talking about it as THE standard. too early for that.

technical language? it is essential part of technical discussion.

[^Lele^]

^Lele^ Can you please, for god's sake, stop using your technical mumble and ovewordy problem descriptions in order to mask the mistakes that has been done by the company you work for.

I beg your pardon?

Aces workflow is not explained well enough by Chaos and it is not out of the box, easy solution as the company presents it - IT IS AS SIMPLE AS THAT

We are tired of the endless explanations of WHY something is not working properly. If it doesn't work properly JUST DO NOT INCLUDE IT IN THE PRODUCT.

God damnit, I am really tired of your posts, if there is some "mute" function to not see them I would gladly make use of it.

You can add me to the ignore list.

[Karol.Osinski]

Karol.Osinski
we are at ACES 1.3 and you are talking about it as THE standard. too early for that.

technical language? it is essential part of technical discussion.

Perhaps it is also too early too implement it as a part of an official product then?

By no means I am against technical discussion....it is just that person approach to the users that I just cannot stand anymore (and I am not the first oine who said it at laud), despite all the best intentions he has. Thankfully the ignore feature tricks did the job.

[fixeighted]

To try to be diplomatic about this, in reading your comments Karol.Osinski I had some thoughts...

Everyone on these boards should have, I believe, the right to express themselves in what ever natural (linguistically) way they see fit, so long as thas that does not demean or otherwise
negate others' responses or indeed questions.

It's quite fine to not like or appreciate someone else's opinion or the the way that that opionion was expressed, though to be openly angrily dismissive about someone
else's form of expression is decidedly not cool.

We of course have the option to 'not' respond to a post that so angers us that it creates some frustration, for whatever reason. Not responding in such a case would be the better option.

Just...saying

[^Lele^]

Regardless of unpleasantries, here's a resume' of the issues i see with a "one-click" solution to the ACEScg problem.

a) Currently, Max is not properly color managed (the only option is gamma on/off, or a custom LUT.), so there are unavoidable issues throughout (the material editor, windows, various tools and workflows that break.).
This isn't a matter of opinion, and the limits are fairly self-evident.
Short of writing a V-Max, we'll have to depend, and wait for, any Autodesk development that may or may not happen on the subject.
Converting right now makes an sRGB scene a "locked" ACEScg one, where a ton of color space conversion nodes need to be added in various places (because shaders aren't made up only of directly-plugged bitmaps.).
Any edit has to happen below those nodes, and the result of any such edit is going to be misrepresented throughout max until one renders to our VFB (f.e., any CC, color picking and so on.).
Reverting the scene to non-ACEScg then becomes problematic (whereas it ought to be trivial in an OCIO-managed application.).
Regardless, even if Max was rebuilt from the ground-up and became the better OCIO-managed application on the planet, the inherent complexities of dealing with ACEScg' various IDTs wouldn't disappear, and couldn't be entirely automated (there is no way that i know of to figure out if a texture is ACES-encoded or not.).


b) ACEScg is not LWF, it's merely scene-linear (as it well should, given we do math with it.).
I have delivered movies without linear workflow, and it's truly an unpleasant affair.
This is what i meant when i spoke of matching a specific color or direction: 10% more brightness added to a color isn't going to be 10% more brightness in the render view, but just 10% more brightness as scene-linear values, with the viewed result varying depending on where it sits on the S-Curve embedded in the sRGB ODT.
However this is a personal preference, and if anyone's happy with operations (double this intensity, halve this amount) behaving differently depending on the effect they have on scene brightness, they're well free to work this way.
Fixing this has to come from the Academy itself, as it's non-trivial to remap the wider gamut to an sRGB display device (the primaries' vectors aren't just longer, they are also quite skewed compared to the sRGB ones, making for some devilishly complicated color math.), and surely it's not a mask that's going to save anyone from a non-LWF workflow (the issue is devastating for, f.e., Chaos Scans' workflows.).
The fix may never happen (it could well be impossible to write one such ODT) and at any rate the latest ACEScg specification has gone untouched for 2 years, now.

This is the extent of my worries, unchanged in over a decade of dealing with ACES first, and ACEScg then, under Max.

[piotrus3333]

math works like it should as long as you input ACEScg primaries. it’s sure quite inconvenient in 3dsMax but should be ok in Maya I guess.

[piotrus3333]

Perhaps it is also too early too implement it as a part of an official product then?

there is no reason to complain on being given more options. you got that with VRay as sRGB/ACEScg switch. “one” click. VRay will kindly take care of sun/sky and light temperatures for you. thank you VRay. it also supports ocio configs. nice, thank you VRay. switch in VRayBitmap - thanks! even more convenient. what is missing that you need to use aces? ocio support is enough to use it. VRay went much farther making workflow as smooth as possible.

[PIXELBOX_SRO]

Regardless of unpleasantries, here's a resume' of the issues i see with a "one-click" solution to the ACEScg problem.

a) Currently, Max is not properly color managed (the only option is gamma on/off, or a custom LUT.), so there are unavoidable issues throughout (the material editor, windows, various tools and workflows that break.).
This isn't a matter of opinion, and the limits are fairly self-evident.
Short of writing a V-Max, we'll have to depend, and wait for, any Autodesk development that may or may not happen on the subject.
Converting right now makes an sRGB scene a "locked" ACEScg one, where a ton of color space conversion nodes need to be added in various places (because shaders aren't made up only of directly-plugged bitmaps.).
Any edit has to happen below those nodes, and the result of any such edit is going to be misrepresented throughout max until one renders to our VFB (f.e., any CC, color picking and so on.).
Reverting the scene to non-ACEScg then becomes problematic (whereas it ought to be trivial in an OCIO-managed application.).
Regardless, even if Max was rebuilt from the ground-up and became the better OCIO-managed application on the planet, the inherent complexities of dealing with ACEScg' various IDTs wouldn't disappear, and couldn't be entirely automated (there is no way that i know of to figure out if a texture is ACES-encoded or not.).


b) ACEScg is not LWF, it's merely scene-linear (as it well should, given we do math with it.).
I have delivered movies without linear workflow, and it's truly an unpleasant affair.
This is what i meant when i spoke of matching a specific color or direction: 10% more brightness added to a color isn't going to be 10% more brightness in the render view, but just 10% more brightness as scene-linear values, with the viewed result varying depending on where it sits on the S-Curve embedded in the sRGB ODT.
However this is a personal preference, and if anyone's happy with operations (double this intensity, halve this amount) behaving differently depending on the effect they have on scene brightness, they're well free to work this way.
Fixing this has to come from the Academy itself, as it's non-trivial to remap the wider gamut to an sRGB display device (the primaries' vectors aren't just longer, they are also quite skewed compared to the sRGB ones, making for some devilishly complicated color math.), and surely it's not a mask that's going to save anyone from a non-LWF workflow (the issue is devastating for, f.e., Chaos Scans' workflows.).
The fix may never happen (it could well be impossible to write one such ODT) and at any rate the latest ACEScg specification has gone untouched for 2 years, now.

This is the extent of my worries, unchanged in over a decade of dealing with ACES first, and ACEScg then, under Max.

Lele thanks a lot for this summary.
When i see it like that given all the facts about ACES we will stick to our custom made LUTS for some more time.
If i do a review of what i really dislike about the current workflow its the swithching and renaming.
We already get quite a lot from the tonemapping options in vray and achieve good results.

Thanks
M

[^Lele^]

If i do a review of what i really dislike about the current workflow its the swithching and renaming.

Oh i hear you.
The renaming is needed because jpgs could be aces encoded, as that's an option for the current spec, but there is no way to read the encoding, as that's not a spec-defined property for those images.
So, the only "metadata" we (and anyone else, for that matter.) have available is the filenames.
Catch 22, unfortunately, and out of our hands.

The switching as well is as ugly as it could be, but there truly is no way around of, right now, under Max, and even then it's imperfect because *all* the tools that aren't the VFB can't work properly and end up displaying *something*.
Speaking of color management throughout, it may seem i am being overly concerned with the vain, but it's something we give for granted as it's a standard sRGB, LWF encoding, and it "just works" by now (it took nearly two decades to do so.).
Not color managing viewports *independently* would mean that you got also the data colors in viewport all broken (think of wirecolors, any data-driven mesh color generated with sRGB LWF in mind, like xViews), while the other perspective view was rendering an IPR under ACEScg.
And this is why the color picker would become devilishly complex: are you picking for an xView color in LWF sRGB, or are you picking for an IPR view in ACEScg? And what would you pick: the scene-linear, or the displayed one?

The list is actually enormous in size, and if Autodesk was to undertake the work to implement OCIO in Max, i'd pity them.
On the worthiness of such an undertaking, however, i'd have no doubt: it'd modernize Max in an area that is sure to see a lot of action in the years to come, as display technologies with truly wide gamuts trickle down to the broader public, and the adoption and need for wide-gamut material increases.

EDIT: historically interesting article on the advent of ACES, from 2011. Notice where the CG was in the pipeline, back then. Not that anyone lamented lack of dynamic range in the CG found in movies.

[PIXELBOX_SRO]

gotcha...too early to implement as reliable bulletproof pipeline in smaller studio environment.
I can remember the LWF hustle when it arrived and the headaches it gave me when reading all the resources outthere....tnd that was alctually just a few buttons to implement and stick to .....aces is another league with way too many inpots to take care of.
Cheers!