Quixel Help Center home page

"Linear" not available for PNG 8-bit Custom Packing

Answered

Comments

11 comments

  • SkyDriver

    Delete the Bridge folder on "C:\Users\<Username goes here>\AppData\Roaming", And make sure that Bridge is closed before you delete the folder.

    1
    Comment actions Permalink
  • normalvector

    Thanks for the suggestion but it doesn't seem to have worked.

    I deleted the Bridge and "Megascans Bridge" from AppData, the UE4 plugin, and uninstalled Bridge.  Reinstalled and still have the same issue.

    0
    Comment actions Permalink
  • rosenand

    Hello. I was about to post a new thread about it but fortunately I found yours, proving I'm not the only one wondering about this. It's stated in the documentation:

    "The Linear color-space option is only available with 16-bit channel depth." (source)

    But it's hard for me to grasp how this is acceptable. Masks like Roughness or Metallic should be in linear space, that's how they are exported e.g. to UE4 by default, without packing. Exporting them in sRGB is simply wrong. They will effectively represent the same values, if sRGB is ON in UE4 when packed, but this is not the correct workflow (applying gamma correction while exporting from Bridge, and then reversing it in the engine).

    And exporting 16-bit PNGs is not a viable option. They will be huge, and also it would be a waste considering that the source textures are downloaded into the local library as JPGs (unless we're expected to download everything in EXR). Come to think of it, Windows tells me even the source JPGs fof stuff like AO are in sRGB...

    Please help me understand the intended workflow for channel-packed textures (I'm using UE4 but the question is general). Thank you in advance.

    0
    Comment actions Permalink
  • Jonathan (Community Manager)

    Simply set your channel-packed textures to Masks compression in UE. The engine will handle the rest for you.

    0
    Comment actions Permalink
  • rosenand

    I tried this before, comparing an unpacked mask (as reference) to the respective channel of a packed texture, and they looked differently in UE4, which made me assume the packed version had wrong values.

    But now I checked the actual Roughness buffer in the viewport and they are identical. The textures, and the samplers in their respective shaders have the same settings, so must be some quirk of the way UE4 displays textures in the texture asset editor.

    I'm glad it works but still something is not right. If these packed masks were truly sRGB, they would've looked differently (with sRGB unchecked in UE4) than the unpacked reference version (also with sRGB unchecked).

    Video: https://drive.google.com/file/d/1GWV105EEcAsST1Vwbky_sNEXkQJAjNXD/view?usp=sharing

    0
    Comment actions Permalink
  • Jonathan (Community Manager)

    This is the standard workflow that we've been using since UE4 shipped - the sRGB checkbox with Masks compression ensures that the textures are loaded in the correct color space and rendered as they were intended to be. 

    0
    Comment actions Permalink
  • rosenand

    I understand the workflow on the UE4 side, just not on the Quixel Bridge side :)

    0
    Comment actions Permalink
  • Jonathan (Community Manager)

    All you need to do is export. The maps are converted to the correct color space when loaded in-engine and compressed correctly.

    0
    Comment actions Permalink
  • rosenand

    Got it, thank you for your patience :)

    0
    Comment actions Permalink
  • normalvector

    It's good that this isn't a problem with the export but it does point towards a problem with Bridge's labelling of the outputs.

    The UE4 Masks compression option is linear, not sRGB.  This is so important that the actual name of it in the drop-down during texture import is "Masks (no sRGB)" (as shown in UE4 screenshot portion below) and so to work correctly without gamma/banding issues the mask image must be also linear, and the fixed "SRGB" label on the output from Bridge is wrong and it should be "Linear" instead.

    0
    Comment actions Permalink
  • rosenand

    That was exactly my point, thank you!

    0
    Comment actions Permalink

Please sign in to leave a comment.