Visible seams between GridMap tiles (sometimes only with MSAA enabled)

[ghost]

Is hard to see. You need to open the image full size. There are no visible seams with MSAA Disabled but with 2x or higher I start seeing seams and edges of 3D meshes.

My guess is the texture or mesh is shrunk by a small factor in order to produce the edge aliasing.

I use a Gridmap is a cell size 1 , 1 , 1 and the tiles are all designed to be exactly 1 x 1 x 1 and the UV maps are made exactly to the dot for 64 x 64 textures.

This is on latest Godot 3.0 release

[TomWor]

Also happens on mesh edges, maybe related to unfiltered textures?
I have a repo here with a demo: https://github.com/Worgames/superspacearcade_godot

[reduz]

There is a cell_scale property you can use, with some values like 1.001 that will get rid of these problems.

[reduz]

Maybe we should document this better?

[Bauxitedev]

Try disabling Compress on the import settings of your .dae and re-generate the MeshLibrary. That did the trick for me.

[TomWor]

@reduz cell_scale is only relevant to grid map right? I have the same issue on an imported dae mesh.

@Bauxitedev I deleted the generated meshes, removed the "compress" attribute from the import settings and reimported the mesh - sadly, the issue remains.

[randomness128]

Are you using a texture atlas? With MSAA, the primitive doesn't have to cover the center of the pixel to be visible, but shading is calculated at the center of the pixel regardless. This can cause interpolated vertex attributes (such as UVs) to instead be extrapolated for a point slightly off the edge of the primitive. This is an issue with MSAA in general, not Godot. Try moving your UVs slightly inward so extrapolated UV coordinates will still use the same texel.

[reduz]

@Bauxitedev I disabled vertex compress by default because many were having issues with it, left compress of other stuff

@TomWor If you are using a recent master, i fixed this by disabling vertex compression by default

[TomWor]

@reduz Would love to test, but my current build of master closes the game window instantly on play. Works fine with the current 3.1 alpha though (not counting the MSAA issue).
Should I even open a bug for this as it's master and no official release?

[bojidar-bg]

What is the state of this issue?

[EzraT]

This still happens for me using 3.1 Beta 10, using a texture atlas and uncompressed meshes.
The seams only appear when MSAA is enabled, doesn't matter what level.
I tried adjusting the cell_scale property in my GridMap, but it does not get rid of the seams, it only introduces slight, (but still noticable) clipping issues.

UPDATE:
No MSAA:

MSAA:

[TomWor]

I think I can confirm that @randomness128 is right at least about the issue I'm facing.
I'm using a texture atlas and because of the nature of it (voxel-style, nearest neighbour) the pixels bleed over. I exported the same model with vertex colors and the problem was gone. (which sadly is not a solution for me because it yields to many vertices)
I also want to mention that this doesn't happen in Unity, their MSAA algorithm must do something different.
Maybe the problem happens because the texture atlas doesn't repeat itself at the edges or something?

[Calinou]

@TomWor Is the issue lessened if you slightly expand/shrink your meshes but keep the textures at the same size?

[akien-mga]

Does this still happen in latest 3.2 builds? If so, does it happen with both GLES2 and GLES3?
Finally, if you can reproduce it, please upload a minimal reproduction project that shows the issue.

[EzraT]

Reproduction Project:
msaa_seams.zip

Very obvious seams, only when MSAA is enabled.
Tested in both GLES3 and GLES2 using 3.2 beta 5, and a nightly build: 7f56ef3, same results for both.

Updated with a screenshot:

[Calinou]

@EzraT Is the issue lessened if you slightly expand/shrink your meshes but keep the textures at the same size?

[EzraT]

@Calinou No, not really, as far as I can tell that just introduces more problems, z-fighting flickering or physical seams between the meshes, along with the texture seams discussed here.

[AlexFlasch]

I'm unsure if its related, but I'm also getting some jittery artifacts along seams only with MSAA disabled. I'm hesitant to report this example as an actual issue, as I haven't ruled out external causes (assets, GridMap settings, Camera, etc) for the odd artifacting displayed here. You can see it here just to the left of the player.

The seams become permanently visible with MSAA enabled very similarly to examples that have already been provided.

