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 part 2 – 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 2

Back in part 1, we discussed the problems with foliage appearance, and how to use the base pass for velocity generation in order to improve it. 

Here in part 2, we discuss how to improve the foliage appearance via content changes. 

Improvements to foliage via content changes

It is also possible 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.

The changes can be extensive depending upon the project and the types of assets involved. Continuing to use ‘A Boy and His Kite‘ as the example, there are several actions to take to change the project and content to ensure that as much of the foliage generates motion vectors as possible.

Project Settings

In order for content changes to be effective it is necessary to make changes to the project settings. Using r.BasePassOutputsVelocity without enabling or allowing FSR 2.1 to enable r.BasePassForceOutputsVelocity can result in missing motion vectors even when all objects are set to be Stationary or Movable. Therefore if it is necessary to render velocity for the minimum number of objects, then this must be done first.

To disable this setting open Project Settings > Engine > Rendering > Optimisations and disable Output velocities during base pass.

FSR 2.1 Unreal Engine
FSR 2.1 Unreal Engine

Landscape grass layers

The demo uses grass layers sampled in the landscape material which create Hierarchical Instanced Static Mesh components at runtime with Static mobility set in the Unreal Engine code.

For Unreal Engine 5.0 and earlier

The plugin has an option in the plugin settings to force the mobility for these components to Stationary at runtime.

To enable this setting open Project Settings > Plugins > FidelityFX Super Resolution 2.2 and then select either All Instances or Instances with World-Position-Offset. The former is lower overhead on the CPU while the latter may use more CPU time but sacrifice less on the GPU.

For Unreal Engine 5.1 and later

A new console variable r.Velocity.EnableLandscapeGrass controls whether these components render velocity and it is enabled by default. The FSR 2.2 plugin will enable r.Velocity.EnableLandscapeGrass if disabled to ensure correct rendering when Force Vertex Deformation To Output Velocity is enabled.

It should not be necessary to enable the Force Landscape HISM Mobility option.

Force mobility to stationary

Enabling this option ensures that the majority of grass nearest the camera in the starting scene renders velocity which has a significant effect on the visual result. However, there are still gaps in the velocity caused by objects not rendered as part of the grass layer and these need additional work.

Velocity Scene

Static meshes

Later in the demo there are trees that still don’t render velocity and many are regular static meshes.

Static meshes - trees that don't render velocity.

When editing, it is possible to use FSR 2 in the Editor viewport by selecting the option in the viewport:

Enable FSR 2.1 in the Editor Viewport

Changing these meshes to Stationary forces them to render velocity required for best rendering in FSR 2, but there are many more that still don’t.

Before Meshes set to Stationary

Foliage

These are part of an Instanced Foliage Actor and require modifying the blueprint used to spawn them in the foliage system. Switching the editor to Foliage mode shows the blueprints and static meshes used in the current level.

Foliage mode

Opening these blueprints and changing Mobility from Static to Stationary, then saving the blueprint and the level will cause them to start rendering velocity.

Static Stationary

Close-up of velocity inset

We can also open the Procedural Foliage System which shows us more blueprints used to generate the forest.

Procedural Foliage System
Procedural Foliage Simulation

These blueprints define how the foliage system spawns the Instanced static meshes in the forest, and to have them generate velocity requires changing the mobility for each blueprint.

Changing mobility for each blueprint

Dithered LOD Transition

Enabling the Dithered LOD Transition option on materials that use World-Position-Offset is an issue when r.BasePassOutputsVelocity is disabled. In this case the engine renders the base pass using a dithered pattern between two LODs at the boundaries of LOD transitions. This reduces ‘popping’ between the LOD levels.

When r.BasePassOutputsVelocity is disabled, the velocity is rendered with a separate pass and this can result in a mismatch between the velocity and the dithered base pass which confuses the FSR 2 upscaling algorithm. The screenshot below shows an example:

Mismatch between the velocity and the dithered base pass

To fix this requires either enabling r.BasePassOutputsVelocity or disabling Dithered LOD Transition in the relevant materials as shown below:

Disabling Dithered LOD Transition

Material Instances

When using Material Instances with UE4 4.27 and earlier, it is necessary to double check that the material system properly exports that the material uses World-Position-Offset . This is not necessary for Unreal Engine 5.

The issue occurs when using a Material Instance Parameter with a default value of 0 to control whether to use World-Position-Offset in a Material as the system will evaluate whether WPO is used based on the default inputs to the Material, not the Material Instance.

Material Graph with Instance Parameter

Material Graph with Instance Parameter

Material Instance that enables WPO

Material Instance that enables WPO

The Material defaults the value of Animate to false, but the Material Instance sets Animate to true. However, the object using the Material Instance does not render velocity, despite being animated.

Object using Material Instance does not render velocity

Simply changing the default to true will allow the material system to assume that WPO is used and render velocity.

Changing default to true
Velocity being rendered

Results

Once all the content has been properly modified there will be reduced ghosting in the upscaled result, but there will be changes in the CPU and GPU behavior.

  • Setting objects to Stationary rather than Static may result in slightly higher CPU and GPU overhead as the number of objects whose bounds are updated and that write to the velocity output will increase.
  • There may also be subtle changes in the lighting of objects illuminated by static lights whose mobility is changed from Static to Stationary.

When making these content changes it is best to only change the content where the ghosting is apparent, leaving as much to be Static as possible to reduce these changes in behavior.

Coming up next

Continue reading in part 3 to find out how to apply the ImproveStaticWPO patch and see the results. 

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.