Suggestion: include and preprocess FXAA (or TXAA or SMAA if you can afford it)

[ni1chigo2115]

It's been quite some time since Reshade was disabled in VRChat. I've been using nvidia's TXAA and FXAA settings, but I'm a bit skeptical that they are properly adapted to VR. Either way, relying on FSR&MSAA alone in a game where Reshade is not available but MSAA is a bit harsh for those who care about performance.

So could you please provide a setting to apply post-effect anti-aliasing such as fxaa before applying the fsr effect?

I don't get any additional information when upscaling an image. (Unless it's ML upscaling like DLSS), it doesn't provide any AA. Furthermore, with FSR, the image must already be well AA'd before upscaling. https://steamcommunity.com/app/993090/discussions/0/3034851135422178593/#c3035977580514594170

The last step in FSR is the sharpening process. For games that don't have AA, it's better to use FXAA before FSR; it gives a better effect than applying AA after FSR. https://steamcommunity.com/app/993090/discussions/0/3034851135422178593/#c3035977580514748739

There is some information in this thread that says you should anti-alias before applying the FSR effect, but it's not clear if it's after or before you increase the resolution. If you are going to add the feature, I will leave it to your side to decide.

Translated with www.DeepL.com/Translator (free version)

[fholger]

As far as I know, NVIDIA options do not work for VR games, at least not in the headset.

In my personal experience, FXAA and even SMAA are not very good in VR. This is due to your constant head movement, which makes temporal aliasing a much more significant issue than in flat games. And FXAA/SMAA do not help against temporal aliasing. FXAA, in particular, will therefore just blur your image without giving you any meaningful AA in VR. So I'm skeptical that this is worth adding.

Only MSAA and TAA can really work well in VR. And yes, MSAA is expensive, but with FSR you can lower the render resolution further to offset the cost, and it will probably be worth it.

[ni1chigo2115]

reshade has an effect that is equivalent to TAA, could this be implemented? https://github.com/BlueSkyDefender/AstrayFX/blob/master/Shaders/Temporal_AA.fx

[fholger]

I'm afraid not. It requires access to the depth buffer, which I don't have. Also, it is a somewhat limited version of TAA, and when I tried it in Skyrim VR out of curiosity, it did not work well.

"Full blown" TAA solutions cannot really be implemented as a generic post-processing effect, since they require motion and depth buffers and tweaking for the particular game.

[ni1chigo2115]

Even though PC is the main hardware, I think the cost of MSAA is too heavy, so I am hoping that some good effects will be developed for VR.

Also, in using FSR, I think you need a guide that allows you to feel the effects of the trade-off between resolution and MSAA.

[fholger]

MSAA 4x at SteamVR 100% resolution means that edges are rendered as if you had selected a SteamVR resolution of 400%. Yes, it's costly, but the effect for edges is much higher than whatever resolution increase you can get for the same price. So in my opinion always go for MSAA over resolution, unless you are really struggling for performance and would have to lower resolution so much that it'd look like crap, anyway. But otherwise, enable 2x MSAA at a minimum, 4x if you can, then choose resolution appropriately to get decent performance.

[ni1chigo2115]

I did a lot of testing, and it seems to me that the best way to eliminate jaggies between is to keep MSAA at x2 and upscale it n times with FSR, assuming a 90-100% HMD working resolution. The best way to do this is to set the game resolution to n00%, assuming a 90-100% HMD working resolution, and then use FSR to bring it down to the working resolution, and then upscale to nx. If the rendering resolution is set at 1:1 with HMD, I think the artifact jaggies emitted from the glossy representation of the object's material that occur when the resolution is reduced by FSR are too harmful. This cannot be removed by MSAA, which uses meshes to determine depth and jaggies. (This is why I used FXAA and SMAA to mitigate the artifact jaggies.)

Since VRTOOLKIT, RESHADE's effect for VR, also has FXAA, I feel that FXAA is not necessarily meaningless in VR. https://github.com/retroluxfilm/reshade-vrtoolkit However, the most effective way to do this is to not reduce the base resolution of the game too much from the hardware resolution of the HMD. If you want to get rid of artifact jaggies in VR, it is best to increase the game's base resolution.

Translated with www.DeepL.com/Translator (free version)

[ni1chigo2115]

