So, I just got informed that we are now able to split textures in a texture atlas and have them tile.
I didn’t notice the change but I’m pretty sure we couldn’t do (like we were able to in UDK) a while back.
Anyways, as many of you might know, this usually cause bleeding (grid-like lines in the material surface).
There are two different things about it that cause these problems:
The first (and most simple) problem is that when mipmaps are generated for the texture they will bleed into each other, so having big contrasts between textures that are close to each other in the atlas will cause more bleeding. This can be circumvented by adding padding to the texture and then cropping the texture in the material to use a smaller part of the texture.
For example my texture sheet have textures that are 2048^2, these have been re sized to 2000^2 and have a 24 pixel border (padding) around itself. This increase the distance at which the pixel will bleed into each other and works fine.
The second problem is that somehow the Frac node that we use to crop the texture cause a thin line of pixel artifacts.
Like this:
(picture kindly provided by Oliver M H)
These could be removed back in UDK by using the following setup (and code in a custom node):
I’ve tried doing this in UE4 and haven’t been able to get it to work.
I’m at work right now and can’t recall exactly what the error said, I’ll add it when I get home.
So my two questions are:
Is there a way of getting this to work in UE4, so I can get rid of the pixel artifacts?
And
Is there a better way of removing the bleeding (not caused by Frac)?
My atlas is 8192^2 pixels with 16 2048^2 textures. Each texture have 24 pixels border around it’s edges which removes bleeding close to the player but it get’s rather apparent further away. I’ve reduced it by blending in a flat color by depth (replacing the diffuse) but I would prefer not to do that.
Is there a way to control how the mip maps are generated? or possibly making them by hand in some software? If the borders between each texture wasn’t blurred/blended together I wouldn’t have this issue.
You can get rid of the frac artifacts by manually computing the Mip level. There is a material function called CimputeMipLevel which provides the necessary math.
The downside is it will add ~15 instructions due to the log2 function and it removes anisotropic filtering (although Temporal AA helps to fight the aliasing/noise).
Here’s a simple material setup for 2 sub-textures of one atlas:
It worked pretty well, the artifacts are gone and there is hardly any noticeable bleeding now, only on hills far away.
I have a new problem though, in certain angles (it seems) the texture turns brown instead of the green it should be and there are some new lines appearing.
I’ve included a picture. Please ignore how horrible it looks.
This is definitely a mipmapping issue.
What I did as a workaround is to modify the ComputeMipLevel function to select higher mips at steep viewing angles.
Hi guys, I m struggling to figure out how do control the sub-texture tiling scale, after the frac function from an atlas.
I guess it would make sense to set the texcoords scaling of the atlas first, and then frac using decimals, but that will obvisouly cause severe floating point problems (with values like 0.1), is there a way I can control the UVmapping scale, after the frac and divide? So from a Texture sample, then scale it?
Rahter than setting the texcoords scale, then trying to frac and divide/offset the correct amount for the tile?
Ehm… Is that maybe what the compute miplevel can be used for *(other than fixing the tiling artifacts)?
