Unreal Engine 5, [UE5 Developer Availability 2022-04-05]

[Andrew Lauritzen]

They were insanely popular and cards like the HD5970, HD6900 and HTX590 were very sought after GPU's

I can say in terms of raw numbers, they were never particularly popular configurations. Of course they waned further over time, but even at the peak they were at most low single digit percentages of gamer setups. Definitely the "SLI on a stick" cards were probably a good chunk of the ones that saw use, but even then. Otherwise - frankly - it would not have been acceptable to change how they worked in the new APIs. And to be clear, game developers can still implement SLI with more flexibility than ever, but now that the economics are tied more directly to the install base and not the IHV marketing department, it turns out the motivation is a lot less

Anyways... getting kind of off topic here, sorry.

 

[Lurkmass]

No they didn't.

They were insanely popular and cards like the HD5970, HD6900 and HTX590 were very sought after GPU's

All of which are more than a decade old well after which D3D11 was more than supported ...

You're going to have to clarify this irrelevant comment as multi gpu died well before DLSS arrived.

You can stop using D3D12 as your scapegoat for all the ails behind the PC platform like you or the others here usually believe since it's not even close to the reason for the decline of mGPU setups ...

Some of which are even documented by IHV interns too ...

 

[davis.anthony]

All of which are more than a decade old well after which D3D11 was more than supported ...

What are you even babbling on about?

You can stop using D3D12 as your scapegoat for all the ails behind the PC platform like you or the others here usually believe.

Pease feel free to show me when I've used DX12 as a scapegoat like others.

since it's not even close to the reason for the decline of mGPU setups ...

I never said it was the reason, I said it was a reason.

Some of which are even documented by IHV interns too ...

You done posting aggressive irrelevant crap now?

Good.

 

[Jay]

Waxes lyrical long and hard about how they feel its only right to support older hardware etc etc etc

Then at the end conveniently forgets to mention that the driver level one only works on RDNA3. Maybe he also misses the irony.

 

[Frenetic Pony]

Waxes lyrical long and hard about how they feel its only right to support older hardware etc etc etc

Then at the end conveniently forgets to mention that the driver level one only works on RDNA3. Maybe he also misses the irony.

I'm pretty sure it's only HyperRx, which is getting frame injection, that's driver locked. FSR3 has been repeatedly called open source and multi platform. HyperRx is a neat thing to have, older games can be CPU bound just by dint of terrible optimization or etc. (Skyrim) and having a one click solution for anyone that wants it is cool, and it's a bit more understandable as a driver thing.

Regarding something completely different, UE5 should, at least optionally, have VSMs assume shadowmaps are "solid" regarding unknown depth. I.E. when it crosses a depth boundary the shadowmap has no information about the ray just assumes it's solid and stops, instead of empty. Yes this cuts off the "inner" half of the penumbra and makes it black, but light leak becomes increasingly obvious as light "size" goes up.

There's a good example in Aveum where some artist really went to town on a light's radius, one of those "light coming from above through grating" setups, and you can see wonky lightleak artifacts plain as day, wish I could find it for a screenshot. Regardless this is how GoW Ragnarok: https://www.gdcvault.com/play/1029298/Rendering-God-of-War-Ragnarok handles their raytraced shadowmaps and what they recommend, I believe Jedi Survivor does something pretty similar as well. As it's even a bit distracting in Jusant, where the artists do not go crazy with light radius, or even Baldur's Gate 3 (also contact hardening shadows) it seems a good fix for an obvious artifact.

 

[Andrew Lauritzen]

There's a good example in Aveum where some artist really went to town on a light's radius, one of those "light coming from above through grating" setups, and you can see wonky lightleak artifacts plain as day, wish I could find it for a screenshot. Regardless this is how GoW Ragnarok: https://www.gdcvault.com/play/1029298/Rendering-God-of-War-Ragnarok handles their raytraced shadowmaps and what they recommend, I believe Jedi Survivor does something pretty similar as well. As it's even a bit distracting in Jusant, where the artists do not go crazy with light radius, or even Baldur's Gate 3 (also contact hardening shadows) it seems a good fix for an obvious artifact.