I've set up the following on Quest2 so far virtualdesktop, VRLow (I think the horizontal resolution is about 17xx) SteamVR, 100% resolution VRChat, resolution 200%. MSAA x2 OVRFSR, resolution 0.5 ・Sharp 1 Also the environment is Ryzen 1700 GeFroce1060 6G (That Cheap) VRC has videos that can be viewed in-app, but if you lower the base resolution too much, the artifacts will look terrible. It's probably best to increase the resolution there, hoping for an upconverter effect, and let the game run at a resolution between FSR use, 90% and 100%.

Translated with www.DeepL.com/Translator (free version)

[ni1chigo2115]

https://github.com/fholger/openvr_fsr/issues/90 It seems to me that the improvements to the routines I'm putting in the issue, which are intended for mobile use, will reduce the processing load on the FSR and increase the target resolution, although it does say that the detail is weaker than normal FSR.

[WizzDude]

Another good way to remove aliasing with FSR on is to set it to render higher than your native res, ex. 1.25, and then lower your render resolution in SteamVR to around 75% or 80%. It acts as a Supersampling filter and definitely has less aliasing compared to setting FSR to less than native. It might be slightly blurrier because of the lower resolution though

[d0x360]

Another good way to remove aliasing with FSR on is to set it to render higher than your native res, ex. 1.25, and then lower your render resolution in SteamVR to around 75% or 80%. It acts as a Supersampling filter and definitely has less aliasing compared to setting FSR to less than native. It might be slightly blurrier because of the lower resolution though

Bingo! Unless you're on oculus, then I'd use oculus tray tool for super sampling. You can tweak some visual stuff while in game because the tool has voice commands

[krillme]

I also believe preprocess anti-aliasing could be a valuable addition due to how important anti-aliasing is when it comes to upscaling. While MSAA is obviously the optimal choice, it can reduce performance, not every game supports it, and some games don't have anti-aliasing at all. Upscaling an aliased image often produces a result worse than bilinear filtering, so having some kind of system to blur the image before upscaling it could be useful in some circumstances, especially considering the point of this tool is to improve performance and MSAA can be costly to run.

I'm not sure if Reshade is loaded before or after vrperfkit, but if it's loaded before perhaps some testing could be done to prove the benefits of such a process.

Also as previous users said, a more user friendly way to supersample the image before upscaling could be beneficial. Perhaps a secondary value could be implemented like "renderSize" that would change the size of the rendered image with basic scaling. If we use a 1000x1000 resolution as an example, setting "renderScale" to "0.8" and "renderSize" to "0.7" would render the image at 800x800, scale down it to 700x700 to create a supersampling effect, then finally upscale it back to 1000x1000. If "renderScale" was set to "0.7" and "renderSize" to "0.8", then the image would be rendered at 700x700 and scaled up to 800x800, reducing the amount of upscaling done to improve performance. Alternatively, "renderSize" values higher than the "renderScale" value could just be disabled altogether.

[d0x360]

MSAA is probably the worst method other than FXAA for modern games..

MSAA only helps smooth jaggies on a mesh. So objects made of triangles. It doesn't help with anything else in the pipeline. That's why it does nothing for shimmer or jaggies in post effects.

Perfect example of why MSAA doesn't work in a modern game is Forza horizon 4 & 5 and GTA5. You can run the games at 4k which essentially gets rid of jaggies on a mesh by itself...

Of course effects applied to that mesh can have aliasing too which is why Forza and GTA are great examples...

Look at the cars in Forza. Even at 4k with 8xMSAA there is still jaggies and shimmer. Essentially the lighting itself is what's causing them because the mesh itself is perfectly smooth with no MSAA.

So MSAA would be great in old games like dx10 or lower or a new game that is made the same way older games were made. So a very simple and static lighting system with baked shadows everywhere. The problem is you don't really see games made that way anymore.

Lastly MSAA is incredibly expensive from a rendering budget point of view. So using it when it's not really doing much is such a waste.

It's looking like FSR 2.0 or XeSS is going to be the way to go. FSR 2 will work on anything and doesn't require driver support like DLSS does. XeSS doesn't require driver support either and they both take the final image and work their magic on that.

On Fri, Apr 1, 2022, 7:11 PM krillme @.***> wrote:

I also believe preprocess anti-aliasing could be a valuable addition due to how important anti-aliasing is when it comes to upscaling. While MSAA is obviously the optimal choice, it can reduce performance, not every game supports it, and some games don't have anti-aliasing at all. Upscaling an aliased image often produces a result worse than bilinear filtering, so having some kind of system to blur the image before upscaling it could be useful in some circumstances, especially considering the point of this tool is to improve performance and MSAA can be costly to run.

