Is Threat Interactive's (YT) game optimisation channel a long con?

Dev Zone Game Development
21

yea no doubt certain Epic devs with larger social media followings get inundated from the public to watch all sorts, majority of which im sure is the equivalent of a reddit rant post turned into video that doesn’t provide any useful insight.

yep definitely could be all of the above mixtures, especially in the AAA space where you can have 300+ people on a single game or more across multiple studios around the globe, it’s difficult enough to get 5 or 10 people on the same page for one single collaborative creative project let alone the insane dev timelines and complexity at that level.

yes and no, that Witcher 3 GDC video is a great example, if that single dev didn’t work at cd projekt they might never have built anything like that database viewer to check if they had serious optimization issues, common stuff being insanely high detail mesh that an artist forgot to make LODs for, meshes left underground, or a shadow casting light with a range of 4000meters.

if there’s no system in place to periodically check for these you end up with extremely poor performance.

if nobody on the dev team is trained for or has the time to check you also end up with peformance problems

if game devs are told to not worry the engine will handle all the optimization for you, you bet you’ll end up with perf issues

LODs or level of detail are typically say LOD=0 is the highest detail dense quality model typically very close to the player camera taking up a large amount of screen space then as you go LOD=1 might be 10+ meters away then LOD2 30-40meters and so on, typically most games will have 3 to 5 LODs per mesh depending on size ,complexity and use case
example being small items buckets/furniture etc vs extremely large structures that can be seen at a distance on the horizon, you don’t need to render those highly detailed tiny items from miles away

so yes/no it’s a double sided problem

essentially yes,
if you look up Quixel they’re a company now merged into Epics “Fab” marketplace what they do is use 3d lidar scans of real world locations for truely photorealistic assets
these assets are great for film/tv not so much for real time games.
for a game you need your 3d artists to make multiple LODs for each of these assets
but it appears more and more devs are spamming these assets and killing performance.

what Threats tool appears he wants to make an AI assist program that creates multiple LODs as simply as possible which may or may not be applicable in the game dev space,
As one part of the issue is the developers themselves first being aware nanite wont save your project in every overdraw situation

overdraw aka a object has 100,000 triangles that look fine close to the camera, but if that object is extremely far from the camera and only takes up say, 4pixels on the screen the engine is still trying to render that objects 100,000tris that ends up being computationally expensive thus wasting resources

UE5s nanite system is “suppose” to be single magic in engine tickbox to fix that by crunching/scaling detail at runtime dynamically, while it does improve Some performance its still significantly less gains then if you used traditional methods: LODs, good mesh topology, keeping some idea of a polygon budget in mind, not overlapping dynamic light sources or covering too large an area with dynamic lights etc

His theory is sound i think most big studios just simply don’t want to waste tons of artists time and money on such tasks and if they had a 1 click solution to auto create 5 varied detailed versions of a mesh/object that’s AI assisted it could help

the issue with strippling detail down from a model is the UV aka 2D texture coordinates, if you reduce a models detail by 50% now his shirt texture is on the skin, the eyes textures are misaligned etc
so an artist again needs to unwrap that model into 2D space and fix up the UV so the textures look correct
rince repeat for every level of detail object

if devs are told you can place thousands of objects at max detail and the engine will automagically handle optimizing for you, ho boy will 3d artists make some wild scenes

there’s all sorts of graphics research papers that pop up, what worked today might be deprecated tomorrow, there’s certain use cases where one method looks 99% as good as another but with far less resources used.
sometimes theres that classic “why the hek did noone tell me about this method 5 years ago” that leads to breakthroughs
as the saying goes ‘thousand ways to skin a cat’

the reality is AAA games and engines have gotten so complex it’s extremely difficult for any one person to parse through it all in any sane manner so various techniques or now “AI” solutions need to help them get a handle on things (one mans algorithm is seen to others as AI)
we’ve seen primitive AI 3D model generators nothing really usable yet,
his claimed approaches for this is kinda reversed, start with the artists highly detailed model, use AI to optimize topology and create various levels of detail

what he pitches could be an interesting tool but developing that tool alongside a game? tall ask for a team of an unknown size/funds

