Also beware that if it’s the last option You shouldn’t put a comma there 
It’s read as a list of key/value pairs and it’s comma separated.
3 Likes
If you are still having problems send me your steamvr.settings file and I’ll take a look.
By the way, disable all unnecessary peripheral devices under Startup/Shutdown -> manage addons. Turn off everything but StarVR and turn off every startup app except Revive and then try making the change. I have fpsvr disabled because it doesnt seem to work anyway with custom resolution set.
3 Likes
Nice!!! This actually makes a lot of sense to me. Remember how the 4 viewport rendering in Showdown showed 2 lower res renderings for the whole FoV and how I said that I felt that that’s actually the reason the resolution is too low (they just seem to use those 2 low res renderings) in regular SteamVR content and much better in the optimized Showdown demo? Then @jojon said “well then just scale, use more SS”, which made a lot of sense but just didn’t work somehow. So that setting might actually have caused that! I had that setting set a while ago but on my new PC I never changed it… Damn, wish I had tried it.
Either way,so I suspect the driver indeed always renders the 4 viewports but the compatibility layer just only uses the 2 lower resolution ones (the whole FoV). Which would be extremely inefficient of course … But I’m guessing that’s the reason why we even need that setting.
6 Likes
I set the value in this default.vrsettings file and it worked that way. I could never make the steamvr.vrsettings file retain the settings, but the default.vrsettings worked. Then I tried to run Final Assault and it was about 5 fps :(. But yeah thats great that it seems to work! Maybe super sampling 5 is a bit too ambitious even for a 2080ti… Thanks for all the help guys and @NextGenVR for mentioning it.
3 Likes
Hehe. But what about the resolution? Do you indeed see a rather big step up?
2 Likes
This file has something like if mem serves 3 different locations.
1 Like
Hmm I actually doubt now that what I said above is correct (about the apps always rendering 4 viewports and just discarding 2 for nonoptimized content). I just checked some older logs and it seems multiview rendering only is enabled when running the showdown demo. And I guess it also makes no sense, since I don’t think a driver can force a game to render 4 views when the game actually wants to render only 2. Or what do you think @jojon you know a lot more about that
Anyway this is the output that I was looking for and it only shows when running showdown:
Sat Jun 13 2020 16:20:55.035 - StarVR: Rendering_SetMultiView m_currentPid:7244 Mode:1
(where that process ID is the Showdown demo)
1 Like
Once I am done and all said and done. I will talk and possible share with some
2 Likes
Well, that is five times the no-supersampling pixel-shader workload, so if the application has any amount of fancy graphics to begin with… :7
Yep; Default.vrsettings will work - one just need to remember it resets every time SteamVR updates. :7
Heh, I don’t know nuttin’, really; Just seem to sadly lack the sense to keep my mouth shut. 
As far as I know, it is precisely as you say there, though. :7
I wonder what the OpenXR API allows, and how well the implementations of it, from each runtime supplier (Valve, Oculus, Microsoft, Pimax?, StarVR?, etc…) supports it…
Cool - sorry about the nosiness.
4 Likes
Try it in Half Life Alyx, Pavlov, Pistol Whip and The Walking Dead. I got a smooth experience in those games. For Pavlov and Walking dead turn VRSS to adaptive in nvidia control panel settings -> program settings. Interestingly, VRSS slightly lowers the amount of mura I see in Pavlov. The supersamplescale 5 is just setting the resolution to max. Try switching between manual 500% and auto. I have mine set to auto. Also make sure you play in 72Hz. The lower the refresh rate, the better your GPU can handle the higher resolution rendering.
3 Likes
Yes, the resolution was very good, but the slideshow was unplayable yeah :). But I’m sure it varies per game and that the games dmel642 mentioned would work at those settings
3 Likes
SteamVR will delete any values which match setting values elsewhere (or it’s possible you’re not changing the right file). I had this problem also (for a while). Also, if you’re not editing the right file, SteamVR will replace the contents every time it updates. That’s a real pain if you’re using the SteamVR beta, which updates frequently.
Try using a different value; I use 12288. That might keep it from being deleted, but ONLY make that change in 1 file, ideally the correct file.
2 Likes
Heads-up for @VR-TECH @Djonko @NextGenVR and others using StarVR One and hmdq tool.
I was able to get the complete geometry readings from StarVR One headset (thanks to an unnamed benefactor) and I found out several interesting things about its FOV and also a bug/problem with hmdq, which means that the FOV readings from hmdq related to StarVR 210° mode are not correct.
The raw FOV frustum (i.e. without considering the HAM) is indeed 210° in “native” mode. Which already busted my visualization algorithm for HMDGDB, as this can only work < 180° FOV because there is no way to project bigger FOV onto a plane. To show FOV bigger than 180° I would need to create a different model, possibly using a projection onto a sphere and redo all geometry modelling algos.
This is however not the problem I discovered. When hmdq calculates the “masked FOV” i.e. using the HAM with the projection frustum getting out of the 180° degree half-sphere, it leads to incorrect calculation and the values.
I can see that the StarVR One HAM limits the peripheral part of the FOV, and makes the visible horizontal part smaller than 180°, but it is definitely more than 172° the tool reports now (my estimate is ~ 178°, i.e. just a tad bit smaller than 180°).
I am currently looking into fixing it, but it is too early to say, how long it will take.
11 Likes
Very cool, thanks for sharing!
2 Likes
Interesting. Odd thing is that also in Oscar rov tool, commercial version, I couldn’t see beyond 172.
Then again, this probably was one of those cases that if you think something is true, you don’t look too hard for evidence of the contrary. Meaning that I think I remember that i didn’t take off the foam. I just saw 172 and thought, hey that’s what Risa’s tool showed so that’s correct then. Maybe if I had removed the foam, pressed the headset against my head that there actually was more FoV
2 Likes
I cannot speak for Oscar’s tool, but chances are that it might be difficult to perceive a few degrees difference at a such extreme periphery.
4 Likes
I’ve never tried a Pimax but I knew your tool was inaccurate from the beginning. Just from pure observation I can tell that the field of view is very near human vision. There’s still some black border at the peripheral but just barely. 10 to 20 degrees more and I could see no border at all.
You need to realize just because 220 is the Human FoV doesn’t mean one has the full Monty due to face shapes. As @Djonko mentions in a fashion using the RoV tool
3 Likes
I doubt that you can notice the difference from pure observation because as I wrote above the correct value would still be less than 180°. But even if it would be 180° and the wrong value was 172° this would make 4° difference at periphery. To notice this difference you would need to be trained or have some kind of tool (as Oscar’s app for example).
It is quite difficult (for an untrained eye) to quantify the FOV it sees correctly (this forum is an excellent example for that).
5 Likes
That’s right, in my case with my face shape I cannot see any borders on the sides or top at all, only the bottom.
4 Likes