I'm not sure if Reshade is loaded before or after vrperfkit, but if it's loaded before perhaps some testing could be done to prove the benefits of such a process.

Also as previous users said, a more user friendly way to supersample the image before upscaling could be beneficial. Perhaps a secondary value could be implemented like "renderSize" that would change the size of the rendered image with basic scaling. If we use a 1000x1000 resolution as an example, setting "renderScale" to "0.8" and "renderSize" to "0.7" would render the image at 800x800, but then scale down it to 700x700 to create a supersampling effect, then finally upscale it back to 1000x1000. If "renderScale" was set to "0.7" and "renderSize" to "0.8", then the image would be rendered at 700x700 and scaled up to 800x800, reducing the amount of upscaling done to improve performance. Alternative,y "renderSize" values higher than the "renderScale" value could just be disabled altogether.

— Reply to this email directly, view it on GitHub https://github.com/fholger/openvr_fsr/issues/92#issuecomment-1086403767, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADLH3GPXNKJ5TC6CGK4LV4TVC57ALANCNFSM5DQKL3IQ . You are receiving this because you commented.Message ID: @.***>

[krillme]

Can't speak for XeSS as Intel has been incredibly secretive about it but FSR 2.0 is a temporal effect much like DLSS which must be implemented on a per-game basis. It doesn't just work on the final image, it can't be used as a post-process effect on any game. At least as far as we know right now.

[d0x360]

Probably right.. I was thinking about it backwards. It's using temporal data but not any kind of ai created profile that lives in a dll file like DLSS...

XeSS will likely be the same in terms of temporal data.

I was working on a project to inject TAA into games that don't "support" it and I had it working about 75% of the time. Basically as long as the engine itself supported it I could make it work 75% of the time even in games that didn't have any temporal AA.

I gave up on it because I was doing it for openvr_fsr and basically told it wouldn't be happening. I had it working in VR in almost all case's but I had to work on a game by game basis and it wasn't worth the time if nothing was going to come of it.

So as far as VR goes the best AA is still super sampling although even that won't eliminate jaggies in alpha effects.

The best way to show that is actually alien isolation. You can run it at 8x your native resolution and it will still shimmer in the distance and show jaggies on save stations or anything with a certain surface material and light hitting it.

It also happens to be a game you can add VR support into (mother VR) and inject TAA...and damn does it look good. Not a jagged edge to be seen anywhere and it also becomes 100% shimmer free.

On Fri, Apr 1, 2022, 7:55 PM krillme @.***> wrote:

Can't speak for XeSS as Intel has been incredibly secretive about it but FSR 2.0 is a temporal effect much like DLSS which must be implemented on a per-game basis. It doesn't just work on the final image, it can't be used as a post-process effect on any game. At least as far as we know right now.

— Reply to this email directly, view it on GitHub https://github.com/fholger/openvr_fsr/issues/92#issuecomment-1086418695, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADLH3GPTLVH7Y25HEQ5GYMTVC6EFRANCNFSM5DQKL3IQ . You are receiving this because you commented.Message ID: @.***>

[WizzDude]

MSAA is probably the worst method other than FXAA for modern games.. MSAA only helps smooth jaggies on a mesh. So objects made of triangles. It doesn't help with anything else in the pipeline. That's why it does nothing for shimmer or jaggies in post effects. Perfect example of why MSAA doesn't work in a modern game is Forza horizon 4 & 5 and GTA5. You can run the games at 4k which essentially gets rid of jaggies on a mesh by itself... Of course effects applied to that mesh can have aliasing too which is why Forza and GTA are great examples... Look at the cars in Forza. Even at 4k with 8xMSAA there is still jaggies and shimmer. Essentially the lighting itself is what's causing them because the mesh itself is perfectly smooth with no MSAA. So MSAA would be great in old games like dx10 or lower or a new game that is made the same way older games were made. So a very simple and static lighting system with baked shadows everywhere. The problem is you don't really see games made that way anymore. Lastly MSAA is incredibly expensive from a rendering budget point of view. So using it when it's not really doing much is such a waste. It's looking like FSR 2.0 or XeSS is going to be the way to go. FSR 2 will work on anything and doesn't require driver support like DLSS does. XeSS doesn't require driver support either and they both take the final image and work their magic on that. …

MSAA worked well in games with forward rendering, and most VR games use forward rendering to increase performance. This means MSAA works really well in VR, but sucks in recent non-VR games. It makes an incredible difference in H3VR and Pavlov even at 2x MSAA.

[d0x360]

