Yes and no, default 1.0 vive resolution is 1.4. Native resolution on vive and cv1 is 1200 but they default a 1600 ss
Increase pixel density - VIVE - improve text readability
- Thread starter ElectricZ
- Start date
Yes and no, default 1.0 vive resolution is 1.4. Native resolution on vive and cv1 is 1200 but they default a 1600 ss
perhaps renderTargetMultiplier is a factor applied on top of the default 1.4?
It's all going to be hand waving anyway, until FD come out and explain it for us with a one line changelog entry saying "Fix VR rendering"
Why are people still using the in game SS, even down sampling? The in game SS seems pretty broken to me so why use it at all?, e.g. SS: 0.65 and render target of 2.0 rather than just disable the in game SS and use, say, render target of 1.65 or so?
I'm using 1.5 at the moment and finding it pin sharp with no adverse affects - also decided to wear my contact lenses for extra sharpness
It's a performance balance thing. Running SteamVR SS at 2.0 and in game SS at 0.65 actually generates LESS pixels than straight up Native x 1.5 SteamVR SS. You've then got a easy performance lever with the in game SS option for when you need it.
The rendermultiplier can be set by the app - some other apps already make use of it, e.g. Virtual Desktop, Solus Project.
At the very least, it would be good if FD integrated this simple option as another slider in the graphics menu so we don't have to adjust the config file (which is used for the default if not overridden by the app)
At the very least, it would be good if FD integrated this simple option as another slider in the graphics menu so we don't have to adjust the config file (which is used for the default if not overridden by the app)
interesting, i noticed in the solus project this has a massive difference on quality using a vive. it would be nice if elite had this option if it is something that can be done in API rather than messing around in json files that affect all games.
Think the opposite order:
EliteDgr: "Hello, I am Cobra Engine, what size images do you want?"
OpenVR: "Hi Cobby! Please give me bitmaps that are 1080 by 1200, times 1.4, times RenderTargetMultiplier." Lets call the product of these multiplications: "RT", for short. (EDIT: I am sure it's a little more complicated than this; E.g, as some have pointed out, the application can pick multiplier on its own.)
EliteDgr: "Okidoki!" *proceeds to render left and right eye views that are RTx0.65 large, then upsamples them to RT, before passing them on to OpenVR -- if RTM is large enough, RTx0.65 will still be bigger than regular 1.0* - "Here you go, Oppi!"
OpenVR: "Thank you!" *proceeds to pluck each pixel from the RT bitmaps, and place it in its right place on the image that will go to the actual screens, along with those of its neighbours that will come to occupy the same pixel on the output image, the values of each weighted by how near the target pixel location they are.* This is not only a downsampling process, but will displace pixels to counter the physical distortion caused by the lenses that we view the game through; Near the centre, we stretch things out - hence the 1.4: Without those extra pixels, we would effectively have another upscaling here, instead of cramming in as much detail as the physical resolution can take; Out in the periphery, things squish together. A larger render target provides OpenVR better precision, which directly manifests in the accuracy of the output. This is (hopefully) done in a single step, whereas if we first downsample to a smaller render target, before giving it over to Open VR, we perform a downscale on top of a downscale, losing detail and softening the image twice, instead of just once.
It's like when you process a photo for web publishing; You'll keep it at full resolution, and in a non lossy file format, throughout all the steps of your working on on it, and only at the very last moment do you downsample it to the size it's going to take on the web page, and save it as a lossy JPEG image. (EDIT: Ehrm... Let's see... profanity filter...) "Sheet in: Sheet out", as they say... :7
Last edited:
SO this, maybe?
Vive single eye res is 1080 x 1200?
With the inbuilt 1.4 modifier that is 1512 x 1680?
The above chart shows 1512 x 1680 being the default, so I'm assuming that is with Steam config value unset (essentially 1.0 multiplier).
So if you set the value in the steam config to 1.4 (Resolution Scale column) you're rendering at 2116 x 2352?
Which would make x2 a heavyweight 3024 x 3360 render? (or 1966 x 2184 with ED set to 0.65 (though it's probably not that simple))
Though Reddit seems to think this :
So I dunno, they may be right I'm just not quite following Reddit's working out there.
Vive single eye res is 1080 x 1200?
With the inbuilt 1.4 modifier that is 1512 x 1680?
The above chart shows 1512 x 1680 being the default, so I'm assuming that is with Steam config value unset (essentially 1.0 multiplier).
So if you set the value in the steam config to 1.4 (Resolution Scale column) you're rendering at 2116 x 2352?
Which would make x2 a heavyweight 3024 x 3360 render? (or 1966 x 2184 with ED set to 0.65 (though it's probably not that simple))
Though Reddit seems to think this :
https://www.reddit.com/r/Vive/comments/4q8vzg/super_sampling_screenshot_steam_overlay_comparison/d4re4fz?st=iqbbr2x2&sh=9e2160dd said:
So I dunno, they may be right I'm just not quite following Reddit's working out there.
Last edited:
You may notice that the redditor's X values are twice yours, while the Y ones are the same. It's probably safe to assume they are counting the total, for both eyes. :7
Last edited:
Tried this @1.6 on vive with r930/fx8350 and elite ss 1.0. a bit juddery in stations but wow so very clear. Pretty amazing.
Quick question:
Is this only for the Vive? I have the DK2 and I don't see a "steamvr.vrsettings" file.
I do have steamvr installed.
Thanx
Is this only for the Vive? I have the DK2 and I don't see a "steamvr.vrsettings" file.
I do have steamvr installed.
Thanx
Does the DK2 not use the oculus runtime, not sure it launches steamvr.
I don't own a dk2 so I'm guessing here.
Ummm...honestly, I'm not sure how to answer that, here's why:
When I launch ED, Oculus Home (OH) does indeed start up and goes to the home screen. When the ED client opens, OH goes to a white screen with the usual safety warning that you have to agree to, then ED launches in the DK2.
However, if I launch steamvr, without launching ED, I get the same warning screen in the DK2, but then the DK2 display goes black, as if it's "waiting" for a VR game to launch. If I launch ED (or any other VR game) it starts right up, no problem; but at this point, I don't know what runtime the HMD is using...Oculus or steamvr? It seems as if steamvr takes over, but I'm not sure. If I close OH, steamvr closes down seconds later. So I'm leaning towards Oculus runtime being used here.
I've tried launching ED straight from the Steam client (which asks if you want to play ED in steamvr) to see if that would create the steamvr.vrsettings file, but it does not.
Not a biggie really, just wondering if I don't have that file because I'm not using the Vive or if I'm doing something wrong.
Thanx for your response.
Last edited:
From what I've seen that file is not created along with Steam VR.
To trigger its creation you have click the "VR" thing in top right of Steam to get the pop up, then click the popups menu and go to settings and changes some stuff.
steamvr.vrsettings is then created.
My file currently looks like this :
Code:
{
"audio": {
"offPlaybackDevice": "{0.0.0.00000000}.{014d76d9-021e-4ee9-a6d9-12ba01a245c6}",
"onPlaybackDevice": "{0.0.0.00000000}.{904425ba-a8f1-484a-8d0b-d65dd22dd719}",
"onRecordDevice": "{0.0.1.00000000}.{f77409d0-418e-43e1-859d-450cfbba477c}"
},
"camera": {
"enableCamera": true,
"enableCameraForCollisionBounds": false,
"enableCameraForRoomView": false,
"enableCameraInDashboard": false
},
"jsonid": "vrsettings",
"perfcheck": {
"heuristicActive": true,
"warnOnlyOnce": true
},
"steamvr": {
"allowReprojection": true,
"startMonitorFromAppLaunch": false,
"renderTargetMultiplier": 2.0
},
"version": "1"
}So changing any of those settings will trigger its creation.
Guessing this pop up isn't available for Oculus since the pop up does seem kinda Vive specific.
Maybe just try copy pasting the above?
Having a Vive and a Rift CV1 simulatenously connected, I notice that Elite seems to favour the Rift - I have to stop OVRService to get the game to target OpenVR/SteamVR.
The Oculus debug tool, that will allow you to increase the render target for your DK2, is part of Oculus' SDK, which can be downloaded at https://developer.oculus.com/downloads/
(EDIT: I.e; If you use a Rift, Elite will work with the Oculus
Last edited:
Sorry if this has been covered already, but could someone explain in simple terms the performance I'm seeing with supersampling on my GTX 1080?
I've got i5 4670 @ 3.4ghz, 16gb RAM, Windows 10 64bit, GTX 1080. I've got in-game supersampling down to 0.65 and I've got settings at High VR.
I've seen reports of other people bumping their Steam VR render setting up to 2 or 2.5, but when I do that I get either a) a juddery broken mess (games other than Elite), or b) constant grey-outs every few minutes (Elite).
I've had to dial it back to 1.5 to get a stable result, which is annoying because I see from the moments when 2.0 works that it looks a lot better than 1.5.
What is going on and how come my 1080 can't handle what lower spec cards seem to be capable of?
I've got i5 4670 @ 3.4ghz, 16gb RAM, Windows 10 64bit, GTX 1080. I've got in-game supersampling down to 0.65 and I've got settings at High VR.
I've seen reports of other people bumping their Steam VR render setting up to 2 or 2.5, but when I do that I get either a) a juddery broken mess (games other than Elite), or b) constant grey-outs every few minutes (Elite).
I've had to dial it back to 1.5 to get a stable result, which is annoying because I see from the moments when 2.0 works that it looks a lot better than 1.5.
What is going on and how come my 1080 can't handle what lower spec cards seem to be capable of?
Yeah. Kind of suprised it isn't stickyed at this point.