tech debt also absoloutely applies to game engines alongside how good your documentation is can play huge factors

i agree that DLSS upscaling and AI for fake frames just seems like the total opposite direction gaming hardware should be going, if we need 7 fake AI frames just to hit 4k 60 or 120fps with an RTX 5090 somethings gone terribly wrong on the game side.

i really appreciate motion clarity in games though the average joe doesn’t seem to mind keeping motion blur on so i dunno maybe we’re all doomed to a generation of smeary messes in similar vein to 360/ps3 era games being all piss filtered lol

4 Likes
22

I dont think they are necessarily the wrong direction for graphics to be going, just the current direction of using these technologies just to get back to 60-120fps because we can no longer run natively due to lack of optimizations is what is wrong with it. The idea itself is pretty much mandatory for future of gaming in order to reach very high FPS numbers in order to get rid of motion bluring.

Here are a couple great articles on the topic of why we need to reach 1000fps and beyond, and a bit on how frame multiplication will get us there:

https://blurbusters.com/blur-busters-law-amazing-journey-to-future-1000hz-displays-with-blurfree-sample-and-hold/

https://blurbusters.com/frame-generation-essentials-interpolation-extrapolation-and-reprojection/

https://blurbusters.com/frame-rate-amplification-technologies-frat-more-frame-rate-with-better-graphics/

The short of it is, we will always be CPU or engine bound for many parts of a game, and GPUs need to be unbound from such limitations to give us more frames per second. We need those higher frames per second in order to eliminate motion blurring. In order to get around these CPU/engine processing limitations, we need to generate these “fake frames” in between “real” ones with the new CPU data. So I am fine with frame multiplication/generation in between those real frames, as long as it gets to a point where we have no strange artifacting and cannot tell the difference between the types of frames at all. We are not yet at that place right now, but we cannot get there without these current generations that work towards the goal.

Many years ago, Nvidia has shown off some prototype high Hz displays. First a 1700Hz model and then a 16,000Hz model. I believe much of the research into these frame generation technologies is because they see as many others do that the only possible way to move into truly high frame rates is to decouple themselves from being CPU and engine bound, and they are doing testing with this frame gen stuff and these experimental displays with the goal of reaching those 1000+ FPS and Hz numbers in the real world. Youll notice in this video here that Nvidia had basically already been testing this next part I was going to talk about, using in-display hardware to bypass limitations of the connecting cable and PC hardware:
https://www.youtube.com/watch?v=nUXZwzH-114

The other big problem once you get back to the really high FPS numbers is the cable bandwidth from the GPU to the monitor. Even with the new HDMI 2.2 and its 96gbps bandwidth we dont have enough bandwidth for frames to reach perfect motion clarity at 4k resolution. So I really think we need to start doing things like placing “mini GPUs” inside the input modules of monitors that would contain nothing but the input, a couple CPU cores for input processing, and a GPU with a front end, no cuda/shader cores at all, no RT cores, and just have tensor/matrix cores in it for the frame generation, and finally a back end with “mini-ROPs” that just generate the pixels of the new frames and dont have to deal with drawing geometry or lighting or any of that. Such a “GPU” would be far smaller and more efficient than what we typically think of as a GPU and would not be some power hungry monster since all it is doing is processing the static images it receives and generating new in between frames. By using a processing unit like this inside monitors and TVs we would bypass the cable limitations and allow 2-4x or whatever frame multiplication of whatever frame rate we send to the monitor that takes no additional processing power on the PC side of things. It could also allow the removal of those cores from GPUs themselves in a PC and use that transistor space for more real cores to crunch frames. Though a simpler solution to the bandwidth problem is to move to all fiber optic cable connections. Use something like an MPO-12 connection and the cable would easily support 2.4terabits per second over it and we wouldnt have a bandwidth problem with the interconnect for a couple more decades…

But in order to achieve the goal of perfect motion clarity and good graphics, the industry does need to once again start actually doing some optimization in games.

Edit:
Here is a good excerpt from one of those Blur Busters articles talking about how we have had this with video watching for a long time and that gaming would be moving in this direction as well. This prediction was back in 2019:

1 Like
23

