godot
godot copied to clipboard
godotengine
MSAA turned on makes Gridmap tiles seams visible
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
Also happens on mesh edges, maybe related to unfiltered textures?
I have a repo here with a demo: https://github.com/Worgames/superspacearcade_godot
There is a cell_scale property you can use, with some values like 1.001 that will get rid of these problems.
Try disabling Compress on the import settings of your .dae and re-generate the MeshLibrary. That did the trick for me.
@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.
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.
@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
@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?
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:
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?
@TomWor Is the issue lessened if you slightly expand/shrink your meshes but keep the textures at the same size?
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.
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: 7f56ef365, same results for both.
Updated with a screenshot:
@EzraT Is the issue lessened if you slightly expand/shrink your meshes but keep the textures at the same size?
@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.
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.
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.
Try adding a green plane (with the same color as the grass) below the GridMap floor to make the seams less visible
Thanks for the suggestion! I just tried that out, as well as making a plane that just barely sticks out near the top of the grass tile in the MeshLibrary itself, and unfortunately it doesn't seem to have had any effect.
Here is the size of the plane I used just beneath the GridMap (changed to blue to show that it stretches across most of the GridMap.)
With the top face of ground level tiles in the GridMap being at Y coordinate 2.0, I changed the plane to be the same color as the grass, and moved it to Y 1.999, and I'm unfortunately still able to see seams. (You can see where the plane ends when its just underneath the GridMap tiles at the top of the picture)
This is very probably due to precision issues due to floating point error in the matrix math. Normal rendering hiding it and anti aliasing showing it up. I seem to remember answering a similar problem for the voxel addon guys a few months ago.
As reduz says, aside from merging vertices, a common solution is adding a small increase in scale for each element, although it has to be applied in the right way (relative to the element centre, not simply a global scale). I'll have a look in the source just to check it's being applied correctly.
Edit: Scale does seem to be set correctly, in the local basis. (unless there's a place in gridmap I missed)
Reproduction Project: msaa_seams.zip
Very obvious seams, only when MSAA is enabled.
In this project the seams look due to texture filtering. You need padding if you are using texture atlas.
Just to clarify - you need padding even without filtering, because of precision error on borders. You can also contract the UVs a little as @randomness128 suggested, this is what we do in GLES batching for the same problem (uv_contract).
There may be 2 problems being discussed here. For UV / filtering issues the above are some solutions. For geometry seams, scaling should help.
Depending on how common the particular workflow is, it is sometimes possible to automate adding padding to atlases and modifying UVs. But I'm not familiar enough with gridmap to give any opinion on this.
After doing some research on MSAA and how its handled, as well as re-reading randomness128's suggestion after lawnjelly referred back to it, I wasn't able to entirely remove the seams, but they're much, much less noticeable.
Each face of our cubes were 64x64 pixels, and they were stored in one UV map making the entire albedo map 128x128. We initially tried adding a single pixel border around the textures, and adjusted the UVs to be within that 1 pixel border. For some reason this seemed to actually make the seams even more noticeable (at least on 2x MSAA)
But when we added a 10 pixel border around the entire albedo map, and reassigned the UVs to wrap the initial 64x64 textures we've gotten this instead.
(side note, the remainder of the seams near the player are still present because the padding hasn't yet been applied to all tiles in the mesh library)
Here is a comparison of how our original and padded albedo map looked to get our results in case anyone stumbles upon this issue in the future.
The seams are still slightly visible in the top left corner of the world, but I think this should suffice. 😄 Worst case we can add a bit of a vignette or some sort of post processing to help cover up the remainder of it.
As a separate suggestion:
I'm not very familiar with the specifics with modern OpenGL, but would it be possible to have a GL_CLAMP_TO_EDGE type flag for materials to somewhat emulate this padding effect? I'm unsure if that would positively affect the MSAA, but it seems like it could help with it grabbing similar colors when it tries to sample outside of the UVs.
As a separate suggestion:
I'm not very familiar with the specifics with modern OpenGL, but would it be possible to have a GL_CLAMP_TO_EDGE type flag for materials to somewhat emulate this padding effect? I'm unsure if that would positively affect the MSAA, but it seems like it could help with it grabbing similar colors when it tries to sample outside of the UVs.
Unfortunately CLAMP_TO_EDGE only works for the absolute edges of textures, so won't help with texture atlases (it can help with non repeating regular single textures though). Texture arrays can also be used to solve this instead of atlases, but they aren't available in GLES2.
We initially tried adding a single pixel border around the textures, and adjusted the UVs to be within that 1 pixel border. For some reason this seemed to actually make the seams even more noticeable (at least on 2x MSAA)
Also note texture compression can affect this. Texture compression tends to work in blocks (I believe 4x4 is common) and if your atlas edges span a block this can result in artifacts on edges. Using uncompressed textures or better still avoiding these edges can help here.
i.e. If you original atlas tiles were 64x64, make them 68x68 including 4 texels of padding, giving 8 texels between the actual tiles (or use 8 texels of padding etc).
Also for 3d, you should consider the effect of mipmapping. Mipmaps are made at 1/2, 1/4 etc sizes of the original texture and are shown as you move further from the texture. So padding which might be ok up close may still end up showing seams as further mipmaps are shown. The solution to this is to increase the padding to take account of it (obviously there's a limit, as the furthest mipmap could be just 1 texel!).
It's possible to clamp UV coordinates using a shader, but this has a performance cost. See also https://github.com/godotengine/godot-proposals/issues/651.
Like for https://github.com/godotengine/godot/issues/35067:
Would centroid sampling be able to alleviate this? I don't know if it's available in GLES3 though. If it's likely limited to desktop OpenGL only, would have to be conditionally added on shaders on desktop platforms only (which would add a fair amount of complexity).
Centroid sampling is definitely not available in OpenGL 2.x/GLES2.
More information on centroid sampling: https://www.rastergrid.com/blog/gpu-tech/2021/10/multisampling-primer/#:~:text=be%20aware%20of.-,texture%20sampling,-We%20talked%20about
One of these three solutions provided by clayjohn and lawnjelly may fix this issue. https://github.com/godotengine/godot/issues/35067#issuecomment-1058617216
I have recently encountered this issue in 3.5.1. I'm using models made in MagicaVoxel, then processed in blender to reduce geometry. Seams on tiles are bad enough, but I'm also getting this on more complex objects (like ruined buildings) placed on map, and it is quite jarring. Since those are quite complex, padding the texture is not an option for me, it would take dozens of hours of manual work.
What is more interesting to me is that even with MSAA disabled, I am still getting this issue, although way, way less. I think the bug might actually not be linked to MSAA, and it only makes it more visible.
I'm also getting a similar issue, and it's quite bad on lower resolutions.
Edit: this is on Godot V4 Stable
