Fix core features breaking when SMAA is selected

Unreal Engine 5.7 recently introduced SMAA as an anti-aliasing option, which is a welcome addition for developers looking to serve a diverse set of user preferences for their game, or for projects/genres where motion-smear & ghosting free methods are more preferable candidates.

However many core rendering features in UE5 are tied to temporal based anti-aliasing techniques and break down visually when a non temporal method is chosen. Issues include dithered reflections, noisy shadows, unstable volumetric clouds, dithered hair, shimmery foliage due to binary alpha masks, etc. The artifacts appear because these effects rely on history samples to stabilize their output. Even Epic’s own titles (Fortnite) demonstrate these problems when SMAA, FXAA, or no AA is selected.

If Epic intends for SMAA to be a serious or viable option, there needs to be a pathway for these effects to remain stable when non-temporal AA’s are selected. One solution is to implement independent temporal denoisers for features such as reflections, shadows, volumetrics, etc, instead of forcing the denoising to only be done by the anti-aliasing process itself.

Another option is to replace certain systems with non-temporal techniques that achieve stability without relying on history data, such as a different (non-dithered) hair shader that does not require temporal accumulation for smoothing (both solutions should be utilized and decided on a case by case basis depending on which path most viable).

Certain effects in Unreal like Lumen GI already have independent denoisers enabled by default, while others need to be manually toggled on, and some lack independent denoisers entirely. Adding additional options and implementing per-effect scalability groups that automatically select the appropriate denoiser, mask, shader, or technique based on the active anti-aliasing type would significantly improve workflow and visual cohesion.

Implementing these adjustments would make spatial methods like the newly added SMAA a viable option, giving developers more flexibility by allowing them to retain core effects without compromise, and providing users who are sensitive to motion sickness a better experience without forcing them to trade comfort for distracting visual artifacts.

Temporal-based AA methods provide cheap effective anti-aliasing and workflow convenience, but they are inherently anti-accessible to a sizable portion of players (mostly motion sick related, sometimes peoples eyes feel out of focus) and it is also not ideal for every genre of game either. Therefore ensuring that alternative methods work well in-engine should be a higher priority than it currently seems to be, as it’s not a trivial issue, and one of Unreal’s goals is to be an Engine than can serve as many gamers & project types as possible. SMAA was the first step in the right direction, but it feels incomplete or almost redundant in some ways due to the current issues mentioned in this post.

These changes could make UE5 more accessible and versatile for developers and players alike, thank you for considering these improvements for the engine. I hope to see features like these come to later Unreal versions, best regards!

12 Likes

Hi, i’m sorry but i don’t reproduce anything you said.

Some shadows have some squares or lines paterns but are completly visualy stables between frames, TSR or no-AA doesn’t change anything.

1 Like

Activate Lumen & Virtual Shadow Maps - with VSMs, shadow edges are noisy

It doesn’t have anything to do with temporal AA or no-AA then.

Lumen REQUIRES temporal accumulation to work…that’s litteraly how it works no change to the engine can change it.

But you may be interested in how Robocop : Rogue City implemented lumen because it has very very low noise. There is an interesting video.

Direct comparison no-AA :

TSR Epic Native :

Shadows looks exactly the same.

To conclude it is your lack of knowledge of how Lumen and VSM works that is the issue.

No-AA and SMAA works perfectly fine.

Lumen and VSM needs temporal accumulation and works better with temporal based AA, this is not an issue this is normal and can’t be “fixed” that’s just how it works.

Edit : unfortunatly my 4K PNG screenshots are converted to low quality JPEGs so we can’t see much here.

Edit 2 : To be honest i have discovered than shadows from a certain distance are switching to lower quality and seems to be rendering at a lower rate and appears a lot smoother with TSR but that means it’s only rendering distances settings.

1 Like

If you’re going to try to roast me with passive aggresion, a) don’t because theirs no reason to be a jerk to people, and b) make sure you’re actually correct and don’t put words in my mouth.

I never said Lumen GI had an issue with TAA disabled. and I’m fully aware it has to do with anti-aliasing not temporal accumulation.

However some effects (not Lumen GI) tie their denoising algorithm to the anti-aliasing process itself, which means when something like SMAA is used the visuals break.

Here’s 3 examples of it happening in game

Flickering Shadows, Noisy VSMs, Dithered Reflections, Dithered Smoke. All present with SMAA, goes away or significantly reduces with TSR enabled because the denoising algorithm is applied by the anti-aliasing method itself instead of being independent.

3 Likes

As far as I know, the inclusion of SMAA is mostly meant for forward rendering projects and is meant to be a cheaper replacement to MSAA for those kinds of projects.

Well its in Fortnite, a deferred project, and works in DR out of the box. SMAA was created as an alternative to MSAA for deferred since MSAA doesn’t work properly. If you’re using Forward MSAA 2x isn’t expensive.

Don’t play Fortnite but I assume they’re using forward on mobile, it’s the engine default. SMAA is also listed as a mobile feature in the roadmap fwiw

Yeah, but SMAA/MSAA aren’t really meant to really be used in a game that has a bunch of features that use temporal sampling. Sure, it will still work, but it’s not going to be pretty. That’s why I said “mostly meant for forward rendering projects.”

Well you can’t use MSAA in a game with a bunch of those features because its relegated to FR. SMAA isn’t

Its intended for both. But lets look at FXAA, when it was added it was intended DR desktop (the creation of FXAA was made for DR not FR, same with SMAA)

