Godot: Anti-alias in 2D

Created on 11 Nov 2017  Â·  26Comments  Â·  Source: godotengine/godot

After looking at those issues: https://github.com/godotengine/godot/issues/10241, https://github.com/godotengine/godot/issues/7242#issuecomment-343637952

I saw that Godot supports anti-aliasing using MSAA, but I was surprised that this is only active in 3D. I tried to set it to 2x, 4x, and I saw a neat difference in 3D viewport, but none in 2D (using Line2D or Polygon2D to test it).
image

Could it be made optionally available in 2D too?

Note: not sure if I should have posted in the first old issue rather than creating a new broader one

archived feature proposal rendering

Most helpful comment

I guess I can't expect anti-aliasing for 2.1 ever? (Sorry for late comment/bump)

I've been making a 2D game with high resolution for year in 2D, almost done. But this issue has always kinda disturbed me but I wanted to find solution later. Looks like there is no solution yet to avoid this sharp razor points on 2d like Anti-aliasing?

What can I do best to have anti-aliasing effect on 2D sprites?

All 26 comments

It should be possible to enable it in 2d eventually...

On Nov 11, 2017 2:22 PM, "Marc" notifications@github.com wrote:

After looking at those issues: #10241
https://github.com/godotengine/godot/issues/10241, #7242 (comment)
https://github.com/godotengine/godot/issues/7242#issuecomment-343637952

I saw that Godot supports anti-aliasing using MSAA, but I was surprised
that this is only active in 3D. I tried to set it to 2x, 4x, and I saw a
neat difference in 3D viewport, but none in 2D (using Line2D or Polygon2D
to test it).

Could it be made available in 2D too?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/12840, or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z25sBGIpu21KOxXE6e4xFd5RphK0Lks5s1dfUgaJpZM4QakBs
.

May be added for 3.1? A bone-animator friend can't start using Godot because of this

Yeah, should be tagges for 3.1

On Dec 22, 2017 11:48 AM, "Igor S." notifications@github.com wrote:

May be added for 3.1? A bone-animator friend can't start using Godot
because of this

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/12840#issuecomment-353611927,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2yFEapfSFHqSHsMqffAhDz_HFWZ-ks5tC8EggaJpZM4QakBs
.

