Announcement

Collapse
No announcement yet.

Fix UE's alpha handling

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

    #16
    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.

    Comment


      #17
      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.

      Comment


        #18
        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.

        Comment


          #19
          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.

          Comment


            #20
            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.

            Comment


              #21
              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.

              Comment


                #22
                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.

                Comment


                  #23
                  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.
                  0xAFBF
                  https://github.com/0xafbf

                  Comment


                    #24
                    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.

                    Comment


                      #25
                      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

                      Comment


                        #26
                        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.

                        Comment


                          #27
                          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.

                          Comment

                          Working...
                          X