Forward doesn't really matter. MSAA only cleans up jaggies on triangle's. So yes visually simple games that were developed almost like dx9 games are fine but any game using more modern alpha effects isnt going to be helped by MSAA.

Developers should have been using a more efficient and effective anti aliasing solution since day 1. Needing super sampling and 4xMSAA (or higher) is incredibly inefficient. They should be able to output a clean image without MSAA or SSAA.

Pavlov for example runs on an engine that supports MSAA, SMAA, and multiple variants of temporal AA. Not using at least SMAA is kind of ridiculous when you think about it.

Even more so when you look at the steam hardware survey and what people are running.

Then there's the quest line... The lack of resources due to a mobile SOC should have pushed every game developed for quest and quest 2 should have low cost but effective AA.

On Mon, Apr 4, 2022, 8:15 AM WizzDude @.***> wrote:

MSAA is probably the worst method other than FXAA for modern games.. MSAA only helps smooth jaggies on a mesh. So objects made of triangles. It doesn't help with anything else in the pipeline. That's why it does nothing for shimmer or jaggies in post effects. Perfect example of why MSAA doesn't work in a modern game is Forza horizon 4 & 5 and GTA5. You can run the games at 4k which essentially gets rid of jaggies on a mesh by itself... Of course effects applied to that mesh can have aliasing too which is why Forza and GTA are great examples... Look at the cars in Forza. Even at 4k with 8xMSAA there is still jaggies and shimmer. Essentially the lighting itself is what's causing them because the mesh itself is perfectly smooth with no MSAA. So MSAA would be great in old games like dx10 or lower or a new game that is made the same way older games were made. So a very simple and static lighting system with baked shadows everywhere. The problem is you don't really see games made that way anymore. Lastly MSAA is incredibly expensive from a rendering budget point of view. So using it when it's not really doing much is such a waste. It's looking like FSR 2.0 or XeSS is going to be the way to go. FSR 2 will work on anything and doesn't require driver support like DLSS does. XeSS doesn't require driver support either and they both take the final image and work their magic on that. … <#m-5247511139289977064>

MSAA worked well in games with forward rendering, and most VR games use forward rendering to increase performance. This means MSAA works really well in VR, but sucks in recent non-VR games. It makes an incredible in H3VR and Pavlov even at 2x MSAA.

— Reply to this email directly, view it on GitHub https://github.com/fholger/openvr_fsr/issues/92#issuecomment-1087481160, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADLH3GJGVWS2P2JQSIJKJQDVDLMN3ANCNFSM5DQKL3IQ . You are receiving this because you commented.Message ID: @.***>

[fholger]

The problem, though, is there is no "low-cost but effective" AA for VR. FXAA and SMAA (except, perhaps, for the more advanced modes which either mix in MSAA or a form of temporal AA) do not work great in VR. The reason being that they do nothing against temporal instability, which is a major issue in VR due to the constant head movements.

And even TAA or DLSS so far do not have a particularly great work record in VR. Few games get the balance between anti-aliasing and blurriness quite right, and blurriness in VR can be as bad as aliasing, depending on your personal perferences and tolerances.

And yes, MSAA "only" cleans up geometric aliasing, but that is still a huge part of the aliasing, and it at least delivers reliably. Unlike TAA, which is extremely difficult to get just right.

[Crimson-foxGITHUB]

Then there's the quest line... The lack of resources due to a mobile SOC should have pushed every game developed for quest and quest 2 should have low cost but effective AA.

@d0x360 The thing about mobile renderers is because of how they’re designed, 4X MSAA IS that low-cost AA. The base render resolution is high enough that it doesn't feel like MSAA.

[Crimson-foxGITHUB]

Forward doesn't really matter. MSAA only cleans up jaggies on triangle's. So yes visually simple games that were developed almost like dx9 games are fine but any game using more modern alpha effects isnt going to be helped by MSAA. Developers should have been using a more efficient and effective anti aliasing solution since day 1. Needing super sampling and 4xMSAA (or higher) is incredibly inefficient. They should be able to output a clean image without MSAA or SSAA. Pavlov for example runs on an engine that supports MSAA, SMAA, and multiple variants of temporal AA. Not using at least SMAA is kind of ridiculous when you think about it. Even more so when you look at the steam hardware survey and what people are running.

SMAA is natively supported by Stormland and it doesn't clean up image quality nearly as much as you'd expect that form of anti-aliasing to. TAA was developed because of modern games switching to deferred renderers to take advantage of lower costs per light anyways: because VR games are primarily going back to forward rendering, using MSAA makes perfect sense.

