I’m building a VR game for the Quest, and mesh edges look great with 4x MSAA. However, 3d widgets have the worst aliasing ever. There must be a trick to have smooth looking UI, I’m sure I’ve seen other UE4 games where it looked great but I don’t seem to be able to find a way. Anyone know what I’m missing?
I figured it out - get the widget render target and put it on a stereo layer
1 Like
do you mind posting some visuals and how you did the widget?
I am running into the same issues when it comes to AA. I am getting black artifacts.
see screenshot below:
No matter if I change the MSAA 2x, 4x, 8x
It’s a super simple setup, just with primitive objects and I can’t figure out why it’s doing it.
VIDEO EXPLANATION:
Updated Scene File:
In my latest Project File, I added a rotating head-sculpture. I wanted to see the performance when an object is rotating. As expected, frames drop. For the rotation I am losing about -20 FPS.
DOWNLOAD PROJECT FILE Unreal 4.24.2:
My Documentation about Debugging and my Developing-Process for the Quest can be found here:
Sorry for my current mess… I am planing to structure the post soon, so people can actually follow step by step.
Another issue I am currently experiencing:
- the geometry seems to “jump” or it’s kinda “jittery”
and I can’t figure out what’s causing it, even if I am just using a plane and one cube.
Curious about your thoughts & ideas.
Thank you so much for any little hint, I really do appreciate that.
happy pixeling,
cheers
Bumping this thread for people coming here through search.
Another way to solve it is to enable mipmap generation and filtering for the render target. Not super straightforward and can be quite expensive, but is more flexible than stereo layers. Also I couldn’t use stereo layers because they are currently bugged for me and several other people.
I made a note on enabling mipmaps and filtering for UMG widgets here (also available as a plugin on github):
3 Likes
Thanks. Came here through search, after extensive search. I can’t understand why this thing is not more easily solved and/or more widely discussed/explained. Does not seem a minor issue to me 
1 Like
Ok that works, indeed. Have yet to check how much it hurts performance if I use many.
Two links that are explaining the solution in a detailed way are:
Although part at the end of Mitch’s video explanation (starting at min 9:05’) is not needed anymore as the ‘Stereo Layer Type’ parameter in the Stereo Layer component now admits “World Locked” and it appears to have been correctly implemented now.
The problem in VR is that controler 3D models, that from a 3D logic criteria should be in front of the stereo layer, because are nearer to the user, are rendered “behind” (since the stereo layer ir rendered on top of everything). To solve that, the stereo layer is apparently cutting out a part of itself with the silouete of the controller, where the controller is, so you can see it “through” the stereo layer, giving somehow the apparence that the stereo layer is behind the controller. This sophisticated behaviour comes with a handicap: this “cut” itself is a “hard” one with no antialising at all. So while the widget shows itself almost perfect now, the frontier between the controller and the widget, doesn’t. It’s much les noticeable and annoying that the widget aliasing that solves, but still not ideal.
Update. That was the behaviour with PCVR (Quest2+link).
When exporting to Quest2 (standalone),things get worse. I can’t get " Supports Depth" working correctly. It either makes the layer show a black background, or you have to deactivate the checkbox, and then you can’t see your hands or VR controllers. The problem has been reported here and here (Meta Oculus site links).
In adition, Quest Standalone shows my stereo layers clear but with aliasing. Something that did not occur in the PCVR version.
If I try to work without stereo layers (which in fact would be better for me due to the limitation in number of stereo layers allowed), I’m finding dificulties to find workflows in Unreal that allow to easily follow many of the advices given by John Carmack to reduce UI antialiasing, and also those shown in this Oculus page. Speclally regarding the use of mipmaps with 3d Widgets’ textures.
Maybe it’s because all Oculus/Meta solutions -and explanations- are more oriented to Unity, and also undoubtedly my lack of knowledge of hard coded graphic solutions play a role here, but I assumed the path should be more paved to a more friendly and optimitzed UI solution for Unreal’s VR projects. The results I’m getting so far would clearly not allow me to ship a product.
I may give a try to the proposal given by dmolchanov here on this thread (thanks for your contribution, by the way!), but that would make me plug-in dependent, since I don’t have the necessary C++ skills to do it myself. I just whish Epic Games gave some more care about this with “out-of-the-box” straighforward sollutions. VR is slowly back in its growth track, and good quality 3D UIs will necessarily have a role in future apps and games.
1 Like
I don’t think there is any way to set everything up well without enabling mipmapping form C++. The modification to the class is very simple, it’s a shame Epic hasn’t implemented it yet.
The article mentions using shader based supersampling, which can be done in Unreal through the material editor. I’ve implemented it and it is an significant improvement over regular mipmapped. I think it still needs mipmapping enabled to give any benefit though.
200% zoom, stock on left, mipmapped on center and mipmapped + RGSS on right
The link above lets you copy the code into a material blueprint.
5 Likes
That’s great, thanks! I’ll definitely give it a try.
Done. It already gives some result, removing aliasing on Quest. But yes, as you already said, I supose it still needs mipmapping to be really useful (I applied it directly as an experiment and the result is better than the original, but a bit too blurry).
1 Like
I finally got around to trying this out…Amazing!!
It completely removed all of the aliasing and didn’t soften the text as much as I feared.
1 Like