Both the video in the link above as well as the attached image were taken while running 3.2.3.rc1 on win10 with a GTX 1080 Ti.

My GridMap settings in the attached media have a cell size of Vec3(2, 2, 2), and cell scale of 1.

Our game intends to make fairly heavy use of the GridMap node, so this is a bit of a sticking point for us.
Has anyone else with this issue found any workarounds that can help mitigate the issue?

We've tried slightly increasing cell scale to 1.001 as well as modifying cell size by small increments as well, but unfortunately they didn't seem to help.

[Calinou]

Has anyone else with this issue found any workarounds that can help mitigate the issue?

Try adding a green plane (with the same color as the grass) below the GridMap floor to make seams less visible.

[Zylann]

Both issues occurred when someone tried MSAA in my Minecraft-like demo:

• Atlased textures show seams everywhere
• Gaps become visible between every face that cannot share vertices (way too common to be negligible)

The error renders the same size in screen space, so if a correction were to be done, it would have to support all view distances by not looking weird at close range and not happening again when far away.

In my case this happens within the meshes, which are chunks of voxels, where voxels are not necessarily cubes and can have been UV-mapped in Blender, so finding an easy algorithm to automate a fix that would work at any view distance doesn't sound straightforward.

[elvisish]

I'm having this problem a LOT:

What's the current workaround to minimize seams?

[Calinou]

What's the current workaround to minimize seams?

Several workarounds are mentioned in the above comments, outside of disabling MSAA and using another antialiasing solution.

[elvisish]

What's the current workaround to minimize seams?

Several workarounds are mentioned in the above comments, outside of disabling MSAA and using another antialiasing solution.

I'm not using MSAA and I can't using antialiasing as it's a retro game. I'm using gridmaps with MeshInstance boxes that are 1 * 1 * 1 and use ShaderMaterials, not atlases. It only happens really when I move around, is there a fix for this?

[J0Beck]

I had a similar issue, I tried rotatin the gridmap along the y axis a couple of degrees and that helped reduce the number of lines

[BurningFluffer]

I have this too. The meshes are made with perfect snap in blender, but gridmap often places them with gaps. Disabling MSAA did not help. Scaling also doesn't help, since that straight up makes the planes missalign, though I would expect them all to remain centered - is the problem with how GridMaps determine cell center?
Edit: Nvm, scaling my meshes would make them missalign, but expanding them in proper directions in Blender also didnt help. It seems to be an issue with rotation - quatornions are very impercice. Do they use trigonometry or just +- flips on axis? I imagine the latter would not have as much inpercision.

[CammiePone]

Can confirm that it's still a problem on 4.2.1. I haven't tested 4.3's rcs yet, so I don't know if a change there may have magically fixed it. I've tried everything people have suggested here and nothing really fixes it, or even noticeably reduces its effect

Hopefully this can get figured out and fixed soon

2024-03-03.11-09-31.mp4

[BurningFluffer]

I've discovered that there was a issue with blender that was causing it in my case. Even if based on the default cube and snapped to it, verteces are NOT in perfect positions. Instead, each vertex should be given position manually in the tool tab (key N to see). Assigning them manually fixed it in my case.
However, Kinematic character is unable to slide down without periodically hopping, unlike sliding in any direction that isn't same as gravity. Idk if that's gaps, or just a issue with GridMap+Kinematic body.

[CammiePone]

I wish i could say it was a blender issue for me, but it's also visible on the default box mesh made in Godot itself

[CammiePone]

so a friend of mine has discovered something that might help with fixing this. apparently this occurs only when the meshes that are next to each other have side-facing geometry. if i just have a plane, this doesn't happen

[elvisish]

so a friend of mine has discovered something that might help with fixing this. apparently this occurs only when the meshes that are next to each other have side-facing geometry. if i just have a plane, this doesn't happen

Thanks, I use plane meshes to cover up the worst looking of these that occur, but for games built with cubes with sides that are darker/lighter or have different textures the problem still remains.

[BurningFluffer]

apparently this occurs only when the meshes that are next to each other have side-facing geometry

It feels like that kinda forces the marching cubes approach, where there is only the geometry actually needed for the total shape. I suppose the cubes need to be separated into individual planes, and you combine planes instead of blocks. Would definately make it more of a hassle.

