Shimmering lines, common in menus, HUDs: Term for the artifact? And possible to "fix" with post-processing?

[xLothwenx]

Continuing my series of threads on common graphical "styles" and/or issues that bug the heck out of me, to the point where they distract from the game. See this thread for an example of a "stylistic" nuisance:

Bayonetta prominent lighting artifact's name

I've wondered about some obvious lighting artifacts in prominent games, and would like to know what this issue/effect/"feature" is called. I've never seen a single person mention it, and I've looked. First example is Bayonetta. By developer Platinum Games, they tend to create games with this...

forum.beyond3d.com

Now I want to talk about an issue with shimmering thin lines. In contrast to poor style choices, game developers often produce games with this thin-line-caused artifact which can be considered a bug, since the developer could have fixed their rendering such that it does not happen. Shimmering lines on menu/button edges is not a desired stylistic choice in the cases I'm concerned about.

The the most obvious and clear-cut example of this is the Zelda: Breath of the Wild. It's even more obvious it's a bug because the sequel, Zelda: Tears of the Kingdom, fixed it/does not exhibit the shimmering lines.

In Breath of the Wild, take a close look at the item menu boxes when scrolling. The thin lines of the boxes shimmer because they are not aligned to a pixel grid, which amounts to a small discrepancy scaling issue. Look at the similar menu item boxes in Tears of the Kingdom. They fixed it; good riddance.

Two questions:
1. What is the common term for this graphical artifact/bug I'm describing?
2. Assuming I'm not able to hack any particular game to truly fix pixel grid alignment, which is a common issue with 2D elements, can you recommend a post-processing/shader kind of solution?

I think this is a form of aliasing? One would thing some kind of very specific and targeted anti-aliasing could smear the thin line enough?

 

[xLothwenx]

Here's an example from Gloomhaven. Notice the box edges shimmering. However, neither the text nor the village below exhibit this artifact. Probably because textures usually don't have this problem; some kind of limitation of geometry (the text box):



I find this graphics bug all over games these days. Another example that comes to mind is Final Fantasy XII PS2 version's contextual icons, like when entering/leaving areas. In-game minimaps almost always have this problem, and it's a rare day to see a minimap that doesn't have this AKA looks correct.

 

[jlippo]

Term is aliasing.

Box edges are screenpixel aligned geometry and thus jump from pixel center to pixel center.

All other lines are textures with bilinear filtering, which does blend area between texel center.
This gives them ability to display subpixel movement.

There are many solutions.
Use AA which allows subpixel movement and antialiasing of geometry.
TAA, MSAA, analytic etc.
MLAA and FXAA are limited to screen resolution, so they do not help.


Change a way how boxes are rendered.
Ie.
Add transparent skirts to boxes from opaque edge pixel to fully transparent, around 1px in width or wider.

Render box with transparency and create similar edge. (In texture or shader, just make sure there is space for it .)

If background texture is known you can just blend it on top of the box at edges.

And so on.

 

[xLothwenx]

You'd think a game engine like Unity, as is used in the Gloomhaven example, would have these box types predefined so developers would have less of a chance to continue screwing it up.

 

[homerdog]

You'd think a game engine like Unity, as is used in the Gloomhaven example, would have these box types predefined so developers would have less of a chance to continue screwing it up.

It's not Unity's fault. Anti-aliasing features are built into the engine and freely available for any developer who bothers to use them. MSAA on opaque menus would be effectively free on any graphics hardware.

This article is old but very useful. I link to the page for sample based AA.

Beyond3D - Diving into Anti-Aliasing

Beyond3D 3.0

www.beyond3d.com

 

[Shifty Geezer]

You'd think a game engine like Unity, as is used in the Gloomhaven example, would have these box types predefined so developers would have less of a chance to continue screwing it up.

You have to set Unity to pixel align content - that's on the devs. Although pixel alignment is oft preferred for UIs for clarity, at which point you need art that will tackle it. In short, you're kinda blaming a hammer for making a wonky cabinet here.