Frame generation inherently causes motion blur, it can never be the solution to it in the context of gaming or any input latency constrained 3D rendering. As framegen develops it’ll get better but motion blur and other artifacts will always go hand in hand with generated frames for the simple fact that generated frames are guesses of what the next image would have been had it actually been rendered.

Picture one of the worst case common setups that demonstrates motion blurring which is the trailing edge of a vehicle in motion from a third person perspective. As parts of the image are exposed for the first time in generated frames they have to be fabricated without the benefit of knowing what details will be uncovered by the next rendered frame. It’s the uncertainty in these regions where framegen puts blur because blur is a lesser artifact vs making boldly incorrect predictions.

I’ve never followed anything by Blur Busters but based on what you quoted comparing video compression with 3D rendering I never will because I find the comparison innocently ignorant at best and just flat out misleading for the sake of sensationalism/click bait at worst.

While frame generation faces the problem of having to predict images based only on prior frames because waiting for the next rendered frame would introduce vastly more input latency than generating a frame already does, this is never the case for video compression. Video encoders have full knowledge of not only every frame being encoded but in the case of B-frames future frames as well. Although P-frames are referred to as “predicted” it’s from the perspective of the decoder which uses previous reference frames combined with motion vectors to “predict” pixel values. This isn’t the end of the decoding process though and these predicted values are subsequently refined with the benefit of additionally encoded data. Claiming that a compressed video with one I-frame per second somehow equates to rendering at 1fps with the rest being “fake” frames I can only attribute to being willfully misleading.

Yeah, you’ve been mislead… being based exclusively on previously rendered frames motion blur and other artifacts along with increased input lag are inherent to any form of frame generation so at best framegen can only minimize the degree that it introduces these issues but the ultimate solution to them will always be less generation and more rendering.

I’d just delete your Blur Busters bookmarks/subs and never look back… the 1000fps nonsense makes me shudder to think what else they’ve published.

4 Likes
24

This isn’t actually a problem though. Older games like Quake, Half-Life or Call of Duty (2003) can already run over 1,000FPS on modern CPUs.
The only limitation to maximum framerate is the small game/physics timesteps required and numerical precision.

You can see this in Source Engine games if you increase the trickrate too high, and GTA IV is also known to fall apart above a certain framerate.

However, a rendering engine can be fully decoupled from game-logic, and can run in the 1,000s of FPS. All that matters is reducing the data and commands you send to the GPU per frame. If the GPU can process all of the data in time, you’re good to go, otherwise, keep reducing the complexity until your goal is reached.

No, we don’t need to go to absurdly high framerates for games to get rid of motion-blur. The reason we see blur, is that it’s actually smudging. With LCD displays it can be reduced by shortening the backlight duration and improving grey-to-grey times. OLED panels are quite slow right now, but should get faster transition times in the future.

The only case were a super-high framerate would actually be benifitial would probably be VR, where extremely low system latency is required.
In that case, any frame generation would worsen this, not improve it.

From an engineering PoV, this sounds like an awful amount of needless complexity (see the G-Sync $400 FPGA fiasco). But it sounds even worse for the end user, because now we have to buy two GPUs! And they both have to play nice with each other, or else we’ve wasted a huge amount of money for nothing.

Not to mention that now your monitor that was perfectly fine last year, is now completely outdated because it lacks some super-duper AI processing that isn’t possible with the old silicon.

As far as the cable bandwidth goes, I have no idea what to think about that, other than that if demand is high enough, we’ll probably just switch to multi-mode optical cables for displays.

2 Likes
25

Even Nvidia is not proposing frame gen to combat latency. On the contrary, they state that it introduces latency and that you should disable it and use Reflex 2 for latency critical games.

Reflex 2 could open up a whole other thread, because Reflex 2 basically does not wait for your GPU to render a new frame (which naturally has your updated mouse inputs) but applies your mouse input to the finished frame.

Of course, these are just nifty tricks and native would always be better. The question is, if native 1000fps is realistic.

Are you 100% sure about that? I don’t claim to know, since I have not looked into it. But in theory this could work pretty well.

Let’s assume a game running at 60 fps without frame gen.
This would translate to 16ms latency.
A new, real frame every 16ms.
We assume that generating a fake frame also takes 16ms.
We also assume that are fake frames are perfect and have no artifacts.

