So I’m rendering blocks next to each other, and I’m getting a strange artifact between the blocks. It started happening when I started using a texture atlas.
Things I’ve already tried to fix it: using GL_CLAMP, GL_CLAMP_TO_EDGE, and GL_NEAREST for my texture parameters.
Anyone know what’s causing this and how to fix it? Or, any guesses?
Update: it turns out, this only happens on my laptop. On my desktop it works flawlessly.
I don’t know for sure but I THINK my laptop has an AMD card… and my desktop has an NVidia card… so…
So they implement the spec differently. It doesn’t tell you which one is right and even if one of them is wrong (instead of the spec being open to interpretation), you still have the artifact. So AMD v nVidia doesn’t move you forward.
Are you 100% sure this is a texture bug? It really looks like a floating point error on your geometry.
Are you using mipmapping?
I am almost certain this is a texture bug. I really don’t see where any floating point error could be getting in there, but then again, I’m no pro.
I am not using mipmapping.
The code is available, if anyone wants to try and look.
Texture atlas: https://github.com/sci4me/SciCraft/blob/master/src/main/java/com/sci/craft/client/texture/BlockTextures.java
Block rendering: https://github.com/sci4me/SciCraft/blob/master/src/main/java/com/sci/craft/client/render/RenderChunk.java
I don’t understand how it would be a floating point error if it only happens on the AMD card… but like I said, I am a n00b at rendering.
This is precisely why I think it’s a rounding error, granted I could be wrong.
There’s couple things you should do. You decide the order cause like I said it could be texturing.
When you create two adjacent blocks check to see if you are referencing the exact same vertex positions, for the points that touch. If you don’t you will get rounding errors leading to edges that don’t quite line up. This could be where the problem comes from.
Also, see if you can replicate the issue without using the texture atlas. If you can the issue is definitely from the above scenario.
Another thing I noticed is that you have an odd cast in getUV():
public Vec2f getUV(final int x, final int y) {
-return new Vec2f(((float) x) / this.pixelWidth, ((float) y) / this.pixelHeight);
+return new Vec2f((float) x / (float) this.pixelWidth, (float) y / (float) this.pixelHeight);
}
Granted since it was the denominator I’m not sure it will make a difference.
Last thing I can think of is I recommend changing GL_NEAREST to GL_LINEAR (You actually might try this first as it’s easiest).
Looks line a sub-pixel accuracy issue to me. The sub-pixel accuracy on AMD is (or least was for older GPUs) lower than on nvidia. That might explain the difference.
I am almost certain it’s not a rounding error. I am getting the exact same values for all the vertices as far as I can see.
Using GL_LINEAR doesn’t help. Not only does it ruin my textures, but it also makes this issue even worse. But it also makes me think that it might be some sort of issue like you have described. I don’t know that is’s a rounding issue, but… look at this:\
I think the issue is texture bleed. I’ve run into this issue before and it’s kind of annoying.
The result you got from GL_LINEAR looks like a blend between the grass texture and whatever texture is next to it in the texture atlas, especially considering the bit of green on the side of the dirt texture. With GL_NEAREST there is no blending and so it is much less noticeable, and shouldn’t actually happen under normal circumstances. If multisample anti-aliasing is used with GL_NEAREST, some pixels on the edge of polygons are shaded with values outside of the polygon and therefore the wrong texel is sampled from the texture.
The easiest solution would be to make sure you’ve created the window without multisampling anti-aliasing, but graphics drivers can force the window to use multisample anti-aliasing, and then the problem would show up again. One time I forced Minecraft to use multisample anti-aliasing and got the exact same issue you’re seeing.
Another solution that wouldn’t show up again in the user messes with their graphics driver settings would be to not use texture atlases, probably in favor of array textures. Array textures are a nice alternative to texture atlases, but only when all your textures are the same size. They also require a layer number when being sampled, so they need more information to be used.
So I tried this:
glDisable(GL13.GL_MULTISAMPLE);
Unless that’s the wrong way to do it, it doesn’t fix the problem.
Hmmh…
Unless you’ve enabled openGLs anti-aliasing you don’t need to disable it. It’s most definitely texture bleeding though. Sadly I don’t know how to fix it because I’ve never used glTexSubImage2D(). Sorry I can’t be of more use.
That’s alright. Thanks for trying.
Honestly, I might just have to declare this as an AMD fail and move on. Maybe at least for now.