Jaggies due to material type are something VR gamedevs actively design around, due to MSAA being the cheapest anti-aliasing solution that doesn't have other inherent downsides without cranking up the resolution(such as TAA's inherently soft output)

[d0x360]

Gonna need to edit that... Some weirdness happened lol

so I just deleted the entire thing and then pasted it back in, the double quote from the 2 posts combined with the book I wrote caused GitHub to freak out. The "makes sense" version is posted below 👇

[d0x360]

@d0x360 The thing about mobile renderers is because of how they’re designed, 4X MSAA IS that low-cost AA. The base render resolution is high enough that it doesn't feel like MSAA.

Forward doesn't really matter. MSAA only cleans up jaggies on triangle's. So yes visually simple games that were developed almost like dx9 games are fine but any game using more modern alpha effects isnt going to be helped by MSAA. Developers should have been using a more efficient and effective anti aliasing solution since day 1. Needing super sampling and 4xMSAA (or higher) is incredibly inefficient. They should be able to output a clean image without MSAA or SSAA. Pavlov for example runs on an engine that supports MSAA, SMAA, and multiple variants of temporal AA. Not using at least SMAA is kind of ridiculous when you think about it. Even more so when you look at the steam hardware survey and what people are running.

SMAA is natively supported by Stormland and it doesn't clean up image quality nearly as much as you'd expect that form of anti-aliasing to. TAA was developed because of modern games switching to deferred renderers to take advantage of lower costs per light anyways: because VR games are primarily going back to forward rendering, using MSAA makes perfect sense.

Jaggies due to material type are something VR gamedevs actively design around, due to MSAA being the cheapest anti-aliasing solution that doesn't have other inherent downsides without cranking up the resolution(such as TAA's inherently soft output)

I had a very long and in depth response I was typing the day @fholger made theirs and I was... Many paragraphs in and writing it in this crap zFlip3 and then I lost all of it except for the first couple of paragraphs and I didn't wanna retype it all.

Then I got your reply and I figured I'd just let it lie and not respond because whose right/wrong generally leads to arguments and that's not what I want and this isn't the place for it...

However, I can't let both those post sit there because they are incorrect in too many ways both technically and from a development point of view. I say that in the hopes you will continue learning because if you're here you must have some passion for how technology works.

So... Let's start with modern rendering, and I'll keep this as short as sweet as possible... But it's gonna be long.

Also TAA isn't "inherently" soft, it depends on multiple factors which I touch on later but to summarize that point it's basically the algorithm used, number of frames used, number of samples per frame, and the resolution itself. At native 4k and normal viewing distance even middle of the road in terms of quality TAA looks fine.

First most modern games are NOT deferred rendering. Most are a mix of forward and deferred with a heavier leaning towards forward. Deferred was created at a time when games were getting very atmospheric with lighting and (baked) shadows. Both of which are expensive in the rendering budget generally speaking. So deferred rendering was used mostly during the 360/PS3 era because it allowed lots of lights although lighting and shadow were baked into the scene which means they aren't simulating light therefore can't have occlusion shadows.

These days we have better ways to light games. We have more dynamic lights, light bounce, RT or SVOGI usually. Technically you can use these in a deferred pipeline but you need to be careful with how you bake your shadows. Deferred also causes more issues with anti aliasing an image than forward in regards to MSAA & SSAA. A temporal solution is generally best.

In a deferred pipeline the shading is done on the framebuffer image which is a problem for MSAA because it has no way of telling one object from another while a temporal solution like TAA or SMAA doesn't need that information and relies on color data. This basically makes MSAA more costly on performance because it's acting more like SSAA than MSAA.

Now as far as VR goes they generally use forward rendering because it's a good deal faster even on older GPU's. The games use a simpler lighting system in most cases so deferred rendering would just add unnecessary latency.

Now as far as SMAA goes... It really depends on the algorithms used because unlike something like MSAA or SSAA which have very defined methodology in how they work, SMAA can use any number of open source or custom algorithms for it's temporal component and then it combines that with MSAA. Sometimes it looks great and other times it leaves lots of shimmer and jaggies.

TAA also has multiple algorithms so TAA in Game Z might look significantly better or worse than an equal sample count TAA implementation in Game Y. Also assume the final sharpen pass is equal.

You're right MSAA has worked well for VR because it doesn't require any temporal data which means less latency and even more so because VR games, especially on the quest have limited horsepower so they use simple geometry and lighting. It's not JUST a materials issue or lighting, specular detail etc it's a combination of all of it and it's a task MSAA is NOT suited to handle. In fact it probably won't be very effective for whatever replaces the quest 2 assuming it doesn't use the same SOC or devs don't use the extra power for resolution and frame rate alone.

