There has been one question that has been bugging me since the introduction of the SteamVR supersampling setting: if the final render resolution is a product of all supersampling settings (in-game x SteamVR x whatever else), then does it really matter how that product is arrived at?
This is the equivalent of certain people doing some crazy shit in Elite Dangerous, like setting SteamVR supersampling to 60% while increasing the in-game HMD quality to 1.5 and then claiming they have found the best graphical settings when in fact they just set a net supersamping of 90%.
Translated to the Pimax world, does it really matter if I set 0.75 in PiTool or SteamVR if the resulting resolution is the same? To my eyes, the results look identical.
Resolution = Pitool x SteamVR x In-Game
As an example:
Pitool (1.5) x SteamVR (60%) x in-game (1.2) = 108%
This should be the equivalent of leaving everything at 100%, and setting the SteamVR app profile to 108% and be done with it, shouldn’t it? No more requesting Pimax to introduce per-app settings in Pitool.
@SweViver - any thoughts on this? I assume you did a ton of testing with these settings.
This is a very valid question. There are too many variables for us to fiddle with in order to ge to the the final resultion.
If you want a dose of brain overload go read doc ok paper on the display resolution problem, noticeably the extreme sampling needed at the edges of the display:
I really wish they would explain the PiTool’s setting. It’s annoying to have a setting in between the headset and SteamVR as well. It adds a 2nd variable to play with. I mainly leave PiTool at 1.0 and tweak SteamVR. Rfactor2 at 70%, RaceRoom at 80%, iRacing dx file at 100 pixel density. That’s the sweet spot I found currently… (previously the steamVR SS was at 100% on all my games but something changed somewhere in pitool or steam recently)
Would it then not be feasable (or even very neccessary) to introduce a kind of foveated rendering for applications that need parallel projection (PP) on?
Afaik PP does simulate the rotated panels by Rendering even wider resolution and then shrinking (dismissing) part of the rendered image) again.
So if pimax could add foveated rendering (e.g. half resolution in the outer areas - at least horizontally) this could give an very welcomed performance boost.
Honestly, most of the games i play in small fov. And to look to the sides in normal or especially large is mostly blur and/or distorted anyways. Why not make an option-slider in pitools to blur the outer edges for performance?
I’m afraid it is the games that need to do that - Pimax has no influence on how they render their viewplanes; Their VR runtime just asks the games for a certain bitmap size and to please use its provided frusta – all fullscreen.
Since Pimax’s runtime is the alpha and omega, setting the base bitmap size, and receiving and finalising […for the HMD] the output from both the games and other APIs that may sit in between (such as SteamVR), I’d be inclined to do any and all bitmap size modifications there, so that the full rendered bitmap is to a high likelyhood available to its distortion pass (…of which any downsampling of extra rendered detail should be an inherent function).
I suspect that pararrel projection block steamvr ss or not?
Has anyone know about this, but not sure why I can set 500% sampling by fpsvr in Battlezone, but image look be same, but when I test on “The Rose and I”, it can make image look smoother.
Or SteamVR SS will lock some limit although we set the highest value if our computer can’t run it?
Yeah fair. I was kinda running blind with no help and testing stuff out. My question would be which leads to the best performance. Because I firmly believe Steam VR vs Pimax PT vs in-game gives different performance. I have no evidence, but my gut tells me this
Yep! I am hoping OpenXR will in include standards for this. :7
Some games ignore it - notably anything that runs on Unreal Engine 4 (Maybe this has changed in newer builds of the engine - I don’t know).
I don’t know where they get the render target size they use, given this: Maybe they hardcode it, maybe they can query SteamVR for the base render target and multiplier separately, but for some reason, somehow they do it.
Wow, I didn’t see your original post so far. Great work!
So it seems Pitool uses a quadratic scale (window height), while SteamVR is linear (total rendered pixel count). Which kind of make sense, Valve did that change a while ago to reflect total pixel count as opposed to one side of the render window.
No there’s def something up. It’s not a smooth exchange. .75 pitool 125% steamvr doesn’t look the same visa versa. The res have a different “flavor”.
Although I think we really need an official response if there is an even exchange and formula.
I’m very surprised given the performance requirements that controllers and lighthouses and leap motion took precedence over eye tracking and a foveated rendering solution. Especially since they use a custom runtime, which I assume they do so they can implement eye tracking and foveated rendering without having to wait for steamvr to casually release their foveated rendering whenever they feel like, most likely later than pimax will.