v1.2.8 Release Notes Introducing TAA and DLSS Support
Hi everyone,
I'm very happy to announce that with today's update, we are introducing Temporal Anti-Aliasing and NVIDIA DLSS support for Trails through Daybreak II. If you are interested in more detailed technical information about this, then stick around for the final part of this post, but first, let's go over the patch notes and some (potential) FAQs.
(See Screenshot_1)
Here's the full list of changes and improvements:
- Introduce a TAA anti-aliasing option.
- Introduce DLSS3 and DLSS4 graphics options for compatible hardware.
- Always render 3D UI at 100% scale, even if the render scale is below 100%.
- Always render expanded minimap UI at 100% scale, even if the render scale is below 100%.
- Always render the time chart illustration UI at least at 100% scale, even if the render scale is below 100%.
- Load the default graphics preset on game start if no settings file is present, and adjust the preset logic to use DLSS on compatible systems.
- Fix the behaviour of the "Camera Auto Center" and "Slope Adjust" options.
- Fix the potential temporary loss of background blur in the settings menu upon changing some graphics settings.
- Prevent mouse scrolling on the Cube Analysis result screen from wrapping around the list in a surprising way.
- Prevent specific soft-locks which could occur when having a direct shortcut action binding which conflicts with another action.
- Fix an issue with loading the latest save on startup when all 225 save slots are used.
Rendering the various types of UI at least at 100% scale also applies to simple (non-DLSS) scaling, but is particularly useful in conjunction with DLSS as this makes lower render scales more viable.
TAA/DLSS Integration FAQ
Why is the performance impact of enabling TAA/DLSS slightly higher than in some other games?
Most current rendering engines always generate motion vectors, e.g. to use them for effects like object motion blur. This is not the case for Trails through Daybreak II, which means that motion vectors are only rendered when TAA or DLSS are enabled, with a slight performance cost. Of course, DLSS still allows for much more significant rendering performance savings by using a sub-100 render scale at very good output quality, and TAA provides much better performance than the more expensive AA options like MSAA or SGSSAA.
What is the difference between the "DLSS 3" and "DLSS 4" settings?
The former setting uses the traditional CNN AI model, while the latter uses the new transformer-based model for spatial upscaling. This provides improved image quality in most situations, at slightly higher performance cost.
(See Screenshot_2)
Where are the DLSS quality settings?
To adjust the DLSS quality, just adjust the existing render scale setting. For example, "50" render scale is "Performance DLSS", and 100 render scale is "DLAA". You can actually go above 100 in our implementation, which is a bit silly and which I don't think NVIDIA has a name for.
For example, the settings in the screenshot above would be using the DLSS transformer model with a scale close to the usual DLSS "Quality" preset.
Why only DLSS? What about FSR or XeSS?
Given that the majority of the work for integrating DLSS into this game went into creating reliable motion vectors for all scenes, we'd absolutely love to support all technologies that can make use of this. Sadly, neither AMD FSR nor Intel XeSS support the DirectX 11 API used by Trails through Daybreak II, while DLSS does. If a future release of either of the other temporal upscaling solutions adds DX11 support, we would certainly aim to integrate them as soon as possible.
This is also the reason why I implemented TAA, so that anyone on a non-Nvidia GPU can at least benefit from this update in this way.
Technical Background
As alluded to in the FAQ above, the major challenge with integrating TAA and DLSS into this game was that it does not naturally generate per-pixel motion vectors. "Motion vectors", in this context, are simply a vector of two numbers for each pixel on screen which indicates where this pixel was on the previous frame -- e.g. a motion vector of (20,5) would indicate that the object this pixel belongs to moved 20 pixels to the right and 5 pixels down in the current frame.
The quality of the motion vectors supplied is crucial for the final output quality of the result that DLSS (and other comparable technologies like FSR and XeSS) can produce, as it enables them to use information from previous frames not just for stationary objects, but also for those that are in motion.
While integrating DLSS into a game which already generates motion vectors and uses some form of TAA might take just a matter of hours and potentially be completed in a working day or two, adding motion vector generation in a game and engine from scratch is a more involved process. For example, any bone-animated mesh (such as a character model) needs to be supplied with the previous frame's poses in order to compute both the previous and current vertex position, and finally deduce pixel movement from these. Other objects which require special handling for motion vectors are things like grass and foliage that sways in the wind.
(See Screenshot_3)
Even with accurate motion vectors, there are some specific patterns which don't work well with DLSS. An example is the starry sky shown in the screenshot above, where stars are rendered as single-pixel dots (you probably need to look at the full-size image to see them). To support situations like this, a special mask can be provided to DLSS which marks areas where recent changes should have priority. We also provide this for that particular purpose. (Note that, in our testing, it seems like DLSS 4 / the transformer model currently ignores this input).
After finishing work on DLSS, and confirming that neither FSR nor XeSS support DirectX11, I really wanted to at least provide a solid TAA implementation based on the motion vectors I put so much effort into generating. Now again, since this is a completely custom engine with no support for this, I had to start more or less from scratch -- I of course know the basics, but this paper was a great overview of the state of the art (at least as of 2020), and other resources also helped. It took some doing, but in the end I think we now have quite a solid TAA implementation that at least manages to compare decently to the state of the art -- outside AI-enhanced options. Also, since I have full control over it, I was able to optimize it specifically for the dithering patterns used in some places in the game, where it now generates an even better result than DLSS.
As you can see in the patch notes, we also used this opportunity to solve a few remaining niggles in the interaction between the render scale setting and some UI elements. We already rendered 2D UI at the output resolution rather than the (potentially scaled) main rendering resolution, but we now also apply this to 3D UI elements, the timeline, and the map, to ensure that all of these look good when using a lower render scale.
Overall, with the integration now complete, the output of DLSS is excellent in most situations. For stationary or slow-moving objects it even rivals SGSSAA. And I am also quite pleased with my TAA implementation. While it obviously cannot rival DLAA, it provides very good anti-aliasing and is tuned to provide a good tradeoff between aliasing, sharpness, clarity in motion, and temporal stability.
Conclusion
I hope you enjoy this update. This took a very substantial amount of work with changes throughout the rendering pipeline, which also means a substantial amount of testing was necessary. As always, thanks to our great beta testers for their support!
Since this update by necessity touches almost everything related to rendering, despite our in-depth testing, some regressions might have made it to this version. As such, I want to remind you that you can always revert to a previous version of the game by using the Steam "Beta" feature.
Cheers,
Peter "Durante" Thoman, CTO, PH3
