Godot 4 Gpu Pixel Snap is missing

[Banduck]

Godot version

v4.0.dev.20211108.official [5968653]

System information

Windows 10

Issue description

Godot 3 had a GPU Pixel Snap feature in Project Settings, and that was extremely useful for 2D games.
This option is missing in Godot 4 and that causes issues like this:

Steps to reproduce

Godot 3:

Minimal reproduction project

No response

[Calinou]

The option still exists in Godot 4.0 as rendering/2d/snap/snap_2d_vertices_to_pixel and rendering/2d/snap/snap_2d_transforms_to_pixel. You probably want to enable both settings at the same time for pixel art games.

[Banduck]

@Calinou Those options are sadly not the same as Gpu Pixel Snap.
With Gpu Pixel Snap, the movement still looked smooth, while with Snap 2d Transforms To Pixel & Snap 2d Vertices To Pixel it looks choppy. It probably doesn't bother everyone, especially in a pixel game, but for those who want smooth movement (despite the pixel artstyle), it was very useful.
Also, even if I enable both, sometimes the same thing happens as in the screenshot.

[Calinou]

@Banduck Please upload a minimal reproduction project to make this easier to troubleshoot.

[Banduck]

I noticed it's probably not about Godot 3/Godot 4 but it seems to have something to do with vulkan:

vulkan.mp4

But Gpu Pixel Snap is still important imo.

Here is the project, you can move the camera with the arrow key:
Godot4.zip
(If you enable the snap options, you will also see the choppy movement.)

And for comparison the same project in Godot 3 with Gpu Pixel Snap enabled:
Godot3.zip

[lawnjelly]

I suspect that's about the texture coordinates rather than snapping (the lines in the vulkan version).

It could be reading from the neighbouring sprite, or the texture wrapping mode is wrapping instead of clamping at the edge of an atlas. I suspect it's that bottom bit of the pipe sprite, is reading from the top section.

This has been an issue quite a bit in 3.x as well. With batching there is an option to contract UVs which helps with it, and with the legacy renderer it passes the rect and attempts to clamp to it in the fragment shader, which may or may not work depending on the hardware, but also may be responsible for the problems on nvidia hardware.

The general solution that is usually used for this with texture atlases is to pad the sprites, with at least 1 pixel of edge padding that duplicates the outer border. This would be nice to automate in 3.x, and I've mentioned it before but it would need to be done client side probably @groud 's area (i.e. in the whole texture atlas system in the scene) rather than in the renderer, because it needs information as to the rects used for the tilemap in order to construct the padded version.

In 4.x I believe one plan was to move towards using texture arrays (or vulkan equivalent) rather than atlases as the cost of switching texture is much lower. GLES3 I think also supports this, but GLES2 does not, hence the need for atlases in 3.x. There may be other options available in vulkan I don't know this API.

[Banduck]

@lawnjelly I did another Test and I think it's really the texture coordinates, but somehow this problem is also solved by Gpu Pixel Snap.

I set the resolution (window width/height) 1280 x 720 and scaled the TileMap node, this makes it more obvious that it's a texture problem.
Godot 4 vulkan:

But then I tried opengl3 and the problem is still there, just not as bad.
Godot 4 opengl3:

(It looks exactly the same in Godot 3 without Gpu Pixel Snap.)

And THEN I tried it in Godot 3 with Gpu Pixel Snap enabled:

perfect.

[lawnjelly]

The reason GPU affects it is because it is caused by small precision issues in where it reads texels at the borders. The very act of GPU snapping changes the alignment of the screen pixels to the texels, and thus which texel it decides to read.

However unfortunately it does not always completely solve this - we have had numerous issues in Godot 3.x with this, even with GPU snapping. This can also potentially be hardware dependent, with some GPUs having less precision.

See for example #39256, #39096.

BTW, when reading that latter issue, I didn't realise at the time but the reason the legacy method did not suffer is that it did clamping in the fragment shader, if I remember correctly. But this turned out to be a non-ideal solution - firstly it created issues in the batching (especially having to considering increase the vertex format size to store the extra data), secondly that this was likely to cause significant slowdown / problems on some mobile hardware, and thirdly it seemed to have been associated with the artifacts on nvidia hardware.

[groud]

I think we can close this issue as solved by #54485.
Could you confirm use_texture_padding solves your problem ?

[Banduck]

Yes, thanks.

[RNwebdk]

In Godot 4, the setting previously known as "GPU Pixel Snap" in Godot 3 has been replaced with two new settings to help with pixel-perfect rendering. These settings are:

• Snap 2D Transforms to Pixel
• Snap 2D Vertices to Pixel
  To find these them navigate to your project settings,Turn on advanced settings button,, look under the Rendering tab, and then click on the 2D section

[produno]

• Snap 2D Transforms to Pixel
• Snap 2D Vertices to Pixel
  To find these them navigate to your project settings,Turn on advanced settings button,, look under the Rendering tab, and then click on the 2D section

This only seems to work correctly if mipmaps are turned off.

[ggsolbadguy]

I'm facing issues with this right now, If I enable the two snap options, the lines go away; however, I get weird problems with collision shapes with uneven sprite sizes. Does this mean I should only use even sprite sizes?

[Calinou]

however, I get weird problems with collision shapes with uneven sprite sizes. Does this mean I should only use even sprite sizes?

I suggest creating a post on the forum with a minimal reproduction project attached (this may not be a bug, but a configuration issue).