The T on the left is the timeline.
RFx stands for real frame.
FFx stands for fake frame.

Start: The GPU renders RF1 and it gets displayed.

T16: The GPU finished RF2 after 16ms. But we are not showing it yet.

T32: The GPU finished FF1 based on RF1 and RF2. But we are not showing it yet.
T32: The GPU finished RF3. But we are not showing it yet.
T32: Output of RF2.

T40: Output of FF1.

T48: Output of RF3.
T48: The GPU finished FF2 based on RF2 and RF3. But we are not showing it yet.
T48: The GPU finished RF4. But we are not showing it yet.

T56: Output of FF2.

T64: Output of RF4.
T64: The GPU finished FF3 based on RF3 and RF4. But we are not showing it yet.
T64: The GPU finished RF5. But we are not showing it yet.

This cycle repeats forever.

Now let’t take a look the two things that happened here.

  • We have twice the framerate compared to the native experience!
    This of course helps with Moving Picture Response Time (MPRT).
    I am not going into why MPRT is better than GtG, since there are good articles already on that topic. You have to trust me on this one or read up on it.

  • We added latency.
    For native, the RF2 gets displayed at the time T16.
    But with frame gen, RF2 was displayed at the time T32.
    We have added another 16ms of latency to a total of 32ms (instead of the 16ms native).

Conclusion:
For games like Counterstrike you probably do not want that. But for something like Baldurs Gate or Civ, you probably don’t care about the added latency and enjoy a clearer image.
This isn’t the first time in gaming we have added latency to create a better image.
V-Sync also adds latency but provides a better image by removing screen tearing.

Again, I have no idea how DLSS works in reality, but even with our primitive example here, we demonstrated that the claim from blur busters makes a lot of sense.
Maybe it isn’t blur busters that has been mislead but you.

1 Like
26

Frame generation isn’t based only on previous frames though. You should do some reading on the topic. The frame gen does analyze the last 2 frames so it has a more accurate prediction of what the next frame will be, but it also uses the motion vectors to understand the 3D nature of the image, the Z buffer for further depth information, as well as optical flow information as a further enhancement to the motion vectors for better understanding the specifics of things like shadows and lighting. In addition to all that data for predicting how to build the next frame, it has access to actual future data for how the next real frame is going to be constructed, such as mouse movement updates for the direction things will move and geometry data for how objects should look from a different angle to generate the frame from a slightly different perspective. And though this next part is not 100% confirmed, and there is somewhat contradicting info on it right now, some articles are saying that the newest frame generator works with Reflex 2’s frame reprojection and mouse movement data for the generation of the new frame. It is true that currently frame generation uses mostly frame interpolation, with only the beginnings of frame extrapolation starting to be used, however, the future tech that I have mentioned in the last post as to where this is headed and how we need to get through these early generations is true and full frame extrapolation. Once we have moved to that stage then latency will be cut down drastically, which solves a major issue that frame generation has right now.

27

Reflex just helps tune game loops based on analysis of the time taken to render previous frames. In GPU bound scenarios the CPU side is delayed to prevent processing inputs prematurely and having to wait for the GPU to finish rendering the previous frame. This brings input sampling and rendering closer together reducing input latency.

Yes, waiting for the next rendered frame and basing generated frames on both previous and the next rendered frame would be horrible for latency. Even in your own example you double input latency.

This condition completely negates the entire reason for frame generation to exist which is that it can be done more quickly than rendering. You can’t claim that “We have twice the framerate compared to the native experience!” with generated frames taking just as long as rendered frames. It’s the small delay that frame generation introduces between the presentation of the previous frame and the presentation of the next rendered frame that causes the small increase in latency that framegen causes in practice. Waiting for the next rendered frame also would be borderline catastrophic in terms of input latency.

I’m not suggesting that frame generation has no place especially when input latency doesn’t matter. Just that it has inherent shortcomings and more specifically that frame generation itself should never be viewed as the solution to the very issues that it causes.

I’m afraid your example isn’t valid either. Even ignoring any time spent on frame generation the reason frame buffering has largely been abandoned in favor of reflex style loops is because the penalty paid in input latency is often unacceptable.

