Announcement

Collapse
No announcement yet.

Fix UE's alpha handling

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    This is Adobe's fault, not Epic. Having white (or whatever PS randomly decides) on transparent pixels from Photoshop's default PNG exporter had been a problem for game textures since forever, long before UE4 and even UE3 were a thing. You do not want the engine automatically "fixing" or "guessing" the color value for transparent pixels because not every texture is a cutout and your material might need those values for something else (roughness, occlusion, etc).
    Last edited by Manoel.Neto; 06-03-2019, 08:17 AM.

    Leave a comment:


  • replied
    For other people finding the PSD issue, previous poster is absolutely correct in that Adobe has chosen two things that make alpha handling a nightmare. The latter, that the background is set to white, is a large one.

    For those looking for other possible solutions, OpenImageIO’s `oiiotool` should handle the broken PSD’s background colour and broken unassociated encoding format correctly.

    Leave a comment:


  • replied
    I know I read this thread a bit late but there is an easy solution for everyone.
    If you use PNG don't use built in Photoshop version. PS always fill the empty(alpha) info with white and it's wrong method.

    This is a free plugin for Photoshop:
    https://www.fnordware.com/superpng/

    When you install than you will found second PNG export version in the save list. (SuperPNG (upper PNG))
    SuperPNG option window:
    - select Clean Transparent (you need to check this at each export - some PS don't save the setup!)
    - save file

    If you don't use PNG than you need bleed out the color data (RGB) into the transparent region to avoid unwanted pixel noise at the alpha edge.
    There is a free Photoshop plugin from NVidia:
    https://xnormal.net/
    When you install than you will found under Filter/xNormal
    - select color info (layer)
    - Use Dilatation from the xNormal option list
    - Radius (in pixels) - how many pixel to bleed out into the alpha region
    - save file

    Welcome

    Leave a comment:


  • replied
    I'm not doing anything - the artist shouldn't need to know about that, not to mention that it's a fairly length and destructive process to put the original file through. It's such a simple thing to fix programatically.

    Once this is in you'll look at anyone saying it needs to be a manual process like they're crazy.

    Leave a comment:


  • replied
    are you doing texture padding? http://wiki.polycount.com/wiki/Edge_padding it is practically a required procedure for whatever texture you do for game engines.

    Leave a comment:


  • replied
    Originally posted by Kalle_H View Post

    Mipmaps are generated on CPU. But bilinear filtering happen when you sample texture at rendering time.
    That's what I thought. We're talking about modifying tesxture output to exclude zero alpha pixels when being generated. This wouldn't be forced on you or a default setting.

    Leave a comment:


  • replied
    Originally posted by Antidamage View Post
    Yeah after thinking about it for a few days doing it during mipmap generation would be a strange place to fix it.

    I've lost the issue tracker link but it turns out Epic became aware of it in April finally and are going to do exactly what we're discussing, I can only assume that they'll handle bleed as an import step or something. Obviously it'd be an option in the texture.

    Are mipmaps really generated on the GPU? That doesn't seem right but I've never gone beyond a high level with it.
    Mipmaps are generated on CPU. But bilinear filtering happen when you sample texture at rendering time.

    Leave a comment:


  • replied
    Yeah after thinking about it for a few days doing it during mipmap generation would be a strange place to fix it.

    I've lost the issue tracker link but it turns out Epic became aware of it in April finally and are going to do exactly what we're discussing, I can only assume that they'll handle bleed as an import step or something. Obviously it'd be an option in the texture.

    Are mipmaps really generated on the GPU? That doesn't seem right but I've never gone beyond a high level with it.

    Leave a comment:


  • replied
    Originally posted by Antidamage View Post
    Oh yeah, that makes sense. I wondered about that earlier. When mipmapping it should seek out the nearest valid pixel with any amount of opacity above zero and sample that. In fact, it could just average out the other three pixels being considered during reduction, or however many are valid.
    Bilinear filtering or mipmapping cannot assume that alpha is treated as opacity and zero alpha pixels would be invalid. In our game we store albedo to rgb and roughness to alpha. You could code custom mipmapping filter that would do that but bilinear filtering is done by gpu hardware and cannot be modified.

    Leave a comment:


  • replied
    There was value in talking about it. There's just no use in finding a work-around when what we want is a comprehensive feature request to put to Epic.

    Leave a comment:


  • replied
    Originally posted by Antidamage View Post
    Guys, let's get over it. It's broken, it will be fixed, and knowledge of issue in the userbase will cause it to be fixed quicker. Apologists need not apply.
    I get that, but I'm saying posting this here won't get Epic's attention - make an actual bug report if you haven't already to get Epic eyes on it.

    Leave a comment:


  • replied
    Oh yeah, that makes sense. I wondered about that earlier. When mipmapping it should seek out the nearest valid pixel with any amount of opacity above zero and sample that. In fact, it could just average out the other three pixels being considered during reduction, or however many are valid.

    Leave a comment:


  • replied
    Originally posted by Antidamage View Post
    Interestingly enough TGA has exactly the same problem - it's pre-multiplied against white on import. I don't know how people have been using this like this for so long, when you consider the process to get around it:

    1. Select all visible layers, add as alpha channel
    2. Copy all layers combined, paste in the back, blur, then duplicate and merge the layer several times to get colour bleed to force opaque pixels
    3. Save (as anything)

    That's a lot of work.




    This is the poster-child for not pre-multiplying the colour data, yep! I'd put it in the actual texture settings though, so it can be changed after import.

    Excellent link too. It's a shame that this problem isn't easily solvable in Photoshop either.
    This is not exactly a format specific thing. It is related to texture filtering. For many importers/exporters out there( not only UE or shop specific) the default behavior is use white color on a color channel, where no color data exists. If you sample your texture with nearest filter, you will never run into problems, because there will be always a match. When you introduce bilinear interpolation, pixel with color(0,1,0,1) and pixel with color(1,1,1,0) can get averaged to (0.5,1,0.5,0.5). The issue also propagates to mip chain generation. A common approach is to dilate the color channels, so that color data extends past alpha borders spatially. Applicable to photoshop, you should be able to automate the dilation process with an action/macro. If you are seeing checkerboarded(transparent) pixels in photoshop, those will end up white whereas you need those to be closest match possible to the content, you are trying to cut out. There is no pre-multiplication involved.
    Last edited by Deathrey; 09-05-2018, 06:44 AM.

    Leave a comment:


  • replied
    Interestingly enough TGA has exactly the same problem - it's pre-multiplied against white on import. I don't know how people have been using this like this for so long, when you consider the process to get around it:

    1. Select all visible layers, add as alpha channel
    2. Copy all layers combined, paste in the back, blur, then duplicate and merge the layer several times to get colour bleed to force opaque pixels
    3. Save (as anything)

    That's a lot of work.


    Originally posted by Deathrey View Post
    Exactly that. And additionally, when alpha channel information has no correlation to color channel in respect to how they are going to be utilized.
    But I can clearly see speedups in PSD workflow, if your suggestion(namely, grabbing color data from underlying layer, where current has none) gets implemented as a toggle in texture import settings.

    Link to a pretty good blog post about the nature of the problem for other people reading thread.
    This is the poster-child for not pre-multiplying the colour data, yep! I'd put it in the actual texture settings though, so it can be changed after import.

    Excellent link too. It's a shame that this problem isn't easily solvable in Photoshop either.
    Last edited by Antidamage; 09-05-2018, 06:12 AM.

    Leave a comment:


  • replied
    Originally posted by Antidamage View Post
    An option would suit me! Can you explain what you mean by not pre-multiplying layers against each other though? The only time I can see that being relevant would be if you're exploding a PSD file into multiple textures based on group or layer, in which case yes, you wouldn't pre-multiply against layers that will not appear in your texture result.
    Exactly that. And additionally, when alpha channel information has no correlation to color channel in respect to how they are going to be utilized.
    But I can clearly see speedups in PSD workflow, if your suggestion(namely, grabbing color data from underlying layer, where current has none) gets implemented as a toggle in texture import settings.

    Link to a pretty good blog post about the nature of the problem for other people reading thread.
    Last edited by Deathrey; 09-05-2018, 06:06 AM.

    Leave a comment:

Working...
X