[robbyph]

I am experiencing this issue in Godot 4.2.2

I am using a texture atlas on my gridmaps, however, I am not using MSAA of any kind, and MSAA is completely disabled. The gridmaps use a MeshLibrary (.tres) created in Godot based off of a .glb file exported from Blender. These meshes in my gridmap snap together perfectly fine in Blender, but not in Godot.

If it would be helpful, I used this tutorial here. He even mentions this issue with the gaps at the end of the video.

I have tried:

• Changing the cell scale, but that created more issues that it solved, with weird bleeding and clipping
• Turning MSAA on, has the same issue regardless of if MSAA is present or not
• In Blender, all normals are facing the proper direction
• In Blender, all origins are at the correct location

I've also noticed that most of these artifacts are most visible at the periphery of the Player's vision, as you can see in the attached images. It's really most noticeable though, when the player is moving around.

[Calinou]

I am using a texture atlas on my gridmaps, however, I am not using MSAA of any kind, and MSAA is completely disabled.

This is an unrelated issue, and one that will happen on any real-time engine that uses mipmaps for rendering. You need to add padding between the textures in the texture atlas so that mipmaps don't cause different textures to blend together. How much padding you need to add depends on the individual tile size, but typically, you want at least 4 pixels on each side. These pixels should repeat the base texture as usual (or at least use the average color of the texture).

You can troubleshoot whether mipmapping is the cause by disabling mipmaps on the atlas texture in the Import dock. This will cause textures to become grainy at a distance, but if the cause is indeed due to the texture atlas, the lines should be gone.

[robbyph]

You can troubleshoot whether mipmapping is the cause by disabling mipmaps on the atlas texture in the Import dock. This will cause textures to become grainy at a distance, but if the cause is indeed due to the texture atlas, the lines should be gone.

I tried disabling mipmaps on the atlas texture, however, the lines are unfortunately not gone.

[Calinou]

Do lines disappear if you switch the material filter mode to Nearest in the BaseMaterial3D properties? (If the material was imported from Blender, you need to change the filter mode in Blender, or assign an external material from Godot.)

[robbyph]

Do lines disappear if you switch the material filter mode to Nearest in the BaseMaterial3D properties? (If the material was imported from Blender, you need to change the filter mode in Blender, or assign an external material from Godot.)

That was it! I had my stuff set to cubic, rather than Closest, which is what I believe it's called in Blender. After switching to Nearest there are no gaps!

If you wouldn't mind, could you explain to me a bit further why changing the filtering mode to Closest fixed this? I assume it has something to do with the atlas and the bleed you said before?

Additionally, I was using the Cubic filter in order to make my texures blurry and not so pixelated. Is there a way to have both?

[Calinou]

If you wouldn't mind, could you explain to me a bit further why changing the filtering mode to Closest fixed this? I assume it has something to do with the atlas and the bleed you said before?

This is still due to a lack of padding between tiles in the atlas. When you use linear filtering, the edge of each tile will read from the nearest four pixels for linear interpolation. On each edge, two of those pixels will be from a different tile, possibly with a color that is very different. This is what leads to the visible line on tile edges.

Additionally, I was using the Cubic filter in order to make my texures blurry and not so pixelated. Is there a way to have both?

Yes, you need padding on the edges of your atlas tiles.

[robbyph]

Yes, you need padding on the edges of your atlas tiles.

How can I do this without losing the ability to "tile" my gridmap pieces, so that they line up with the texture of the next gridmap over? I think I might be misunderstanding how to do this. I appreciate your patience with me, I have to apologize, I'm very new to Godot, and Blender for that matter.

[pineapplemachine]

I'm having a similar issue with v4.3.stable.mono.official [77dcf97d8], but with just boxes placed in a grid without the use of a GridMap, with MSAA and all antialiasing turned off, and all unshaded materials without any lighting or shadows. But it is occurring only for the Mobile and Compatibility renderers, not for the Forward+ renderer, and it's showing up when using either an orthographic camera or (especially) a perspective camera with a low FOV.

For example, with a perspective camera and low FOV (5 degrees):

Mobile:

Forward+:

There's some more comments and media in a Twitter thread here: https://x.com/PineMach/status/1841918893478273349