FXAA is less accurate, and less expensive than SMAA, so if that is also for desktop, SMAA certainly is as well.

Fortnite on mobile also looks broken with TAA off as well. Their recommended AA solution is TSR. Not only for stability but also for upscaling because even on the best chipsets playing at native on mobile is hard for this game, so this line of reasoning goes out the window.

But the problem with all these commons is that they’re getting hung up on innocuous facts instead of the actual feedback which is an improvement upon the engine regardless of these factors.

Their’s no way you’re “suppose” to use this, it works in this context and it could look even better with proper support, and it would be very useful if it did.

That’s the point of the post, I don’t find it productive to try and invalidate people who choose to provide the options for PC players (like Epic did) or those wanting it to work better than it currently does.

Right, but just because SMAA can be used, doesn’t mean it should be. In this case, the game is designed around using a lot of the temporal features in various parts of the rendering engine. By not using TAA/TSR, you’re going to run into a lot of visual problems in games that were designed with them in mind.

A good alternative solution is CMAA2. It’s better than FXAA and doesn’t make the screen look like it’s completely smeared vaseline. I’d imagine there are likely CMAA2 plugins for UE5, if not, it’s a pretty simple implementation that isn’t a whole lot more complicated than FXAA. The code is readily available, if you look around.

1 Like

Not sure about volumetric clouds, hair and such. I don’t know where to find them in Fortnite :slight_smile: But some screen-space stuff is very easy to see. For example screen-space shadows (aka contact shadows) is the most noticeable effect. Unreal has a non-temporal screen-space shadows based on Bend Studio paper since UE 5.4, but they only work in the mobile renderer as far as i know. Fortnite in “performance” uses a mobile renderer but there is 0 settings provided and epic treat it like a “no graphics mode” pretty much, there is 0 shadows.

Screen-space reflections should have artifacts as well. But Fornite artstyle doesn’t really have much shiny / mirror like materials or i don’t know where to look. I don’t play the game. I could only find some large bodies of water but they have some heavy blur and wobble effect applied to them so it’s hard to see what’s going on.

It’s just a really bad mindset to say “just because you can use SMAA doesn’t mean you should” their is a large % of gamers who experience motion sickness from temporal methods. SMAA being included in your game provides eye comfort for gamers who need it, and makes your title more inclusive.

Next problem with the statement is you seem to have an attitude that theirs a correct and wrong way to do things and that SMAA is just wrong to use on desktop games, when it has its own set of pros and cons over TAA so shouldn’t be treated as inferior. It looks better than FXAA and CMAA2, so its the best spatial AA option we have at our disposal which makes it ideal in deferred rendered games where MSAA isn’t available for those who dislike or can’t use TAA

Last thing is how non-nonsensical this statement is *“the game is designed around using a lot of the temporal features in various parts of the rendering engine. By not using TAA/TSR, you’re going to run into a lot of visual problems in games that were designed with them in mind.”
*
The whole point of the post is that Epic designed these features around using TAA when they shouldn’t be attached to the anti-aliasing process itself, denoising should be done separately to maintain visual cohesion, or where non-temporal alternatives are available without noticeable quality loss we can forgo temporal accumulation entirely (DoF, Bloom & SSAO specifically for example have no real reason for depending on TAA or even needing temporal denoising, but Epic’s implementation does. Here’s an example fix created for UE4). You’re stating the problem I highlighted and suggested a fix for as a rebuttal for why its a problem, which makes it look like you didn’t read or possibly didn’t understand what you read.

I’m going to add some resources to this post to help users who are confused about the topic, and to provide implementation guidance for Epic.

  1. Implementation

Some effects can avoid temporal accumulation completely for denoising while looking and performing nearly identical to the accumulated version. (Example: Bloom, DoF, & SSAO). There are others as well but the resource I had bookmarked is no longer accessible.

For effects where temporal accumulation is required, such as when alternatives are significantly more expensive or unacceptably lower in quality, it is better to separate the denoising process from anti-aliasing so that it functions independently. This ensures consistent visuals across all anti-aliasing methods.

This is the core of my feedback. The explanation may be long, but the idea itself is straightforward. The only unconventional suggestion is that these processes should adapt dynamically depending on whether the project uses spatial or temporal AA. Unless there is a single universal solution that looks equally strong in every mode, this flexible approach would be the most effective. That is why I am recommending it.

  1. Epic vs Developer Responsibility

Making these tools available without that adaptive element still increases accessibility in the engine, but it should ultimately be the responsibility of studios to configure them once the options exist. However, as Tim Sweeney himself has acknowledged, the industry is plagued by poor practices such as attempting major optimization only at the end of development. This happens because human nature ensures that people and companies follow the path of least resistance, whether that means cutting corners, saving time, or avoiding extra effort. In many cases it is not even ignorance but deliberate strategy, therefore education & documentation alone cannot solve it.

This is why it would be a major quality of life improvement if Epic implemented this in the most convenient form possible. Much of UE5’s development has focused on making workflows faster and easier, and this proposal fits perfectly within that philosophy.

I understand it should not be Epic’s sole responsibility, both developers & Epic share some together, but the reality is that gaming has become increasingly unfriendly to accessibility, and engine creators are often the only ones with the influence to change that in a industry that’s hard to change.

If any developer wants to contact me about specific steps they can take with UE5’s current tools to better support these options, or if anyone from Epic wishes to discuss this directly, my business email is GamerEase.Business@gmail.com. Specializing in accessibility needs, especially motion sickness, and optimization consultancy. Thank you for reading .