Frame generation would no doubt benefit from being able to use the next rendered frame in addition to previous frames but in the context of gaming the feel would be sloppy at best.

Current implementations are… go back and look at everything you just listed off. They all tie back the previous render with the exception of the following.

Without actually running game logic it can’t be anything but another guess as to what effect mouse inputs will have. Worse yet even if it did know how game logic would react it still can’t know what would be rendered as a result until after it has actually been rendered. This may have some benefit in reducing nausea in VR but it does nothing to address frame generation’s primary shortcoming which is that it’ll always be a guess of what would have been rendered. There’s no amount of marketing or tech jargon that can change this.

These forward looking technologies are interesting but understanding them is typically best done by looking back on the problems they’re intended to address rather than looking to the future. The reality of the futures of these technologies is that they’ll be incrementally improved to reduce their drawbacks and maximize their benefits. They may find a home in some scenarios but they’ll remain inappropriate in others because they do have inherent drawbacks.

1 Like
28

Yeah, but we are not talking about Reflex but Reflex 2.

32ms is still nothing and totally unimportant for a lot of games?

Not really. I just want a less blurry image. For example in Civ, this tradeoff when scrolling would be very much worth it.

Assuming we wanna achieve the blurbuster goal of 1000fps.
Assuming we are able to create 500 real frames.
That would mean that we add 2ms and get 4ms of total delay.
4ms of delay is totally fine by me.

Sure, but maybe this isn’t as bad as you make it seam.
According to research (paid by Nvidia) accuracy increases.
For most people, this is probably the most important metric.

29

Doesn’t matter… for the reason already explained.

I don’t think you can ever dismiss doubling latency as “nothing”… especially not after touting reflex which at best shaves off just a small fraction of a single frame’s latency.

It’s generated frames that are blurry in places where they’re unsure of their predictions. They can never be sharper or more accurate than rendered frames because rendered frames are literally the targets that generated frames are striving to achieve. Best case they perfectly match rendered frames.

lol, ok but now we’re just in silly 1000fps fantasy land. Just making the case that 1000fps is even desirable is a virtually impossible feat. Everything is a balance and sacrifices can not be just ignored.

Maybe if you’re already running silly high rates. Are there competitive gamers who actually use framegen… by choice?

I’m not really trying to make it seem all that bad… the issue I had is that frame generation was being painted as a solution to blur which it’s just not. Then a future where generated frames dominate was painted by an attempt to equate P-frames with generated frames despite critical differences that invalidate the comparison. I suspect frame generation will find a place eventually but as of now it seems to be more useful for marketing than in practice.

I have found DLSS to be a win more often than not. Unless without it you can still max out in game settings and peg either your monitors max refresh or a limiter of your choice. The few exceptions were early games where the implementation was botched.

nVidia’s DL DSR also often does a great job of anti-aliasing older games.

2 Likes
30

I think I see the problem with the discussion here. I have been talking about, and specifically said multiple times, that we aren’t talking about current/older DLSS3 frame generation, the topic is about the end goal for this type of tech, why it has to exist, and how it will evolve to get there. You seem to be stuck on brining up only things relevant to DLSS3 tech and are saying it cannot progress beyond that when Im not even talking about the rudimentary version that exists in games already out.

31

I’ve been referring to frame generation in general and the inherent limitations that I’ve raised will continue to exist in future iterations of the technology. “This type of tech” is predictive by nature so the issues I’ve raised will persist over the progression and evolution of the tech.

2 Likes
32

You are contradicting yourself here.
Any sort of prediction is based on previous events and fundamental laws (for example objects not stopping instantly), else the prediction would add uncertainty, not remove it.

At the point where the prediction reaches parity with the conventionally rendered frame, the entire exercise is just a new implementation of the graphics pipeline. Thing is, an approximation at a hit rate of 1 is unlikely at the best of times.

1 Like
33

Sure, when you chop my sentence in half to only select the specific words you want it does look like I’m contradicting myself.

34

Yes it does, because they are not the same.

They are to totally different things for two totally different situations, heck why even NVIDIA isn’t telling you to use frame gen but Reflex for latency sensitive games like Valorant.