@icnikerazah we had to cut the feature addition at some point :( you will have to wait some weeks.

I also realized that some other games (like Terraria I think?) support anti-alias on pixels themselves, so pixel-art with uneven zooming levels can also benefit from it.

Here is how it looked on a prototype I made some years ago (even more relevant with movement):
supersampling

well, you can always supersample yourself by allocating a twice as big
viewport and scale it back, might still work fine for 2D

On Thu, Jan 4, 2018 at 7:05 PM, Marc notifications@github.com wrote:

I also realized that some other games (like Terraria I think?) support
anti-alias on pixels themselves, so pixel-art with uneven zooming levels
can also benefit from it.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/12840#issuecomment-355412317,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z21ShtRpraA2oeNNApI5wcRSl_Uw-ks5tHUsegaJpZM4QakBs
.

@reduz isn't it what AA is doing in 3D currently?
Also that superscaling would need to be done via script I guess, but that could also screw up GUI because everything suddenly becomes way bigger than what the reference the game was made for, even when using responsive anchors it would need to scale (so... more work than it seems!)

@Zylann No, not really, if your scaling is done properly, you should need to touch zero game code.

@reduz from what I've tried so far, GUI doesn't scale. By that, I mean it does RESIZE, but doesn't scale to appear the same with resolution unless you find some magical code to do so (it's about font size, amount of text shown, texture appearance etc)... or maybe I miss something? (on top of that, my UI is in a CanvasLayer for the purpose of being scaled up to get that pixel look, which already had issues because anchors don't play with the correct viewport size, so had to add an additional container... that could link to several other issues tbh)

@reduz isn't it what AA is doing in 3D currently?

No, Godot just tells the OpenGL driver to enable MSAA for the viewport (which can be done without restarting the engine). Rendering everything at an higher resolution then scaling it down is called SSAA (super-sampling), and is a much slower method of anti-aliasing (but it's technically the nicest-looking).

There's a cheaper way to provide AA for lines by using distance fields, it's also more flexible as you can control the AA radius and can add more features like outline, configurable line caps/joins or dashed patterns.
If someone can guide me where I can find the current implementation(geometry generation, shaders, testing) I can start working on it, as it will require some new attributes for the geometry and new shaders.

@tuxalin The Line2D drawing code is in https://github.com/godotengine/godot/blob/master/scene/2d/line_2d.cpp#L226, but it's far from being the only thing that needs AA. You might open another issue for this because although it could provide AA too, it's a different feature.

The problem with AA in the line code is that NVidia has decided to not
support Line AA, even though it's dictated by specification. I still have
to try other approaches to do AA, but there is no more time for this for
3.0. If anyone wants to propose soemthing in the meanwhile, feel free.

On Fri, Jan 5, 2018 at 9:31 AM, Marc notifications@github.com wrote:

@tuxalin https://github.com/tuxalin The Line2D drawing code is in
https://github.com/godotengine/godot/blob/master/scene/2d/line_2d.cpp#L226,
but it's far from being the only thing that needs AA. You might open
another issue for this because although it could provide AA too, it's a
different feature.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/12840#issuecomment-355544301,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z23sCVqdsR7Kvn-i36H9r2TZYIGmZks5tHhYlgaJpZM4QakBs
.

@Zylann , thanks for the info!
I've looked over the code and it's a bit more work than I expected, so yes it wont make for 3.0.

The whole line generation needs to be rewritten as I see it use a basic shader(with position, color and uv attributes) and optional textures. The distance field approach is purely vectorial and no textures will be required(except if you want custom patterns) and will require different attributes(position and tangents, 3 floats), it'll also require several shader variations.

@reduz , regarding AA, if you mean line primitives, then yes, those are legacy left from the fixed pipeline and some vendors chose not to offer AA support(GL_LINE_SMOOTH) for them, especially that you can write your own line shaders designed for your use case.

If wanted I can make another issue for this, however without distance fields you're left few approaches(tried them before) that wont achieve the same AA quality or flexibility, and MSAA will be expensive until the quality is good enough(guessing 8x).
If you're interested on the approach I propose check out this paper: https://hal.inria.fr/hal-00907326/file/paper.pdf

I guess I can't expect anti-aliasing for 2.1 ever? (Sorry for late comment/bump)

I've been making a 2D game with high resolution for year in 2D, almost done. But this issue has always kinda disturbed me but I wanted to find solution later. Looks like there is no solution yet to avoid this sharp razor points on 2d like Anti-aliasing?

What can I do best to have anti-aliasing effect on 2D sprites?

This is difficult to do in GLES3, so will implement in GLES2 and Vulkan in 3.2, kicking there

Fonts use AA just fine so it IS working... but then again it doesn't seem possible to turn that OFF either (yes, with a ttf font... and yeah likely unrelated).

Fonts are rasterized by FreeType, they are not seen as polygons by Godot (in other words, they're just textures).

Also, it's possible to disable antialiasing in DynamicFonts since 3.1 alpha 3 :slightly_smiling_face:

commenting cause this I think this will help with polygon2d holes in zylann's heightmap mask when it's eventually realized.
https://github.com/Zylann/godot_heightmap_plugin/issues/73

Is-there something plans on this for 4.0/Vulkan (or a workaround in 3.2)? I'm faced the same issue, a non-pixel art game (using high res sprites) with ugly pixel edge.

(@Qws have you find a workaround?)

@fab918 Depending your needs, you could use a Line2D node with a pre-made texture whose top and bottom edges are transparent, like the one below. It's streteched to 256×16 for demonstration purposes, but you could crop it to 1×16:

line.png

Make sure the Filter flag is enabled on that texture (in the Import dock). You can achieve the same kind of effect with any 2D texture that touches a rectangle's border (so it's not just for line drawing).

@Calinou Thanks for your answer, maybe I misunderstood the topic of the thread (sorry if it's the case).

I don't use Polygon2D, I just want to apply the anti-aliasing filter in the 2D viewport because I have sprites with "staircase effect" (which I don't have in my photo editor, see here).

I tried to increase the resolution of sprites (and tried import presets) but that not solve the issue, I assumed that could be the 2D antialiasing.

@fab918 Seems like your texture was imported with Filter disabled, as @Calinou mentioned. That's not related to anti-aliasing.

Duplicate of #10241.

@akien-mga No, the other issue is only about lines and polygons. Take "screen-space shaders" example, rotate the picture, and there is aliasing at edges:

aa_broken_2d_godot

Though maybe the other issue is duplicate instead, and this one is more broad.

Note that this feature is planned in some way for Godot 4.0.


Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!

Was this page helpful?
0 / 5 - 0 ratings