(Although AFAIK Unity doesn't have a premultiplied shader which can make transparent elements like shadows a bit wonky unless addressed by a dev)

 

[xLothwenx]

Sounds like the ideal solution is use pixel alignment for stuff that needs to be pixel-aligned, like edges of boxes. But boxes, as in the Gloomhaven example, tend to want to contain textures. I think the root problem is textures need to end at some boundary, and that boundary is geometry. Geometry rasterized = aliasing at practical resolutions.

Like jlippo said, either fade your sharp box edge away into translucency, so the high-frequency edge can be sampled like a texture, or slap anti-aliasing on it. The former, anti-aliasing option has not yielded acceptable results for me...

 

[Shifty Geezer]

The art fixes it. Make the border a couple pixels thick. And/or don't scroll fractions of a pixel.

 

[xLothwenx]

The solution I'm looking for is a technical one, not "make your art such that you don't notice any artifacts." That advice isn't very helpful, especially not to artists.

Not really related, but this is the only way I'll choose to scale pixel art/emulated games because it's the only way to scale by a non-integer factor and eliminate the shimmer/aliasing:

https://themaister.net/blog/2018/08...rt-filtering-in-3d-a-mathematical-derivation/

That band-limited shader is distributed as part of Retroarch, in case anyone cares.

 

[homerdog]

The solution I'm looking for is a technical one, not "make your art such that you don't notice any artifacts." That advice isn't very helpful, especially not to artists.

Not really related, but this is the only way I'll choose to scale pixel art/emulated games because it's the only way to scale by a non-integer factor and eliminate the shimmer/aliasing:

https://themaister.net/blog/2018/08...rt-filtering-in-3d-a-mathematical-derivation/

That band-limited shader is distributed as part of Retroarch, in case anyone cares.

Are the boxes not geometry? I've definitely seen games that use MSAA on menu elements. The original DiRT from 2007 clearly did this. And the menus looked a lot better with 4xMSAA.

 

[Shifty Geezer]

For a technical solution, there isn't really one. Once a thin pixel straddles more than one line, you are either clipping it causing flickering or lerping values across pixels causing waving, the line getting thinner and thicker. The latter is the last offensive and what you'd be looking for in a post process solution. I think such a solution would need be very clever as you can't process the current frame only if there's no line visible to process. You'd need to have awareness of the graphic as it should be, identified it's not being drawn as it should be, and draw in the missing info.

Well, there's probably an ML solution with a specifically trained model but I guess that's not what you're after.

 

[homerdog]

Maybe this could be useful.

Chapter 22. Fast Prefiltered Lines

developer.nvidia.com

In this chapter we have described a simple and efficient method for antialiasing lines. The lines are prefiltered by convolving an edge with a filter placed at several distances from the edge and storing the results in a small table. This approach allows the use of arbitrary symmetric filters at a fixed runtime cost. Furthermore, the algorithm requires only small amounts of CPU and GPU arithmetic, bandwidth, and storage. These features make the algorithm practical for many real-time rendering applications, such as rendering fences, power lines, and other thin structures in games.

 

[xLothwenx]

Are the boxes not geometry?

Nothing in my post you quoted said the boxes weren't geometry, so I don't understand why you're asking this question.

For a technical solution, there isn't really one.

There are solutions suggested by others, so your authoritative statement is false.

Most importantly I want to make it clear this isn't your average everyday aliasing. This is a special case of aliasing that is particularly annoying because it's even more solvable than the general case, although the general case is also solvable. All with technical solutions, not "do art better."

 

[homerdog]

Here is a technique developed by a legendary B3Der for drawing thin lines at any distance.

Humus - 3D

www.humus.name

The idea is to adjust the radius of the wire to make sure it does not get smaller than a pixel wide. If the wire's radius would make it smaller than a pixel, it clamps the width to a pixel and instead fades with an alpha value corresponding to the radius reduction ratio. For example, if the wire is deemed to be half a pixel large at current distance, it clamps width to a full pixel and sets coverage to 0.5 instead.

 

[Shifty Geezer]

There are solutions suggested by others, so your authoritative statement is false.

Which are what? The solutions linked to so far are edge aliasing on lines in game geometry, not in post. This is thin image aliasing. MLAA and other reconstruction techniques can smooth out the jaggies in post but can't solve pixel crawl from thin lines appearing and disappearing. I'm happy to be proven wrong if there's a tech I've missed, but you asked opinions and I provided mine in relation to what I understood what you asking for, so no need to be terse. If you have a game one frame drawing a horizontal line and the next not, and want to post-effect the line back in the right place at the right thickness, there's no immediate solution to that (AFAIK). The moment you are working in game, you can pixel-align your content as I already said.

 

[JoeJ]

There are solutions suggested by others, so your authoritative statement is false.

Depends. Technical improvements are possible, but they can't solve the problem completely. As an artist you can only deal with those limits as good as possible, beside expecting only partial solutions from the tech side.
A good example is to draw a horizontal line which is one pixel thick, but the left end is one pixel lower than the right end.Even if you do 4x4 super sampling per pixel, you get only 4 shades out of those 16 samples, since only the vertical sample distirbution as an effect here. And 4 shades still cause noticeable quantization, visible to the bare eye.

Technically i would recommend to use a zero alpha border in textures, so we can filter to get more shades. But ofc. this causes a compromise on sharpness, and while mip-mapping helps, sharpness of results on different screen resolutions differs a bit. If you filter closely 50% from both texture LODs, that's no ideally prefiltered alpha. For text, using signed distance isntead alpha helps a bit, but if you operate close to the displays pixel frequency, you're always kinda fucked no matter what.
It's also often ignored in shaders that we need to consider gamma here, tweaking filtered alpha so it fits visual perception from the final display.

To do artwork better respecting those technically limitations, there are some obvious tips:
Never use lines which are thinner than 2 pixels. A dot should not be smaller than 2x2 pixels either. Smaller stuff just tends to flicker / alias / creep, which can't be totally hidden with anti aliasing methods.
Avoid lines in general, eventually use different colors or shades to make a distinction across topics. Observe results also with a slightly rotated GUI elements of 1 degree or less, just to see the tech limits / worst cases better.

 

[Shifty Geezer]

A key point not particularly clear in the OP is that xLothwenx isn't creating a game but is wanting to mod existing (retro?) titles to solve the issue (AFAICS - the intention wasn't explicitly stated, only implied in the second question). Fixing the art isn't an option when they have to use the current in-game art, and why they are getting snotty at people pointing out the involvement art has on this artefact.

 