Yes they can. See my picture above.

Yes, that is the blurbuster fantasy land hope for 2030. Don’t know what should be bad about that.
Looking at how OLED developed in recent years, I guess this might be possible.

No, and again, even NVIDIA is not suggesting this! On the contrary!

Mostly agree.

35

We’re just arguing marketing not tech at this point…

If you want to toss the definition of latency out the window and claim that reflex 2 delivers the latency figures that nVidia is claiming then we’re no longer even in the realm of reality and may as well be arguing about who would win, Superman or Batman.

Again if you want to claim that reflex and framegen are “for totally different situations” rather than that they’re both being sold as enhancements to game rendering then we’re in marketing land.

If you believe that generated frames can be “sharper” or better than rendered frames in any way then you have some misconceptions about what frame generation is. Detail in generated frames is derived entirely from rendered frames which is why the ideal situation for frame generation is a static scene where generating a frame just involves copying the previously rendered frame byte for byte.

What’s bad about even entertaining ridiculously high frame rates is that by doing so you’re detaching from reality by ignoring the impact on every aspect of the fidelity of rendered content including both image quality and scene mechanics. The sacrifices required for absurdly high frame rates don’t make sense now and will continue make just as little sense in the future. Pictures painted by marketing departments and fantasy tech writers like the one from Blur Busters aren’t hope, they’re just a fantasy about what things might be like in an impossible future if only we could adapt a technically incorrect view of video compression to game rendering.

1 Like
36

No. Reflex 2 adds stuff like the warp thing that isn’t there in Reflex 1. They aren’t the same.

Are you claiming that the numbers are wrong or that their definition of latency is wrong or they somehow cheat?

I really don’t know what your point is. There are two different tools for two different things.
LG will sell you a TV and an AC. Two completely different things for two completely different use cases. One feature is to reduce latency. The other one is to provide a better image with the downside of additional latency! Of course a FullHD or even less CSGO player, with the settings turned all the way down to not get distracted will NOT enable frame gen.
On the other hand, 5y from now, me playing Civ VII with frame gen on a SteamOS thing I can totally see.

To me, the fence looks better on the right

850×300 386 KB

Agree

37

the 1000hz/fps or fake frame is pointless when your source frames are already a blurry, smeary, flickery mess
garbage in garbage out.

some frame gen stuff has it’s place and i agree that nvidias “reflex 2” which is just rebranded asynchronous reprojection/timewarp
that will help a lot of low framerate games ‘feel’ smoother
assisted by screen edge frame gen

but again we have a lot of underlying issues that are being left to hardware instead of being solved first in software

nvidia shouldn’t need to create it’s own brand of async repro/timewarp (and likely patent the crap out of it), it’s such an amazing breakthrough i don’t understand why all major engines haven’t implemented it yet since it’s already commonplace in VR

Async Reprojection outside of VR
2klilksphilip explains reflex 2 warp at 5:16 well and i agree it’s more interesting than DLSS but it’s insane we have to go that far to begin with

with DLSS off and on examples is nuts, it wasn’t like this in the past. in games from 5-10 years ago one example being: Tom Clancy’s The Division from 2015 if you had no Anti Aliasing, fences would look jaggy and have that stairstep effect but they would never look Blurry or fizzy, turn AA on and you now have a smooth chainlink fence with No additonal AI frame gen required for a smooth sharp image,

AA methods have come a long way so why do we need AI powered super sampling thats paradoxically more performance intensive than ancient AA methods? or require ‘AI cores’ on your GPU to specifically handle it

why do we need fancy denoising? in the past there wasn’t any noise that required denoising in the first place!

that’s the primary issue threat interactive pushes as a number of his comparions where unreal engine vs how frostbite engine handles rendering

i will say looking into TI more he’s apparently abandoned their teams game project to focus on their LOD tool? which isn’t surprising if it’s a very small team as mentioned earlier trying to make a game along side that is wishful thinking

others have challenged TIs videos and yeah there’s definitely hit or miss with his content, but the main issues hold true: epics lack of optimization guides for real time games, game devs using marketplace assets designed for film that aren’t optimized for games, simply ticking the wrong box in engine can kill performance long term as it may be a feature designed for something entirely different to games
so a lot of their focus is Unreal Engine specific issues, however

