Comparative consideration of DirectX 12 in games *spawn

Doesnt work like that. Metro Exodus EE gets 60 FPS on consoles with proper hardware Raytracing.

I think it's important to highlight that Metro:EE is still, at heart, a game that targets last generation consoles.

If UE5 could run on last gen consoles it would be much more performant on current consoles than it is.

It's also worth pointing out that on PS5 and XSX the game cam drop below 1080p and has things like tessellation disabled.

So it's not that much of a technical fest as it is being made to be as I image a lot of last gen games could be done at 1080p60 with RTGI as they lack any next generation effects.
 
60 FPS presumably means with ray traced reflections + VSM + Nanite. On consoles, Metro Exodus EE has none of these things. (At least, I can't find any references to ray traced shadows).
On PC, Metro Exodus EE supports both global illumination and reflections, and runs wonderfully. I wish UE5 games run the same or close to that after these upcoming Hardware Lumen optimizations.

It's also worth pointing out that on PS5 and XSX the game cam drop below 1080p and has things like tessellation disabled.
Same thing with UE5 games too, games like Immortals of Aveum, Robocob and Lords of The Fallen drop hard, all while shipping with software Lumen operating with lots of screen space lighting elements. UE5 games run with vastly better Geometry and Shadows of course, but still ..

Epic will just reduce the workload. Should have been done already if this would be so easy. 4A Games only needed two years...
I agree that Epic needs to step up their game in these global illumination/reflections/shadows departments, it's frankly unacceptable when UE5 games ship with underwhelming reflections solutions on PC, when other older UE4 titles came with a robust RT reflections solutions. Also, global illumination is not the best on UE5 titles, with several problems like extensive boiling of lights in indirectly lit scenes, and the breaking of several screen space Lumen lighting effects when occluded, these are side effects of Software Lumen, thus Hardware Lumen should be available at least on PC, to remedy these issues.

In my opinion, Software Lumen shouldn't be running at the same speed as Hardware Lumen, Hardware Lumen should run a lot faster, and I hope Epic is working on doing just that: making Hardware Lumen faster than Software, while also achieving higher image quality.
 
I agree that Epic needs to step up their game in these global illumination/reflections/shadows departments, it's frankly unacceptable when UE5 games ship with underwhelming reflections solutions on PC, when other older UE4 titles came with a robust RT reflections solutions.
Modders have been able to enable Hardware Lumen, so I doubt there's a technical reason preventing its inclusion.
 
Modders have been able to enable Hardware Lumen, so I doubt there's a technical reason preventing its inclusion.

Modders and developers operate under two different sets of expectation.

If a mod doesn't work well you simply remove it and find something that does work. Furthermore, if a mod doesn't work as intended on a relatively large number of devices, it not typically a hit on a modder's reputation. But thats the benefit of not charging typical game prices for your work.

Devs do not operate under such forgiving circumstances. If a feature doesn't work as intended on a significant number of supported devices, then the developer is blamed and the criticism can lead to poor performance regarding future sales of the title. So devs have to be more conscientious about the code they release as quality control is more pertinent (poor releases over the last several years may make you believe otherwise LOL) function of their job. Buts that the reality of charging a non-insignificant fee for your work.
 
Modders and developers operate under two different sets of expectation.

If a mod doesn't work well you simply remove it and find something that does work. Furthermore, if a mod doesn't work as intended on a relatively large number of devices, it not typically a hit on a modder's reputation. But thats the benefit of not charging typical game prices for your work.

Devs do not operate under such forgiving circumstances. If a feature doesn't work as intended on a significant number of supported devices, then the developer is blamed and the criticism can lead to poor performance regarding future sales of the title. So devs have to be more conscientious about the code they release as quality control is more pertinent (poor releases over the last several years may make you believe otherwise LOL) function of their job. Buts that the reality of charging a non-insignificant fee for your work.
That was kind of my point actually. Many features that developers get the blame for not "turning on" require a lot of QA passes to make sure they are working as expected. But the expectation in these forums seems to be that if another game has shipped with a feature, it is available in the engine, and would deliver a significant visual boost, even the smallest of indie developers are obliged to include it. Or if they don't, somehow the engine developer is to blame. Hence the posts pointing out the reflections in Robocop and the (according to DF) barely noticeable GI artifacts, and ignoring the great work in the rest of the game, coming from a developer who is over the moon at selling 400,000 copies!
 
Where is the support in UE5 that developers see it as a benefit for their games?

We’re seeing slow uptake of hardware RT in UE5 because software Lumen + VSMs on their own already raise the bar for GI and shadow quality and that’s kinda the point. It’s really just specular reflections that suck.

I’m sure Epic wishes that they could just throw Nanite level meshes into a BVH and leave the heavy lifting to the hardware but they can’t. Software Lumen comes with its own mess of data structures and hacks and limitations that they probably aren’t thrilled about. However it’s a necessary compromise to deliver on the geometry density goals they set for the engine.
 
I’m sure Epic wishes that they could just throw Nanite level meshes into a BVH and leave the heavy lifting to the hardware...
Can confirm. No one likes shadow maps :cry:

But it's not just the high detail meshes, it's additionally that many of the things people want to do that are already expensive with Nanite (ex. foliage, deformation, skinning) are even more expensive with raytracing... Ultimately it's always about finding the right set of tradeoffs and compromises for a specific game.
 
Last edited:
Can confirm. No one likes shadow maps :cry:

But it's not just the high detail meshes, it's additionally that many of the things people want to do that are already expensive with Nanite (ex. foliage, deformation, skinning) are even more expensive with raytracing... Ultimately it's always about finding the right set of tradeoffs and compromises for a specific game.

TBH, I've been turning off RT shadows in games lately (where available obviously). Watching a shadow LOD pop is far more egregious than watching the object LOD pop, which makes sense in a way as the luminance values can change more. Still, I don't think you can do RT shadows without some sort of progressive LOD in place without serious image quality issues at times. Perhaps there's something to be said for old tech hiding the faults of other old tech.
 
We’re seeing slow uptake of hardware RT in UE5 because software Lumen + VSMs on their own already raise the bar for GI and shadow quality and that’s kinda the point. It’s really just specular reflections that suck.

I’m sure Epic wishes that they could just throw Nanite level meshes into a BVH and leave the heavy lifting to the hardware but they can’t. Software Lumen comes with its own mess of data structures and hacks and limitations that they probably aren’t thrilled about. However it’s a necessary compromise to deliver on the geometry density goals they set for the engine.

We seeing a slow uptake because hardware RT doesnt make sense with UE5. Its to slow, improves image quality only in a slight way.

WIthin six months CD Project has not only implemented but updated Pathtracing with RR, RestirGI and a few others features. Within 3 years Epic cant even produce a basic reflection. Other companies using the time to do something, Epic is just sitting here...

These reflections in UE5 are worse than Raytracing@low in BF5. Half a decade between both and yet the very first implementation of Hardware RT is more advanced.
 
WIthin six months CD Project has not only implemented but updated Pathtracing with RR, RestirGI and a few others features. Within 3 years Epic cant even produce a basic reflection. Other companies using the time to do something, Epic is just sitting here...
Is there anything wrong with the reflections in the Matrix demo?
 
We seeing a slow uptake because hardware RT doesnt make sense with UE5. Its to slow, improves image quality only in a slight way.

WIthin six months CD Project has not only implemented but updated Pathtracing with RR, RestirGI and a few others features. Within 3 years Epic cant even produce a basic reflection. Other companies using the time to do something, Epic is just sitting here...

These reflections in UE5 are worse than Raytracing@low in BF5. Half a decade between both and yet the very first implementation of Hardware RT is more advanced.
There's has been exactly ZERO major functionality updates to DXR for OVER 4 years now and the folks at DF have the audacity to question developers why they won't use dead end APIs even if Nvidia is the leading PC graphics vendor ? Once spring comes around, we'll be at 5 years without any DXR functionality updates ...
 
We seeing a slow uptake because hardware RT doesnt make sense with UE5. Its to slow, improves image quality only in a slight way.

WIthin six months CD Project has not only implemented but updated Pathtracing with RR, RestirGI and a few others features. Within 3 years Epic cant even produce a basic reflection. Other companies using the time to do something, Epic is just sitting here...

These reflections in UE5 are worse than Raytracing@low in BF5. Half a decade between both and yet the very first implementation of Hardware RT is more advanced.

UE5 supports high fidelity HWRT reflections. I’m sure you know this.
 
There's has been exactly ZERO major functionality updates to DXR for OVER 4 years now and the folks at DF have the audacity to question developers why they won't use dead end APIs even if Nvidia is the leading PC graphics vendor ? Once spring comes around, we'll be at 5 years without any DXR functionality updates ...

DXR 1.1 came out in summer 2020, so it's a little over 3 years old. It's not over 4 years.


DirectX Raytracing 1.1


DXR traces paths of light with physics calculations, enabling highly accurate simulations. DXR 1.1 adds three major new capabilities:


  • ExecuteIndirect: GPU work creation now allows ray tracing. This enables shaders on the GPU to invoke and control ray tracing without an intervening round-trip back to the CPU. This is useful for adaptive ray tracing scenarios like shader-based culling, sorting, classification, and refinement.
  • Incremental State Objects: State objects can now be incrementally compiled to enable streaming engines to efficiently add new ray tracing shaders as needed when the player moves around the world and new objects become visible without causing performance issues like stuttering
  • TraceRayInline: Inline ray tracing is an alternative form of ray tracing that gives developers the option to drive more of the ray tracing process, as opposed to handing work scheduling entirely to the system (dynamic-shading). It is available in any shader stage (including compute shaders, pixel shaders etc) which also allows for easier integration into existing game engines. Both the dynamic-shading and inline forms of ray tracing use the same opaque acceleration structures.

The DXR spec was also updated on Janary 2023 ... not sure what changed
 
Last edited:
We seeing a slow uptake because hardware RT doesnt make sense with UE5. Its to slow, improves image quality only in a slight way.

WIthin six months CD Project has not only implemented but updated Pathtracing with RR, RestirGI and a few others features. Within 3 years Epic cant even produce a basic reflection. Other companies using the time to do something, Epic is just sitting here...

These reflections in UE5 are worse than Raytracing@low in BF5. Half a decade between both and yet the very first implementation of Hardware RT is more advanced.

From a replay I recorded earlier (almost 20 minutes of gameplay). Hardware RT is only about a 11% hit compared to software RT with Lumen GI and Reflections on High in Fortnite Chapter 5 Season 1, which is UE 5.4. Epic is actively working to make hardware RT achievable at 60 fps on console. So they are working on it (has some benefits) and the performance hit is not that big anymore. On my 3080 I can get about 80 fps with HW RT at 1440p TAA native.

1701716381913.png
 
DXR 1.1 came out in summer 2020, so it's a little over 3 years old. It's not over 4 years.




The DXR spec was also updated on Janary 2023 ... not sure what changed
If you actually took a look at the DXR functional spec change logs itself, inline ray tracing was last major functionality addition to DXR in version 1.04 which was dated 4/18/2019. There's been clarifications here and there after version 1.07 for the most part but there's been no major functionality changes since then. Either way you look at it, the evolution of DXR has largely become stagnant ...
 
If you actually took a look at the DXR functional spec change logs itself, inline ray tracing was last major functionality addition to DXR in version 1.04 which was dated 4/18/2019. There's been clarifications here and there after version 1.07 for the most part but there's been no major functionality changes since then. Either way you look at it, the evolution of DXR has largely become stagnant ...

By that standard isn’t DirectX also stagnant? Not sure what point you’re making.
 
By that standard isn’t DirectX also stagnant? Not sure what point you’re making.
DirectX is a collection of differing GPU specific/centric functionality APIs whereas DXR is a singular API feature so your low brow analogy doesn't really match up. Just because an API feature like DXR is faltering doesn't mean that the same case applies to the whole API itself such as DirectX especially when it's getting new major functionality like Work Graphs ...
 
DirectX is a collection of differing GPU specific/centric functionality APIs whereas DXR is a singular API feature so your low brow analogy doesn't really match up. Just because an API feature like DXR is faltering doesn't mean that the same case applies to the whole API itself such as DirectX especially when it's getting new major functionality like Work Graphs ...

Aside from the random insult you haven’t answered the question. Why do you have different standards for DirectX as a whole and DXR which is just one small part of it?
 
Aside from the random insult you haven’t answered the question. Why do you have different standards for DirectX as a whole and DXR which is just one small part of it?
Is it really or is that just your interpretation ? It's simply a fact that DirectX has seen meaningful functionality advancements recently by itself while DXR on the other hand hasn't for some time now ...
 
Back
Top