Be interested to see the specific screenshots in each of these cases; there are definitely artifacts in GoW, but they are usually hidden by the art. The reality is you cannot eliminate artifacts entirely with shadow map raytracing techniques - all you can do is move them around. If you trace a heightfield (i.e. always assume it's a hit), you get artifacts similar to screen space contact shadows, namely it will make solid-like shadows for thin geometry which morph as it changes size in screen space. This is particularly awful on stuff like fences and telephone poles viewed from above with longer projected shadows.

SMRT does something a bit fancier - namely we trace in the opposite direction such that we start unoccluded (from the light), and keep track of the depths we see in the depth buffer as we walk along the ray. When we cross a potential depth boundary, we extrapolate the geometry based on the depth function that we saw approaching the discontinuity, optionally via a simple light-aligned plane (i.e. use the same depth) or more accurately via the depth slope (tradeoff being a bit more occupancy and processing in the inner loop). None of these techniques can be perfect, but this significantly improves the quality of even simple cases like shadows cast from distant objects onto sloped receivers. Most of the other heuristics will not only lose the inner penumbra, but often also heavily clamp the whole penumbra, and in an angle-dependent way that depends on the receiver and looks bad at things like floor/wall-intersections.

Ultimately these things need raytracing of more than the depth buffer/shadow map to resolve these issues, but it's a case that has to be managed sensibly in art for the time being. All of these techniques look bad when the light radius/area is pushed too far, especially when something with soft shadows and something with harder shadows overlap while moving.

I've not looked at what Jedi Survivor does at all - is there a talk on that anywhere?

 

[davis.anthony]

Latest UE5 game - Fort Solis...... It's also heavy AF on the GPU.



And the frame rate on a 4070ti, max settings at native 1440p in that shot???? 33fps!!!!!!

 

[troyan]

Descorde has removed emissive lights because it's not stable enough:

One of the challenges with Lumen is the handling of emissive lighting; the light cubes in Desordre are now excluded from Lumen's calculations. These cubes produce light that flickers excessively, making the overall rendering unstable.
If Epic Games improves this feature in the future, the light cubes will, of course, be supported by Lumen again. However, the primary goal is to achieve stable lighting.

That is now the difference between RTXDI and just Lumen:

Imgsli

 

[DavidGraham]

In Immortals of Aveum, DLSS2 reigns supreme compared to native TAA and FSR2. It's simply the only way to play the game with great image quality on PC.

TAA: The in-game TAA solution has very poor rendering of small object detail—thin steel objects and power lines, incomplete and shimmery small particle effects, tree leaves, and vegetation in general. The TAA solution also has shimmering issues on the whole image, even when standing still, which are especially visible at lower resolutions such as 1080p.

DLSS2: All of these issues are resolved when DLSS is enabled, due to a superior anti-aliasing solution. With DLSS you can expect an improved level of detail rendered in vegetation and tree leaves in comparison to the in-game TAA solution. Small details in the particle effects in different variety of magic abilities are rendered more stably, correctly and completely in all Quality modes.

FSR2.2 (latest AMD version): Immortals of Aveum has a lot of variety of magic abilities on screen and FSR 2.2 simply fails to properly reconstruct the details in these small particle effects. With FSR 2.2 enabled, almost all in-game magic abilities have an incomplete look with shimmering and small ghosting issues, especially visible in motion, compared to the native TAA solution and DLSS. The anti-aliasing quality is also inferior, as the overall image has more jagged lines in motion, especially visible on small particle effects during combat and in vegetation.

DLSS3 is unstable though and needs further improvements.

Immortals of Aveum: FSR 2.2 vs. DLSS 2 vs. DLSS 3 Comparison Review

Immortals of Aveum is out now on PC, with support for NVIDIA DLSS Super Resolution and Frame Generation. Also supported is AMD's FidelityFX Super Resolution. In this mini-review we compare the image quality and performance gains offered by these technologies.

www.techpowerup.com

 

[techuse]

The ghosting issues are far from small.

 

[Frenetic Pony]

Found it, video marked. Obviously no perfect fix, but when you start making large light radii you can see pretty sharply delineated artifacts:

I don't know exactly what Jedi Survivor is doing, it is some sort of shadow map area light approximation, but they haven't talked about it. It does appear the penumbra is pretty solid, and the results are impressively soft and artifact free from playing the game considering it's a shadow map. I'll look forward to GDC next year or whenever they do talk about it.

 

[Andrew Lauritzen]

Descorde has removed emissive lights because it's not stable enough:

Lighting primarily with emissive objects is actively discouraged by Lumen... would be great to handle arbitrary many light emissive things in the future but it is obviously a lot more expensive. That said it's not clear why the cubes in Desordre aren't analytic lights, which would benefit all techniques. If my memory of the game serves (I played it a bit when it initially came out), there's not actually that many of them.

Found it, video marked. Obviously no perfect fix, but when you start making large light radii you can see pretty sharply delineated artifacts:

Hmm yeah I'm not sure offhand why that looks so bad there. That is not typically what I'd expect a single light overlapping case to look like.

I made a similar situation in the Lyra example and while you can see some ambiguity around the places where the soft and hard shadows overlap (as expected), it doesn't look nearly as objectionable as the video case. Note these are raw SMRT results before TSR/other temporal integration, hence the additional noise:

Note that this is actually with a fairly large source radius, just a bit zoomed out to see the context. The result doesn't change materially for local lights when you zoom in (with directional lights the penumbra is effectively clamped in terms of screen area, which to some extent limits how badly you can shoot yourself in the foot).

Forcing occlusion whenever you cross a behind/in front boundary also doesn't really fix things with these sorts of settings per se - it functionally just overlays an unfiltered shadow on top of the proper result. Losing inner penumbra in these sorts of cases means you get what looks like an unfiltered shadow map with a slight haze around it, since the minimal outer penumbra is not going to properly fade to fully occluded:
I briefly looked for cases like this in GoW to see what their solution looks like (since it is not exactly the same sort of thing - it seems to be a bit targeted to be a bit more PCF-like rather than specifically raytracing like), but I couldn't find any cases where they had set the softness particularly high. I'm guessing those cases look bad in their solution as well so their artists just know to avoid it. There are similar notes about keeping penumbra sizes in check in the VSM documentation... if unheeded no amount of algorithmic magic is going to avoid artifacts with shadow maps.

Anyways always interested to see what other folks are doing. Just not sure there's a silver bullet here.

 

[Scott_Arm]

I'm taking some fortnite photos to really show what nanite is bringing to the table. These comparisons aren't perfectly lined up, and they can't really show how well the lod scaling works as you move closer and further away from objects, especially in a game like fortnite. With nanite you don't see imposters popping in, and you don't see the lods switching on the trees etc. What you'll see is some examples of the increase in geometric complexity that people might not realize is there without direct comparisons. Some of these things are fine details, but that's the point. And remember, it's a large open map. It's not a corridor adventure game. The nanite pics have lumen so the lighting looks a lot better. There are a lot of little detailsa that people might not notice if they're seeing youtube videos, or just running through the game without looking closely.

I was able to take these in creative so I could clip through the ground or walls.

Nanite is obviously on the left. Not only are there vastly more leaves, the trunk of the tree has way more geometry. It's not just a bark texture wrapped onto simple geometry. The trunk has complexity.


A comparison of this ground texture of rocks when clipped through the ground and looking parallel to the surface. Also, check out the modeling of the bark of the palm tree. Super detailed.



The same brick location in two locations. The nanite one is obviously on the left.



This one might be subtle for a lot of people, but there is a lot of geometry with very smooth curves, even up close. Curved surfaces look simple but require a lot of geometry. That seal around the doorway in the background has a ton more geometric complexity as do the bricks.

 

[Scott_Arm]

Latest UE5 game - Fort Solis...... It's also heavy AF on the GPU.

...

And the frame rate on a 4070ti, max settings at native 1440p in that shot???? 33fps!!!!!!

Look at the modelling on the harness. Really damn cool. That carabiner clip and the other buckles look very detailed and smooth. Polygon count of carabiner clip to infinity!

Edit: And look at how good the shadowing is on his face and his suit, even the shadows from the harness is very detailed. Those shadows really nicely follow the counters in his face and his jacket. It's incredibly nice.

 

[Karamazov]

when they updated fortnite, Epic posted an article, they said the trees have now 300 000 individual leaves each, and you can't see the LoD pop in even in the distance with all the trees.
Some objects pop in we can still see are non nanite objects.
Remember you have a theater mode in fortnite so you can use it to get close to objects and make comparison shots.

 

[Scott_Arm]

Some objects pop in we can still see are non nanite objects.
Remember you have a theater mode in fortnite so you can use it to get close to objects and make comparison shots.

I’ll have to look for theatre mode. Not sure where the option is. Is that replays?

 

[Karamazov]

I’ll have to look for theatre mode. Not sure where the option is. Is that replays?

yes replays ! then you have different camera options, one is free drone view, you can pause the action and fly anywhere you want on the map, and even change the mode (120/60fps) while keeping the exact same camera position, useful to make comparison shots.

Unreal Engine 5, [UE5 Developer Availability 2022-04-05]

Looks natural to me? It's very bright outside the open wall Isn't that depending on the place you want to have proper exposure? The lumen seems want to see the insides properly exposed, while non lument want to see the outside properly exposed

forum.beyond3d.com

 

[Jay]

I'm pretty sure it's only HyperRx, which is getting frame injection, that's driver locked. FSR3 has been repeatedly called open source and multi platform. HyperRx is a neat thing to have, older games can be CPU bound just by dint of terrible optimization or etc. (Skyrim) and having a one click solution for anyone that wants it is cool, and it's a bit more understandable as a driver thing.

Yeah, I'm aware of that.
But in the end they have something locked behind RDNA3 regardless.
Why should they get to choose when something is ok to be locked and therefore outside of the 'going on about supporting older hardware etc.'
Sure can say it's something in the hardware that makes it possible, but how is that different than dlss fg? The rest of the features are supported on older generations.

I'm not here arguing for amd or nvidia's approach, just pointing out the irony in his presentation.

 

[Flappy Pannus]

Latest UE5 game - Fort Solis...... It's also heavy AF on the GPU.

Not crazy about the performance, but that is kind of the ideal scenario that I hoped for with UE5 - it gives smaller teams the potential to bring visuals more in line with AAA releases.

 

[Silent_Buddha]

Why should they get to choose when something is ok to be locked and therefore outside of the 'going on about supporting older hardware etc.'

When it's a driver level hack versus when it's actually explicitly coded for in game.

Older cards are far less likely to have new features added to their drivers (especially hacky ones that may or may not work in a game like HyperRX) versus continuing optimization.

Regards,
SB