This reminds me of the ‘advanced supersample filtering’ option in steamVR. Most people dismissed it as downright blurry and never used it, but it is probably just a different scaling and interpolation process than traditional steamvr SS.
btw, i come to this site to take breaks from my EE job, not be reminded of it 
we were just discussing the proper sampling frequency of our DAQs
Well, sorry about that. 
The ‘advanced supersample filtering’ option IIRC was intended to be unchecked for legacy applications that do not support it. At present, it does not seem to have any impact on visual quality.
I do not care if you take vertical, total or whatever for your personal evaluation, but claiming that SteamVR supersampling at 125% (1.25x) is equivalent to PiTool at 1.25 is not a conclusion of it. The image quality depends on pixel density and it depends on vertical and horizontal res. Saying the horizontal res does not matter is confusing at least.
I set the same horizontal and vertical resolution in SteamVR regardless of which setting PiTool is at. PiTool at 1.25x, causes both the SteamVR horizontal and vertical resolution to increase by 1.25 times.
I did not say the horizontal res does not matter. I said, I set the SteamVR resolution to at least a minimum number of vertical pixels, which logically, multiplies the horizontal res by the same amount.
Ok, then, to complement PiTool at 1.25, you actually have to set SteamVR multiplier to 1.25x1.25=1.5625. Do you agree that calling this “setting SteamVR to 1.25” (which is what you wrote in your post) is at least confusing?
I am getting confused, so I agree I must be writing confusing things.
1.00 * 1.25 = 1.25
1.25 * 1.00 = 1.25
That is how I set PiTool/SteamVR to identify there was a blur filter in before VirtualDesktop, in SteamVR.
With the 1.25x for SteamVR being a Video resolution setting of at least 4800x2700 .
Could you:
a) set PiTool at 1.0 and SteamVR to 1.25 (125%) and record the recommended render target res for this setup,
b) set PiTool at 1.25 and SteamVR at 1.0 (100%) and again report the recommended render target res?
This is how I understand your description and your claim those two are equivalent. I believe they are not and the latter should provide better image because its recommended render target res is higher.
I never said SteamVR 125% was equivalent!
I did say I set SteamVR to 1.25x as many pixels as the native resolution when PiTool Render Quality was set to 1.0.
I also indicated that when the same number of pixels are given to Virtual Desktop, the resulting image is much sharper when the beyond native pixels are created by PiTool Render Quality setting, instead of SteamVR Video setting.
However, setting PiTool to 1.25 DOES cause the horizontal and vertical pixel counts to SteamVR to increase by 1.25x, if SteamVR is restarted without changing the Video resolution slider, meaning that SteamVR is probably getting 1.25x as many pixels in each dimension fed to it.
Which would overcome a blur filter in SteamVR that smears the final output by 1.5-2 px in each direction, which is exactly consistent with what would be put in place by someone aware of the Nyquist frequency/limit.
This was among, if not the first, experiment I performed to create my spreadsheets.
You can do this experiment yourself with any Pimax headset from the 5k+ up.
The thought has occurred before, that the used formats of writing: multiplier, next to percentage value, could serve well in themselves as shorthand for whether our supersampling amount is by dimensions, or by area, if only everybody was in on such a de-facto standard… :9
Total SR… In-App SuperSampling… SteamVR Vertical Pixels… PiTool Render Quality… Native Vertical Pixels…
SteamVR percentages change often, and I am sometimes not sure they are even internally consistent the same thing. When I changed a render quality setting in default.vrsettings or something, IIRC, 100% SteamVR Video resolution gave me the same pixel counts as 48% had before the change, or vice versa.
It was added as a concession to users who complained fairly loudly, when the blurvanced sampling scheme at first replaced the old one outright.
I doubt there is anything applications would need to support there; It should be strictly something affecting SteamVR’s own shaders, well after the application has already done all its work and handed it over, surely? (…and wouldn’t normally affect users of non SteamVR-native headsets, on account of Piserver, or equivalent for other makers, taking over most of the job that the setting would have affected).
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.