[JoeJ]

Did not read the whole thread, but only now i see the gif animated anyway, indicating the problem is not really image quality but 'pixel snapping' under motion.

I find this graphics bug all over games these days.

It's not a bug. This is just in principle how rasterization works. A pixel is either inside the triangle or outside. (Same for raytracing - ray hits the triangle or not.) There is no 'coverage' per pixel.
So if you move the triangle downwards, a whole row of pixels jumps from outside to inside in one frame for a horizontal edge, and the quantization becomes visible.

Using MSAA should help, plus eventually rendering at a virtual higher resolution but downscaling the result. GPU drivers can enforce both. But because multi sampling is so expensive, accepting some lower quality is (or was) often the better choice.

 

[xLothwenx]

I'm not going to argue over the definition of "bug." It's obviously undesirable, as I defined in the first post. If you think that example is desirable, your system of values is incompatible with a logical discussion.

In the example, they did it correctly for some textures, but not others. Even more evidence.

If you know anything about digital signal processing, like from audio domain, you know there are mirror images AKA "aliases" of the signal beyond the Nyquist frequency. Same problems occur in video signals, it's just that video people generally are forced not to care due to performance or hang their hats on anti-aliasing compromises, because most AA techniques aren't really sound in terms of Digital Signal Processing.

Like saying you prefer car wheels spinning the wrong direction in video.

So when anyone mentions sacrificing "sharpness," you have to realize there's a good chance this "sharpness" you're trying to preserve is incorrect in terms if DSP. It should have been filtered away but never was, so although you may subjectively "prefer" the sharpness and resultant shimmer, the signal you're preferring is technically invalid.

As an extreme example, I might consider 480p upscaled to 1080p with standard bilinear as preferable to "sharpness." Obviously I'd much rather preserve as much detail as possible by rendering at a higher resolution (again "sample rate" if thinking about audio), but not at the expense of shimmering 2D elements.

A little "blur" is probably more correct.

The Gloomhaven example, even when rendering at 480p, if I remember correctly still exhibits the shimmer, with is further evidence the developers screwed up AKA made a mistake AKA it's a bug.

If some of you are developers and that offends you somehow, good. Maybe you'll improve your skills and not do it next time. At least try to use 2 pixels for your skin thickness.

 

[JoeJ]

with is further evidence the developers screwed up AKA made a mistake AKA it's a bug.

No. It just means the devs had higher priorities than fixing some pixel crawling in their GUI.

Maybe you'll improve your skills and not do it next time.

Sorry if our attempts of explaining technical reasoning and potential improvements have failed on you.
But if you don't like our stuff, you do not have to create mods for it.