weirdly RDR2 which uses rockstars RAGE proprietary engine has a lot of dithering/fizzing/blur so whatever underlying issues popping up in more recent games aren’t just singled to UE5

so we can only guess at wherever these issues originate from, far more experienced engine devs really have to deep dive and let devs know what to do/not do
maybe some of its tech debt, maybe some fancy paper released claimed some new method can solve all your problems when in reality it creates a ton more but there’s already so much time and money spent on implementing this into the engine that itad take far too long to remove/replace it? ditto for patching new features onto legacy code?

speaking of motion clarity and blur busters: CRT Simulation in a GPU Shader, Looks Better Than BFI
i wonder if we’ll see something like this pop up more often though if it can cause issues with older LCDs maybe not?

Yet another issue in this clusterfuck that Wendell covered is manufacturers lying about monitor specifications
sure someone can claim some fancy new monitor is 1000hz! and it might accept that signal but in reality as wendell put ‘it physically cannot respond fast enough’ at a higher hz
so that’s another fun one to look out for.

3 Likes
38

Both… the numbers are wrong because they’ve cheated by changing the definition of latency. The pre-reflex 2 definition of latency was the amount of time taken to process input, run game logic and update the scene, render the new scene, and present the new scene. Hence the mouse click to muzzle flash test. Reflex 2 redefines latency excluding both game logic and scene update by grabbing new mouse inputs after frames are rendered and then altering them before presentation. This makes reflex 2 and frame generation both technologies that predictively alter rendered images without the benefit of game logic, scene update and rendering which is why they both suffer the same issues that I’ve raised. So in the context of my previous posts, they’re the same.

I’ll actually be surprised if in the future they don’t unify both features and start taking mouse inputs into account for frame generation and never present rendered frames unaltered at all.

This has been a recurring theme with nVidia. DLSS, framegen and now reflex have each changed the definitions of resolution, framerate and latency respectively. DLSS games aren’t really rendering at their claimed resolution, games using framegen aren’t really rendering at the frame rates claimed, and games using reflex 2 don’t actually have latency as low as claimed.

My point is that they’re both being marketed to enhance game play despite one targeting latency and the other frame rate they’re both predictive in nature.

100% it’s a massive improvement. The issues mostly creep in when scenes are in motion, particularly in areas where parts of the image where details were occluded in previous frames. Even in your example though it looks like there’s an artifact in the top right, two white spots on the fence.

All these predictive technologies come at a cost and when they’re being painted as though prediction itself is the solution to the problems that using prediction in the first place introduces, that’s what I have an issue with.

Because in VR it can (under some circumstances and if well implemented) reduce nausea so it’s worth it. In the context of gaming though it’s additional time spent between input and presentation which although it dramatically reduces “latency” by nVidia’s definition it slightly increases it in the traditional sense.

The main reason is because the same modern deferred shading that provides us with dramatically better lighting doesn’t work with traditional anti-aliasing techniques and also struggles with translucency. The workaround often involves using the alternating checkerboard technique shown in the TI video which is generally designed to work in conjunction with some for of temporal AA. That’s where most of the shimmering and smearing in modern titles comes from.

UE4 is still an option. The main issue with UE5 is that advancements in the performance of GPUs at mainstream prices considerably slowed. Had they continued on pace at after Pascal nanite and lumen would be much more usable by many more gamers. I don’t think there’s anything fundamentally broken about UE5, it just has yet to come into its own. It’s also highly accessible so misuse of its vast number of configurations and features is inevitable.

1 Like
39

I really hate that people are touting reprojection as though it’s a good thing, citing VR. It’s NOT a good thing in VR, avoiding reprojection is the golden goal of dialing in your settings. It’s used as a CRUTCH for VR, because high frame rates, and really more specifically refreshes, is incredibly important. Not to look good, but to not cause you physical pain and suffering when your REALITY as far as your eyes and brain are concerned starts stuttering and flickering.

1 Like
40

I’m sure that’s true, possibly more often than not. I added the disclaimer “(under some circumstances and if well implemented)” to my post.

1 Like