Compression artifacts in mipmaps

Help & Support
1

I have seen this issue frequently. It seems that some textures, when compressed with mipmaps enabled, will get a pink block of pixels or line mixed in. The pink pixles come and go as camera distance varies.

image

(This is a 4K square texture.)

image
image384×685 12.6 KB

I have tried to un-compress, then re-compress textures like this. It seems that the pink lines may move to another area, but won’t go away completely.

Commonly, these artifacts occur in areas of the texture that are just a white (or near-white) field, with no or very little detail, as in the image above.

Is there a work-around? Some combination of settings that I can try? So far, my only solution is to leave textures uncompressed, but that’s no good for mobile devices.

2

Hi @Cain_Quigley,

VRAM compression is lossy, so there can be artifacts in some textures especially textures like that (letter with lining). If you aren’t able to resolve that then you will have to disable compression.

Also is this a repeating texture? If not and it’s only tiled once then set Address UV to Clamp. That can get rid of artifacts in the border of the texture (this isn’t related to compressed to textures but to all textures in general).

1 Like
3

This texture does not repeat, so I’ll make use of that ‘clamp’ setting. Thanks for that piece of advice! I’m sure I can apply that more broadly.

It would be unfortunate if I can’t compress these textures. We always want our projects to run well on mobile devices.

1 Like
4

@Cain_Quigley I can give you access to the basis compression tools that may be an alternative to current compression options.

The downside is that it requires a wasm library to be loaded which adds to the initial download size.

Would you be able to send a copy of one of those textures to the team and see if we can do anything our end?

5

@Cain_Quigley What formats/devices do you see these artifacts on? We use different tools for the compression so this will help us narrow this down a bit :slight_smile:

6

@Cain_Quigley Seems like it only happens on JPGs and/or textures that are not already POT and are resized on import.

Using your example texture, if I convert it to a PNG first and then import, I can’t yet see any artifacts.

7

Hi, thanks! Thanks a big step in the right direction. We have been using JPG where possible. But, since we are going to be compressing most textures anyway, it makes sense that we can use PNGs.

Could these issues be related to compressing an already-compressed format, like JPG?

8

I wouldn’t have thought so but we do have an issue logged on our backlog so hopefully we can get a chance to look at the cause.

It’s weird that it’s random too

9

Well, it’s also possible that I’ve been getting lucky. Since the problem seems to be related to mipmaps, and because I tend to constrain the camera for our projects, there may be ‘altered’ texture levels that just never get used/seen.

IOW, my testing has been far from exhaustive. I ship 5-7 projects a week sometimes! I regret that often I just don’t have the time. My boss says he’s hiring me an assistant, though. We’ll see how that goes. :slight_smile:

1 Like
10

Hahaha yeah I know that feeling, I’ve only ever run into a problem with using JPG for like one texture, otherwise I guess I don’t notice it or something!

Your linked-in is very impressive by the way!

11

Thanks, Chandler. I guess I’ve been in the industry a while, yeah.

Here’s another interesting ‘compression artifact’ but it’s not related to mipmaps, this time. It’s related to cubemaps. After compressing the JPEGs for the cubemap (without mipmaps), I am seeing the images have become inverted! …not all the images, though…just the front/back/left/right ones.

image
image1908×960 797 KB

This is supposed to be a forest scene. You can see the tiling is messed up. The ‘up’ image is correct.

These images were imported as TGAs.

edit: the image inversion does not show in the editor…only a Launched debug window, or a build.

1 Like