I have a progress bar UI element used for my game’s health and ability systems. For whatever reason, when the UI actually renders in game, it appears very aliased.
Below is an example of what it looks like in the widget editor:
I have tried almost every idea I can think of to fix this but it is quite a resilient problem. Checked my masked materials, everything renders fine. Checked the texture itself, looks fine and is using all the appropriate import settings for UI elements. Adjusted all the relevant settings in the widget details, nothing changes. Even applied AA in an external program to the texture, yet still the aliasing remains. Not even scaling up the actual render resolution of the progress bar fixes the problem, only slightly alleviates it. Zooming as close up as you can in the widget editor still yields better looking results than the PIE viewport. Any possible ideas?
Long answer:
The typical way aliasing is reduced in textures is with mipmapping; smaller versions of the texture created by scaling it down by half several times (for example until there is just one pixel). This is then combined with trilinear filtering; blending between pixels of the various mipmap levels, depending on the size of the texture on screen.
This is a little bit trickier with UMG, because it first renders everything to an intermediate RenderTexture, which is then displayed. According to this post, mipmapping “won’t ever work while it is a render target” because the texel density is constant.
But it is unclear to me why they don’t give the option to enable mipmap generation on widgets, so they can be displayed at different resolutions. Maybe because of the potential performance cost? There is a post here by Hollowdilnik about how to go about enabling mipmapping on UMG widgets.
If you expect to display the textures at a specific resolution, it might help to author them at that resolution. As in, you could perform the downsampling in your texture editor of choice, with a nice downsampling algorithm.
Looking into it further, I found something that helped. Switching to translucency mode and using normal opacity rather than an opacity mask for the material was a good idea. This way the edges of the material I’m passing into the bars using gradiated opacity rather than a harsh cutoff. It’s still not perfect since it’s still aliased in the end, but the end result is more inline with expectations. That being said it’s still slightly pixelated around the bends of the shape, and at this point it’s probably simply the reality of not being able to directly access mipmaps or AA from UMG.
I do like the idea presented in the linked post, but I’m not sure it’s replicable which would be required for multiplayer implementations. It’s also very hacky. There was also the solution I heard of converting to a 3D rendered UI which would then inherit the post process of the scene, not sure if that’s the best route for the HUD as a whole but it would certainly solve this problem.
Ah, silly me, it didn’t occur to me it might be masked. In masked mode it’ll just cut off anything below a certain opacity (Opacity Mask Clip Value, 0.3333 by default). So any smooth falloff in the texture will just be cut off. What does it look like now?
I don’t see how a 3D HUD would solve anything, because of the lack of mimapping.
