Hello, my disagreement with @Thomas_Mansencal was ONLY about having the option for “Output - sRGB” as IDT (talk about nitpicking). But as I said it’s an option not an enforcement, you can also choose “Utility - sRGB - Texture” as IDT to conform to standard ACES.
Use common sense, applying a gain of 1.45 because “Utility - sRGB - Texture” looks dark is a destructive hack, you will blow out highlights, think of white textures (walls, snow, etc).
I will be releasing a project in 3 weeks most that deals with all the issues people are having with “Utility - sRGB - Texture”.
Using the contained LUTs that do sRGB —> ACES2065-1 —> RRT —> ODT is a landmine field, colors don’t go well through the log shaper for Substance Painter LUTs. My version doesn’t do any color work, it’s only the tonemapping part.
Now I also have other LUTs that along the ACES Filter (PBR SmartFit is for PBR fit) makes it possible to go through ACES within Substance and later apply the RRT + ODT, and this is close to official ACES as you can check here.
You can still use PBR SmartFit for PBR compliant textures though, this ensures physical plausible albedo ranges as PBR guidelines (PBR MetalFit includes fix for metals too), you still don’t know if it has embedded camera curves but if you author your own textures you can design a negative curve of your camera response (i.e. shooting to some targets), reference colour rendition charts by their own are not reliable enough by the way.
The gamut expansion is subtle enough to ignore for the average texture in my experience unless you’re working with saturated colors near the Rec.709 boundary. The blue light fix may be more of a common issue since it has a bit of an effect into cyan and purple, but the blend is arbitrary and may not even be necessary. I generally disable it unless I need it- it’ll be pretty obvious if you have any bright blue emissives and don’t use the correction.
I agree. There’s a few shader-based ACES implementations(almost always from Narkowicz’s RRT+ODT fit), but imo it helps to have the background HDRI match as well and it reduces the need to manage however many Painter shaders you use. Sadly the LUT requires an additional step that I wish wasn’t needed, but you can set up a template with everything already enabled for your project.
Thank you all so much for your quick responses. Couple follow-ups:
To make sure I’m interpreting this correctly: you’re advocating avoiding touching any of the filmic curve parameters UE exposes like slope/toe/shoulder, since that is meant to be a fixed standard, and any adjustments to be done through LMTs (UE’s color grading categories)?
To go back to what spurred this topic, the original rock texture done in Substance, using their default linear tonemapper, had a lot of colour detail that ended up disappearing after tonemapping. Am I correct that this likely means our albedo was authored with too bright colours? And we should author based on no changes to the color grading categories & the default ACES curve.
I read the UDN link - to disable these changes, you locally modified the PostProcessCombineLUT shader, correct?
Thank you for clarifying Jose; I must admit that at first that discussion had gone over my head, so the exact disagreement was unclear.
What is the ‘log shaper’? Which part of the transform does it affect?
Good to know. I’m going to see what effect it has on our current content if we revert back to standard ACES, but depending on our VFX going forward I may need to bring back the blue light fix as you point out.
Exactly! It is entirely fine to play with exposure though as you author your assets, you should do that all the time in fact, check that they look great at any exposure value.
It could be either that the albedo values are too high or that the lighting intensity/exposure of the scene is too high. Hard to get a solid answer without seeing the texture or asset.
Ideally yes, see it as your neutral authoring conditions.
You can actually set them to 0 in the PostProcessVolume Actor:
Thanks for this great thread ! There were a couple of similar topics on the forum in case you haven’t read them :
Mostly answered by @Thomas_Mansencal There is probably more stuff to read about albedos and such but I would have to dig deeper in the forum archives.
We are also trying to develop an open-source tool based on the Pointer’s Gamut to help artists to check their textures’ base colors (as a personal initiative, not ACES related). Maybe it could be helpful.
There was a discussion about a knowledge base on the new ACESCentral website. Like collecting all the interesting threads into proper documents/pages to give people easier access. I would even volunteer to do that to be honest, since my website is partially based on these threads. Will ask Steve and Scott about it. Sorry, I did not mean to hack the thread…
Chris
No worries @ChrisBrejon! I’m sure a lot of folks would benefit from that page; your summary that I linked earlier was far and away one of the best introductions to this topic.
Cool ! I’ll let you know how this goes @daskyler Thanks for the link to the Unity page. I didn’t know about it ! Sebastien Lagarde and his team really care about this topic : PBR values and such…
At BioWare after we’d transitioned to Frostbite, Seb Lagarde & Charles de Rousiers helped guide our team through the transition to PBR. Can’t speak highly enough of them
Several of the sections in the ACES Central Knowledge Base are summarised versions of threads or posts from the forum. I think it would be worth talking to @stobenkin about adding other topics to that, if you have ideas of what would be useful. It could benefit from more content there, and the useful forum discussions can be hard to keep track of.
What is the ‘log shaper’? Which part of the transform does it affect?
The process where the LUT is made implies doing color transformations in a space that is not linear leading to innacurate color output. My ACESFilm LUT doesn’t do any color transformations only the tonemapper part, whereas the ACESFilm for ACEScg LUTs do the conversions in linear space so they are the recommended method (until OCIO that is).
For the same reasons explained above, I don’t recommend tweaking your exposure to compensate for dark textures from the “Utility - sRGB - Texture” IDT, lookdev normally is done in rather flat lighting. As always I recommend to use gamma (for the time being). Long story short; exposure brightens bright values, gamma brightens dark values.
We are starting a Virtual Production project that includes building lighting tools and standardized assets (buildings, environments, props) in UE that would be easily re-usable in other VP projects. We see ACES as a critical element for this workflow to tie the color spaces together. As we try to use off the shelf assets we are finding more and more that tricks are frequently used to get a UE asset to work in one specific project . It often requires modifications to blueprints and textures to make them portable into new VP projects using different lighting and combining them with other assets.
ACES AND VP Questions:
Is anyone working on a standard for ACES compatible UE assets for use in Virtual Production?
ACES and VP with UE would require a defined workflow as well? I think the asset standard would need to be tied to a recommended workflow. Is this a project being considered?
I assume an ODT would be needed for the LED Wall and an IDT for the camera - would these need to be developed specifically for this VP process or will a standard camera IDT and display ODT work?
For VP lens calibration is also a critical component - dont know if that should be part of the workflow.
How do you see the virtual screen color using an ODT, the camera with an IDT interacting with the live actors and props on stage?
Exciting times to be in our industry. Look forward to hearing any comments/suggestions.
Mmmmh, lookdev is typically done in many scenarios e.g. from studio neutral, to overcast and daylight. There is simply no way for an asset whose appearance was developed under flat lighting conditions to look great in daylight. Assets must be tested under the most varied lighting conditions possible or at least those representative of that they will be subjected to in the show. The corollary is ensuring that the asset looks great at all the exposure levels.
I wish I could answer your remaining questions but I contractually cannot!
If you have UDN access, I would probably also consider asking that over there!
Reviving this topic in regards to texturing workflow. In the meantime Substance Painter works with OCIO so that part is easy-peasey. As mentioned above UE uses sRGB linear as its working space, and will read in 8-bit color textures with the sRGB checkbox selected converting them to sRGB linear. It can also recognize normal maps and uncheck the sRGB box. Trouble is other non-color maps: masks, metalness, roughness, AO, etc. which need to manually have the sRGB checkbox turned off. Looking for a good approach to having it automatically detect the correct IDT.
AFAIK, Unreal does not support OCIO rules such as the ColorSpaceNamePathSearch, which is how we would approach this with OCIO in Maya. So I’m curious if anyone has any approaches to get Unreal to automatically ingest non-color textures as raw? What would be nice is to set it to default to reading all textures as raw, with an exception made for color textures, based on naming conventions.
One possibility, I was considering is writing color and normal maps as PNG, and the non-color maps as EXR, which would presumably be read by UE in linear.
There is probably more stuff to read about albedos and such but I would have to dig deeper in the forum archives.
