Fixed my Vive Elite fussiness.

I run Elite on an overclocked i7 6700 with an overclocked 980ti.

Elite for me on a Vive was, like many Vive users, very very fussy with text that's hard to read and overall everything was blurry. Nothing like my friends Rift.

There have been lots of guides using SteamVR supersampling etc and many have helped but didn't actually fix the problem but last night I managed to totally clear up the issue and the game is now very sharp, all text is easy to read and the difference is like night and day.

The settings I used were very simple.

My SteamVR config file has my SS set to 1.4
The game has SS set to 1.0
The game has HMD quality set to 1.0

That's it, that's all I did. I hope this helps for some of you because it totally cleared up the issue for me. I wish I could post some screen shots but of course you wouldn't actually see the effect.

It has totally fixed my fuzzy image issue. Not helped a little, totally fixed it. The game is now super clear and sharp in VR and it looks beautiful.
 
Do you get any color issues like color banding (seen around nabulas and halos at a distance)?
Cuz in my DK2 (and the CV1 I tried although it was only on one eye) it's disgusting on both eyes!
If you say there is no issue with color and color banding with your vive I think I will go ahead and order one!

In case you're not clear about what color banding looks like: https://upload.wikimedia.org/wikipedia/commons/9/9a/Colour_banding_example01.png look at the 8-bit gradient image, or,
https://15254b2dcaab7f5478ab-24461f...llacommunities.com/editor/1a/lq23qv7u1eer.jpg look at the image on left
 
Last edited:
I will definitely give your settings a go, almost sounds to good to be true.
Fingers are crossed, & will report back when I've got chance to fire the Vive up.
Probably will be a couple days as working all weekend.
 
Really? I thought the "HMD Quality" setting was supposed to *be* the same as the RenderTargetMultiplier you can set in the config, effectively overriding it... (It could of course also be /on top/ of that one, or something completely different altogether, but that was the general assumption...)

On a tangent, a programmer from Oculus recently made a statement about how using higher settings than 1.5, for the Oculus equivalent of RenderTargetMultiplier, can in many cases lead to /worse/ aliasing, in games that do not provide the driver stack with mipmaps for the rendered images ("Eye Textures"). This led to a discussion about why the relevant fragment shader relies on mipmaps in the first place, for textures that are typically used only once, and regenerated every frame, which seems a bit wasteful. -I wonder what the situation is with OpenVR/SteamVR, with regard to this.
 
On a tangent, a programmer from Oculus recently made a statement about how using higher settings than 1.5, for the Oculus equivalent of RenderTargetMultiplier, can in many cases lead to /worse/ aliasing, in games that do not provide the driver stack with mipmaps for the rendered images ("Eye Textures"). This led to a discussion about why the relevant fragment shader relies on mipmaps in the first place, for textures that are typically used only once, and regenerated every frame, which seems a bit wasteful. -I wonder what the situation is with OpenVR/SteamVR, with regard to this.

Yes - in many situations, once you start sampling a visible texture at more than its native resolution, the quality degrades. Sampling a 1024x1024 texture at 4096x4096 just softens the overall image - sure you get 16x the original's resolution, but it can be worse than using the original 1K texture. You can also get poor moire atrifacts where some parts of an original texture get sampled twice, and end up with an annoying linear-stripe or similar on the final render.
 
Hi


Thank you, really. Bought the Vive a few days ago and was very disappointed with how Elite was presented in VR. However, the OpenVR with SS = 1.4 made a significant difference (night and day kind of feeling). Additionally, I'm currently testing different HUD colors in EDProfiler.


Again, thank you / Fortran
 
Yes - in many situations, once you start sampling a visible texture at more than its native resolution, the quality degrades. Sampling a 1024x1024 texture at 4096x4096 just softens the overall image - sure you get 16x the original's resolution, but it can be worse than using the original 1K texture. You can also get poor moire atrifacts where some parts of an original texture get sampled twice, and end up with an annoying linear-stripe or similar on the final render.

Opposite case here, though. Here it's about taking samples from a fully detailed (not upscaled) 4k texture, for drawing to a 1k display, where the aliasing, and its resulting morie patterns, appear when picking samples at intervals, effectively skipping all the values in between (as you obviously know, for instance the classic example of picking positions on the bricks in a wall, but only sporadically hitting one of those thin mortar lines). This is usually dealt with by using mipmaps (explaining for the benefit of other readers), which are a succession of scaled-down (maybe one could say: "pre-averaged") copies of the full texture, and are switched in as the player moves away/to_a_more_oblique_angle from the textured object.

Apparently the shader that does the barrel distortion uses the same regular texture filtering as any other, and need the mipmaps at a certain point, when sample density becomes sparse, so because of the characteristics of the application, the question was raised why it doesn't, instead of relying on mipmaps, take and average more samples from the full texture, which would apparently let you take better advantage of cache, as well as bypass the mipmap generation step (expected to be performed by the application; If the driver did it, it would apparently not be able to just go ahead and do it on the textures as delivered, but have to make a copy first - costly in vmem and cycles, I was told), which is usually done under the provision that this is something you afford once in a while (for procedural textures (...and only when something changes in them) -- art assets have them ready-made, right in the image format, waiting on one's hard disk), and then reuse for many frames - not something to be thrown away after a single use, negating the basic reason why they are usually favoured over resampling higher density sampling at high quality in realtime.
 
Last edited:
I have used the below settings for a long time now:

Steamvr ss: 1.2
Ingame ss: 1.0
Hmd quality: 1.25

I find this setting super clear and gives good performance. I have no banding issues. The steamvr SS of 1.2 does a big difference.
 
Last edited:
I have used the below settings for a long time now:

Steamvr ss: 1.2
Ingame ss: 1.0
Hmd quality: 1.25

I find this setting super clear and gives good performance. I have no banding issues. The steamvr SS of 1.2 does a big difference.

How and where do you set Steam SS?
 
The banding around nebulae and sun's particularly.
IS NOT a VR issue I see these even on calibrated displays.
And is either from the assets or the very engine itself.

It's just very prominent in VR both due to the scale of the experience, and the fact that either my rift and Vive is out of calibration, butility really no more than your average monitor.
 
Last edited:
Hey sorry, forgot I made this thread. My settings have defiantly cleared up my sharpness issue, though I can't speak for others using my settings, hopefully you'll have the same luck. Glad it seems to have helped a couple of people.

The SteamVR SS setting was already at 1.4 (actually at the time it was something like 1.39999999999999 after an update which I believe others have had happen as well) and wasn't touched so I can't say if that is having any effect at all. But the settings I provided totally cleared up my fussyness issue.
 
Ok, deleted my pos as it's OT, I posted my answer about Rift and Banding colors in the appropriate thread which talk about this (sorry mods)
 
Last edited:
Back
Top Bottom