Proper Texturing Workflow for Unreal Engine

[Thomas_Mansencal]

@daskyler

• UE4 uses ACES 1.0.3 and not 1.1?

Correct although for LDR (non-HDR) output it does not really matter as the LDR ODT is the same and you would need to grade specifically for HDR.

@daskyler

UE4 uses sRGB linear (given you’re feeding it sRGB colour) throughout the pipeline up to the tonemapping step, at which point it uses RRT → ODT to output the final tonemapped image?

Also correct, UE4 working space is implicitly assumed to be sRGB.

@daskyler

• UE4 has a fix for blue intensity applied to ACES similar to High light fix and premature desaturate?

Yes but it is not implemented as per the book and cannot be matched in a standard ACES worfklow. There is also a Gamut Expansion LMT in UE4, if you have UDN access, this is super relevant: https://udn.unrealengine.com/questions/543111/view.html

@daskyler

The other tweak is a gain of ~1.4, which I believe I read was to limit the amount of texture rework and still use sRGB.

Correct, it is exactly 1.45.

@daskyler

• ACES 1.1 solves some of the hue shifts issues from ACES 1.0.3 (possibly removing the blue fix in Unreal)

No, for practical purposes, ACES 1.1 and ACES 1.0.3 are the same for the LDR path.

@daskyler

Why is the ACES tonemap applied on linear sRGB instead of using an IDT to transform from sRGB → ACEScg? Or is there an IDT applied there and I missed it?

IDTs are technically for input devices, e.g. a camera and they convert from that input device to ACES2065-1 (AP0). UE4, internally converts directly from sRGB to ACEScg (AP1) as required for tonemapping purposes.

@daskyler

From Substance to Unreal, which is the more ‘correct’ workflow?

• No changes to materials, and using @bleleux’s ACES LUT?
  • Is it correct to say that this has baked the entire IDT → ACES → RRT → ODT transform into one lookup?

Yes, however, the conversion is more like sRGB —> ACES2065-1 —> RRT —> ODT.

@daskyler

@Dogway’s filters + LUT, where for display in Substance both the PBR_SmartFit and ACEScg conversion are applied

No please don’t do that, it is a landmine field and it will throw you off a cliff one day or the other. I wish that thread was never referenced again.

@daskyler

The ACES per material shader we found (but possibly expanded to include UE4’s tweaks to ACES)?

We did that at some point but it is much easier to use a LUT, even one that clips highlights. Keep in mind OCIO is coming to Substance Painter and it will make all the three methods above obsolete.

@daskyler

When should we (or do you) adjust the tonemapping curve to ensure our textures are supporting the result we want?

Never! By adopting a fixed View/Display Rendering Transfom (DRT), you ensure that all your assets are authored in a consistent way which makes them easy to share across shows/games. The other side of the coin is that if they are authored while respecting PBR common sense, they should look good no matter the DRT.

@daskyler

How do you help ensure your albedo textures are ‘base truth’ and not compensating for the tonemap apart from having a physically based reference for all material types?

Ideally, you have everything under control and processed the photographic source images linearly, with reference colour rendition charts, etc… Now it is important to keep in mind that “base ground truth” is somehow vague: albedo in the first place is a measure bound to solar irradiance which encompasses both the diffuse and specular components of the reflection when it is measured. Textures are pretty much never shot in direct sunlight Ground truth would be more about spectrally measure not only the BTF (Bidirectional Texture Function) of the surface but also measure its Polarimetric Reflectance: a Spatially Varying Polarimetric BRDF (Bidirectional Reflectance Distribution Function). And then there is fluorescence, etc…

@daskyler

Are we shooting ourselves in the foot matching to UE’s implementation of ACES tonemapping with its tweaks, particularly the gain? Would we be better served by replacing it with ACES 1.1 and then using the adjustments provided by Unreal (i.e. global, highlights, shadows settings)?

ACES 1.1 will not change anything and we are at 1.2 btw The easiest way, for now, is to use the following OCIO colourspaces and disable the Gamut Expansion and Blue Light Artifact Fix as indicated in the UDN Question:

   - !<ColorSpace>
     name: ACES sRGB ODT
     family: View
     equalitygroup: ""
     bitdepth: 32f
     isdata: false
     allocation: uniform
     allocationvars: [0, 1]
     to_reference: !<GroupTransform>
       children:
         - !<FileTransform> {src: InvRRT.sRGB.Log2_48_nits_Shaper.spi3d, interpolation: tetrahedral}
         - !<FileTransform> {src: Log2_48_nits_Shaper_to_linear.spi1d, interpolation: linear}
         - !<ColorSpaceTransform> {src: Colourspace - ACES 2065-1, dst: Model - Reference}
     from_reference: !<GroupTransform>
       children:
         - !<ColorSpaceTransform> {src: Model - Reference, dst: Colourspace - ACES 2065-1}
         - !<FileTransform> {src: Log2_48_nits_Shaper_to_linear.spi1d, interpolation: linear, direction: inverse}
         - !<FileTransform> {src: Log2_48_nits_Shaper.RRT.sRGB.spi3d, interpolation: tetrahedral}
 
   - !<ColorSpace>
     name: UE4
     family: View
     equalitygroup: ""
     bitdepth: 32f
     isdata: false
     allocation: uniform
     allocationvars: [0, 1]
     to_reference: !<GroupTransform>
       children:
         - !<ColorSpaceTransform> {src: ACES sRGB ODT, dst: Model - Reference}
         - !<CDLTransform> {slope: [1.45, 1.45, 1.45], direction: inverse}
     from_reference: !<GroupTransform>
       children:
         - !<CDLTransform> {slope: [1.45, 1.45, 1.45]}
         - !<ColorSpaceTransform> {src: Model - Reference, dst: ACES sRGB ODT}

Should use the ACES Config with that new ColorSpace and it will match UE4.

Cheers,

Thomas