What is this blog post series about?

When we made FSR 2.1 available, we also updated our FSR 2 Unreal Engine plugin. This update not only brings significant improvements to the plugin generally, but we’ve also provided two patches with the package which can increase visual fidelity. FSR 2.2 further improves the plugin and adds Unreal Engine 5.1 support.

This five part blog post series – this is the first part – highlights the issues these patches address, and how you can use them in your own Unreal Engine projects.

→ Part 1 – Improving foliage appearance: Introduction and using the base pass for velocity generation.

Part 2 – Improving foliage appearance: Improvements via content changes.

Part 3 – Improving foliage appearance: Applying the ImproveStaticWPO patch.

Part 4 – Making materials reactive: How to make a specific shading model write to the reactive mask.

Part 5 – Making materials reactive: Applying the LitReactiveShadingModel patch. 

Introducing part 1

Here in part 1, we discuss how to improve foliage appearance, and one of the ways this can be achieved by using the base pass for velocity generation.

Improving foliage appearance

Within Unreal Engine, one of the most common ways to animate foliage is to use World Position Offset (WPO) within a material to add gentle motion to the geometry without having to resort to full animations and Skeletal Mesh rendering. This animates each vertex directly and by default won’t generate any motion vectors unless the object is itself moving.

For upscalers such as FSR 2, this can result in sub-optimal upscaling results as the algorithm cannot interpret the motion of the foliage, resulting in ghosting as history samples are weighted incorrectly. The FSR 2 plugin can enable the console variables r.VertexDeformationOutputsVelocity (UE 4.27 or earlier) or r.Velocity.EnableVertexDeformation (UE 5.0 or later) which force such materials to write the motion vectors, provided the object the materials are used on meets the criteria to be evaluated.

For Unreal Engine 5.0 and earlier, there is an optimization that skips the calculation of motion vectors for objects set to Static mobility as they are not expected to move or animate. For Unreal Engine 5.1 and later, objects will default to evaluating World Position Offset unless it is disabled by the developer.

For the default upscaler in Unreal Engine, this is not typically a noticeable issue as the algorithm is tuned to handle such small motion as provided by WPO. However, FSR 2 is much more sensitive to both the presence and fidelity of motion vectors provided by the game.

For Unreal Engine 5.0 and earlier

It is therefore necessary to either:

  • Change the project to enable the r.BasePassOutputsVelocity engine setting.
  • Change the object mobility in the editor, and modify the material to force generation of motion vectors.

Enabling r.BasePassOutputsVelocity forces velocity generation to occur in the base pass rather than as a separate pass, and the FSR 2 plugin enables r.BasePassForceOutputsVelocity to ensure that all objects render velocity to avoid these issues. However, this does increase the GPU work for all objects regardless of whether they use a WPO material.

To make it easier to achieve the optimal result the FSR 2 plugin now includes the ImproveStaticWPO.patch which modifies the engine to automatically generate motion vectors for all objects using a material using WPO regardless of mobility setting.

For Unreal Engine 5.1 and later

The r.VelocityOutputPass console variable controls which pass generates velocity data. It defaults to rendering velocity during the base-pass which is preferred for FSR 2.

It is no longer necessary to patch the engine to ensure objects render velocity for World Position Offset materials. Developers should avoid enabling the r.OptimizedWPO console variable. If r.OptimizedWPO is enabled, ensure bEvaluateWorldPositionOffset remains enabled on mesh components that use World Position Offset materials in the editor to have them generate velocity data.

Example

‘A Boy and His Kite‘ in Unreal Engine 4.27

TAAU FSR 2.0.1

Close up 1:1 pixel view: (screenshot is JPEG @ 85% compression)

TAAU FSR 2.0.1

When using FSR 2 by default, the grass nearest the camera appears blurred.

The FSR 2 plugin already enables console variables r.VertexDeformationOutputsVelocity (<= 4.27) or r.Velocity.EnableVertexDeformation (>= 5.0) to force WPO materials to render velocity but visualising the velocity data (below) shows that these objects do not render velocity.

Unpatched UE4 4.27 velocity data

TAAU FSR 2.0.1

Improvements when outputting velocity during the base pass

This project enables the r.BasePassOutputsVelocity setting by default which means that velocity data is written during the base pass. This changes the engine’s behavior slightly and allows the FSR 2.1 plugin to also enable the r.BasePassForceOutputsVelocity setting which then emits velocity data for all objects on screen and ensures that FSR 2 has the motion vectors required.

Unpatched UE4 4.27 FSR2.1 - Velocity inset
Unpatched UE4 4.27 FSR2.1 - Velocity inset

For projects already using r.BasePassOutputsVelocity this is now the default behavior and will ensure optimal quality by default. However, this does increase the GPU work required as now all the objects are emitting velocity even when they might not need to.

Projects that are not already using r.BasePassOutputsVelocity but that use a lot of materials with World-Position-Offset should consider enabling this setting and profiling as in many cases this will work sufficiently without requiring significant investment.

This is the simplest option when using the binary version of the editor.

Coming up next

Continue reading in part 2 to find out how to address some of these issues via content changes rather than relying upon r.BasePassOutputsVelocity or the source code patch. When using the binary version of the editor, making content changes is the only other option to improve quality as the the patch requires modifying the Unreal Engine code.

Alternatively, feel free to skip ahead to one of the other parts:

Part 1 – Improving foliage appearance: Introduction and using the base pass for velocity generation.

→  Part 2 – Improving foliage appearance: Improvements via content changes.

Part 3 – Improving foliage appearance: Applying the ImproveStaticWPO patch.

Part 4 – Making materials reactive: How to make a specific shading model write to the reactive mask.

Part 5 – Making materials reactive: Applying the LitReactiveShadingModel patch. 

Get the Unreal Engine FSR 2 plugins now!

The package linked below contains the latest version of all our currently available UE 4/5 plugins [~600MB]

  • Includes the patches referred to in this blog series.
Download FSR 2 Unreal Engine plugin

Find out more about FSR 2 and our Unreal Engine plugin

Learn more about FSR and Unreal Engine

Unreal Engine

Develop for Unreal Engine on AMD hardware with our plugin, performance and feature patches, including FidelityFX support.

FOOTNOTE:

The information contained herein is for informational purposes only, and is subject to change without notice. While every precaution has been taken in the preparation of this document, it may contain technical inaccuracies, omissions and typographical errors, and AMD is under no obligation to update or otherwise correct this information. Advanced Micro Devices, Inc. makes no representations or warranties with respect to the accuracy or completeness of the contents of this document, and assumes no liability of any kind, including the implied warranties of noninfringement, merchantability or fitness for particular purposes, with respect to the operation or use of AMD hardware, software or other products described herein. No license, including implied or arising by estoppel, to any intellectual property rights is granted by this document. Terms and limitations applicable to the purchase or use of AMD’s products are as set forth in a signed agreement between the parties or in AMD’s Standard Terms and Conditions of Sale.

AMD, the AMD Arrow logo, FidelityFX, FidelityFX Super Resolution, FidelityFX Super Resolution 2.0 and combinations thereof are trademarks of Advanced Micro Devices, Inc. Other product names used in this publication are for identification purposes only and may be trademarks of their respective companies.

Unreal® is a trademark or registered trademark of Epic Games, Inc. in the United States of America and elsewhere.

© 2022 Advanced Micro Devices, Inc. All rights reserved.