Seams / Artifacts between texture tiles when using Mipmaps

Questions
, ,
1

Hello.

I’m using a SpriteMap Tile Layout to display the plane of a boardgame I’m developing.

Now…
I’m using BABYLON.Texture.NEAREST_NEAREST as sampling mode to avoid problems.
If I were use BABYLON.Texture.LINEAR_LINEAR_MIPLINEAR, this is the problem I would face:

BUT…
I’m curious and I would like to understand why exactly this happens, what’s the theory behind this and -ideally- what would need to solve this problem.

I would happy to contribute to this project and -maybe- to improve what it offers…

To be honest, I’ve been investigated this issue a lot for a while now, trying to replicate it even with different frameworks but -even if it seems to be actually a well-known problem by everyone- I wasn’t able to find a definitive solution for this.

The best (but not yet complete) result that I got was by using fwidth and smoothstep together in my fragment shader.

I also came across this other post where the topic have partially been covered…

Do anyone know something about this?

2

Maybe @Pryme8 can have a look as he is the brilliant mind behind the sprite map :slight_smile:

3

In this case you would need to make sure that each of the tiles have a extended edge that goes beyond their normal frame.

In the tileset that is being used in this example (which is one I made so I know it does not have any extends) does not have anything to sample beyond its edge so when doing mipmaps it sees that as “transparent” resulting in the artifacts.

image
image279×279 6.6 KB

This would need to have all of the graphics get their edges extended and then the texture repacked for that to not show the lines.

I think in order to prevent any artifacts while using mips you would need to have at least a four pixel buffer from the edge of a extension of the last color.

1 Like
4

Actually, I need to take a deeper look into this. I did a quick test last night to see if expanded tiles work and its the same thing, so it sounds like a sampling error or something is wrong with the underlying texture buffers.

5

{667F5C28-3049-49CC-9D8B-0652B8E68A02}
Ok so it looks like its the underlying tileUV ends up having artifacts when mipmaping is being used. I’m not really sure why this would be as the tile UV is calculated on the fragment maybe there is something underlying I don’t understand?

You can see on line 63 how Im just setting the color to the UV an we get those little bands between the tiles. Really kind of intrigued why changing the diffuse textures mipmap settings would effect this.

If we can figure out what is causing the banding between tiles then this will be solved.

UPDATE

Fixed it, Ill try to get a PR in today.

PR

2 Likes
6

Hi! I just saw that the PR has been merged and the new version of Babylon has been released.

The result is now awesome!

I took a look at the PR but -honestly- I can’t understand what the difference is…
It seems that the code has just been “prettified” and nothing more…

What are the actual breaking changes that solved this problem? :thinking:

7

Just ensured the correct sampling method was being used.

8

@Byloth

Now I need to wrap this PR up so you can have light effects and other jazz.

2 Likes
9

Ok, so…
Just to let you know and keep you updated on this…

I experimented further, trying to actually use mipmaps.

I DO appreciate your work on this PR, @Pryme8, but forcing the mipmap level to 0.0 essentially disables it.
The result -indeed- is that tiles have jagged edges between them tiles themselves look jagged as they get farther from the camera.

Not an ideal thing… Mipmaps are designed to solve this exact problem.

After few weeks of experimenting I -finally- came up with a solution.
Honestly, I tried to implementing it here too but without success…

As you can see, I added these few lines to the fragment shader:

vec2 sizedUV = uv * vec2(<texture_size>);

// [...]

float dx = length(dFdx(sizedUV));
float dy = length(dFdy(sizedUV));

float mipmapLevel = log2(max(dx, dy)) + <bias>;

// [...]

gl_FragColor = textureLod(spriteSheet, (tileUV * frameSize) + offset, mipmapLevel);

I don’t know if this will be useful, but I’ve described everything in detail…
Starting from what was happening and -more importantly- WHY it was happening…

The only downside is that I implemented it using Three.js.

BUT… Maybe there’s something you can “extract” from this and adapt for Babylon.js as well!

Thanks again for your time.

10

Oh, the idea for the sprite map was to be pixel perfect that is destroyed usually by LODs, but sure yeah I hear you. We can make the appropriate changes here.

I appreciate your clarity, sorry for the miss understand.

here is without the hardcoded size.

Also what is the bias; what is that based off of? Lets get this figured out.

Your fix is super legit lets get a PR in for it!

Also, I have something in the works for Sprites in general for BJS so stay tuned.

1 Like