If you compare the same game on PC VR to a quest 2 port you can see the biggest differences in geometric complexity, lighting & shadows. That will change as time goes on and mobile chips get higher levels of performance.

When that happens we will likely see a shift in AA methods. Either a bigger focus on SSAA even if it leaves jaggies & shimmer on specular highlights amongst other things. If we do mainly switch over to something temporal we are going to need to also ensure frame rates remain high as with VR (generally and ideally speaking) you want as few frames rendered ahead of what you see as possible.

That's why nVidia & AMD default VR in their GPU CP to 1 frame beyond what you see. They don't want to render 2-4 extra frames ahead for temporal aa because the lower the frame rate the worse it would look as what you see wouldn't match up properly.

Now if we were talking 120hz or higher and the higher the better then it's not really an issue. Of course VR is more expensive to render than flat even if the difference between frames per eye is very minor. So if you have say... 2k per eye with a goal of 120fps then you either cut back on visual complexity or you need to wait for better hardware.

Consider that 2k per eye is not exactly 4k due to VR trickery, it's still very close. So you would need a gpu that can render that same game flat in between essentially 3200x1800-3820x2160 at 144fps if not higher as long as it's divisible by 8. VR isn't 16x9 so resolution doesn't need to be divisible by 8 but if you're going for "4k" then it should be just for the sake of aspect ratio preservation.

[d0x360]

Ok I think I fixed everything. There was stuff in the wrong place, stuff missing and stuff in the post twice.

Dunno what happened there but I think it was doing a quote from 2 different posts combined with the length.

I didn't spell check... I typed it on my phone again lol but this time I typed it in a note app so I wouldn't lose it.

If you have any questions or want me to clarify something just ask. We can even take it to discord to keep the forums more... On topic. Even though this is directly related to the project it's not really what the forums are meant to be used for.

Lastly I wanna mention I have TAA and I mean that as in pristine image quality on the quest 1 & 2 as well as the Rift & Rift S working in about 92% of games. Valve actually gave me the idea for how to make it work when TAA isn't natively supported by the engine. Think along the lines of their solution to Elden Ring.

I also may have gotten DLSS 2.x working in a good number of games thanks to some friends at nVidia. So basically PC flat quality at 1440p 120fps locked. It's... Amazing but I'll get shot if I share it. Thankfully FSR 2 is upon us and hopefully it can be added to this project even in games without native support. Based on how much of the technical documentation I've read (ty epic! & AMD lol) it should be easier than TAA or DLSS.

That being said... It's not my project nor will I start a competing one out of respect for @fholger. This is his baby and I love using it & watching it grow. The stuff I've been doing is basically over and was just a distraction during downtime at work. Back to the robot's I go!

Ok I think I've written plenty lol. Have a good one.

[Crimson-foxGITHUB]

Consider that 2k per eye is not exactly 4k due to VR trickery, it's still very close. So you would need a gpu that can render that same game flat in between essentially 3200x1800-3820x2160 at 144fps if not higher as long as it's divisible by 8. VR isn't 16x9 so resolution doesn't need to be divisible by 8 but if you're going for "4k" then it should be just for the sake of aspect ratio preservation.

Most HMDs also report a resolution 1.4x higher than their listed on-store screen resolution to account for barrel distortion and have physical screens designed to account for this. If you wanted to effectively get “4K” image quality out of a current-lens-tech VR headset, you’d need to render the image at around 3024x3024 per eye.

The thing about that is that because in VR you’re rendering the entire scene twice, that level of performance requirement skyrockets so much that most GPUs are simply not powerful enough to handle it on even medium-performance titles. This is why I still think MSAA and TAA will still be the go-to anti-aliasing systems for a while and that HMD resolutions and framerates will just keep increasing instead: the Quest 2’s inherent strengths and weaknesses as a piece of hardware cater themselves extremely well to MSAA as-is.

It’s to the point that some Quest ports of deferred-renderer games on PC switched to forward rendering on Quest(see: Phantom: Covert Ops, which uses 4X MSAA on Quest)

Also this project is technically considered deprecated, so you could send fholger a PR on VR Performance Toolkit with your FSR 2.0 code. That project is planned to have more features than this and isn’t even the lead thing fholger’s been working on as of recently: fholger’s the lead dev on the restarted Half-Life 2 VR project.