I've just created a Wiki page where I've tried to collect current hypotheses and evidence for or against, see also the related Reddit discussion. I'd welcome contributions, and hope it helps get to the bottom of this issue.
I've just created a Wiki page where I've tried to collect current hypotheses and evidence for or against, see also the related Reddit discussion. I'd welcome contributions, and hope it helps get to the bottom of this issue.
/u/CrossVR found an interesting result, the game is rendering the UI text to a rather large texture but then downsampling it with a bilinear texture lookup without additional mipmaps, so (if I'm interpreting it right), this can end up losing information. Fixing this should make it possible to get approximately the text quality of 2x supersampling without paying the huge performance cost for that.Originally Posted by kwx(Source)
More here: https://www.reddit.com/r/Vive/commen...search/d2avh3q
My interpretation:Conclusion: I don't have time to go more in-depth, but I conclude that the text is indeed more blurry than it should be due to a texture filtering issue.
It is likely caused by the fact that they forgot to generate mipmaps for the text, even though they set the texture filter to one that expects mipmaps. Without mipmaps the text won't scale down properly and you get blurry text as a result.
Interesting. According to MSDN docs:
D3D11_FILTER_MIN_MAG_LINEAR_MIP_POINT Use linear interpolation for minification and magnification; use point sampling for mip-level sampling.
If I'm interpreting it right, this means that it always uses a single mipmap instead of interpolating between two mipmaps. In this case since there is only one level, it'll always use that as the only available mipmap. Then, from this mipmap, it'll pick the four samples closest to the pixel center and make a weighed average.
This doesn't work well if the onscreen rendered size is significantly smaller than the original texture size since some parts of the source image may end up being ignored completely. I think that matches the effect visible in http://i.imgur.com/vKIxRUZ.png . Look at the horizontal part of the "L" in "LANDING GEAR" or the first "S" in "MASS LOCKED", you can see that some parts of the image seem to be disappearing instead of being averaged among close pixels.
Crude ASCII graphics:
++++++++++++++++++
++12++12++12++12++
++34++34++34++34++
++++++++++++++++++
++12++12++12++12++
++34++34++34++34++
++++++++++++++++++
Each "+" is a pixel in the source image, and the "1234" points are the ones being sampled and linear filtered for output pixels. Note that there are many "+" pixels that don't contribute at all to the output image, so that any information there gets lost.
The best way to fix this would be to either add mipmaps to ensure that it can properly downsample without losing information, or to dynamically adjust the size of the texture region used for drawing text to roughly match the pixel size after rendering.
Does that sound about right?
As far as I can tell this is all part of Elite: Dangerous's pipeline, so it ends when it hands off a rendered texture to the compositor. I'm still a bit suspicious about how the compositor maps the rendered texture in its distortion filter to get onscreen subpixels, but that would be a separate issue.
This reminds me - I saw an undocumented --nodistort flag for vrcompositor.exe. Can someone try if it's possible to add that for launching it as part of SteamVR to see if that makes a difference in sharpness? (I can't access my Vive just now.) Not sure if it works at all, or if doing so would keep a 1:1 mapping in the image center or if it'll get the scale completely wrong.
Many thanks for doing the investigation!
Cheers kwx. Nice precis of the issues there. Repped.Originally Posted by kwx
I'm sure the happy little oompa loompa FDevs are busily working on a solution. This has to be a priority for them to fix. Just think of the word of mouth advertising potential. If we can all bring our friends over and show them a rotating orbital in hi-def on the Vive, copies of the game will sell like hot cakes.
My Vive arrives in May and I'm confident they'll find a resolution.
AMD FX-8370 4.0GHz / 32 GB Ram / Titan X Pascal / ASUS Crosshair V Formula-Z ROG / HTC Vive / Steam VR Rating: 20937Independent Trader - Curious Explorer - The least talented smuggler in the Galaxy.
"Please stop trying to change the game I love into something you might like." - Any grind, is in your mind.CMDR Shadragon / CMDR Drain Bamaged / CMDR CuteLilBunny
I'm hoping by the time my Vive ships (later this month) the issue will be fixed!
HTC Vive, Thrustmaster Warthog HOTAS, CH Products rudder pedals, AMD R9 290 OC, 7.1 audio, LG 27MU67-B UHD, Win 10 Pro 64bit, VoiceAttack, 200/10 MBit/s internet
There may be a fairly easy way to improve the aliasing issue with minimal effort. TL;DR: change the HMD image quality slider to allow more than 100% of the recommended render target size.
The currently available supersampling option has two problems. The smallest supported increase is 1.5x, and that is infeasible for all except the fastest GPUs since it's a 2.25x increase in pixels rendered.
The more significant issue is that supersampling happens on the undistorted image before it gets handed off to the compositor, so it gets downsampled first to the 1512x1680 grid, and then resampled again in the distortion step when scaling to screen pixels. That adds extra aliasing, so the image doesn't improve as much as it should.
Assuming that SteamVR supports input textures larger than the recommended size, increasing that size should solve both problems. The game could render at 1.25x size for a 1.56x increase in pixel count, and submit a 1890x2100 texture per eye. Then the distortion step has some extra pixels to work with when doing its resampling scaling.
As an added bonus, I think this would also reduce the UI texture undersampling issue found by /u/CrossVR since it would use more rendered pixels than the default scaling with 1.0x supersampling.
Yes, this will only work for people with faster GPUs, but the added cost isn't as high as 1.5x supersampling and I think the result will look better. And if I understand things right, this may be a very simple change for the game, and it seems low risk since the code change has no effect at all as long as people keep the slider at its default setting.
What do you think? FDev, does this seem feasible, and is there any chance of sneaking this into the upcoming 2.1 beta?
Edit: this assumes that the compositor API supports this and can do reasonable quality downsampling in the distortion correction step. If not, it would need some added support from SteamVR, analogous to the current high quality overlay.
Avtually, its not as bad as I'd initially thought. I had some issues with other vive games this morning, and went round a bit of a loop updating drivers, windows, drivers again... I captured the screen feed, and I'm uploading it now. I'll also do a capture with just a single eye, cropped to roughly the main forward view. Its playable - I even had a bit of combat in my first clip. Settings are mostly medium, didnt try to tune them in the slightest...
Video will be here once its uploaded and processed. I think its OK, close up and a comparison using Robot Repair queued up too.
https://www.youtube.com/watch?v=yjAku4ZVdr0
https://www.youtube.com/watch?v=iNeudLZ9xAA Cropped view
https://www.youtube.com/watch?v=pZ28KNy3wQU Robot Repair
The frame rate in Elite appears to be about 25fps, which I don't really believe, it doesn't feel bad (and I re-iterate, I have done zero optimisation here, and no overclocking - just water cooling of the graphics card)
Further thoughts on the rendering/aliasing - its only the centre ~20 degrees, some hundreds of pixels, where precise rendering is going to be effective - the peripheral region will be blurred a bit by the lenses. Presumably the game code or drivers can be tuned (given time) to give a render effort gradient (and this will be relevant to all HMD to some extent). Savings are big, a 1/3 grid translates to 8:1 pixel ratio.
Just played ED Arena after todays update.Looks amazing. Smooth frame rate ,no blurring or distortion.It looks so good!!!
Interesting, I don't recall seeing anything related to rendering in the patch notes, and Frontier tend to be rather conservative with minor point patches. I'll take a look when I get a chance. You're sure that it definitely looks better than earlier? FWIW, I haven't had any issues with framerate or distortion, just aliasing/jagginess combined with a bit of added blur from pixel remapping.Originally Posted by Calv45
I've just played ED with the latest patch and I see no difference in the VIVE. All known issues are present, no noticeable improvement.Originally Posted by Calv45
I got my vive last week. Didn't go straight in to E: D, had a wee shot last week and it wasn't good. Checked it out in more detail tonight. Looks just the same to me. It's a shame it looks as bad on the Vive as it does tonight. I play Dwarf Fortress, I don't demand AAA graphics are not my thing, but they HAVE to be legible and fit for purpose. Text on the vive isn't brilliant on any game or application, but I manage to use virtual desktop and write emails and word documents. I've read around the various E: D and Vive issues reported on /r/elitedangerous and /r/vive and on the forums here, which suggests this game may never be brilliant, but it could at least be optimised for Vive better so it's playable. At the moment it's subpar. I definitely wouldn't demo it to anyone.Originally Posted by kwx
It was amazing flying through asteroid fields, and enjoying head tracking in combat after all the months of playing without such finery, but as it stands, I can't see myself making more effort to play E: D than just to check in to see if things have changed.
I'll hopefully get shot on a Rift sometime in the future to compare. Meanwhile, you'll find me enjoying roomscale titles elsewhere.
I'm fairly certain that these issues you guys are having with the Vive are the same ones that caused the huge drop in image clarity with the DK2 once the ED 2.0.7 patch was released.Originally Posted by Heavenly-Hammer
My initial guess was that FD had changed the underlying value that the HMD Quality slider modifies. Within the Custom.fxcfg settings file, maxing the slider (all the way to the right) corresponds to the following line:
<HMDPixelsPerDisplayPixel>1.000000</HMDPixelsPerDisplayPixel>
In other words, I believe the slider determines the resolution of the image that is sent to the VR driver. At max, the output of the rendering pipeline is intended to match the HMD's native resolution; lowering the slider means the frame will be undersampled (relative to the HMD).
I suspect that prior to 2.0.7, the variable modified by HMDPixelsPerDisplayPixel was hard coded to the resolution of the DK2, and that 2.0.7 changed that to the resolution of the CV1. I don't know if that's actually the case, however, because if so the problem should be that the pixels in my DK2's display would be larger than the pixels in the rendered frame, requiring downsampling. In reality, as far as I have been able to determine, the pixels that are being rendered are much larger than the DK2 pixels. This is most evident when I look at the mirrored window on my monitor, which is actually a 55" 1080p TV: if I set the resolution to 1920x1080 in Elite, it becomes glaringly apparent that every rendered pixel is being upscaled to be made up of several smaller display pixels.
I don't know exactly what FD changed to cause this, but if Vive users who previously used DK2 are experiencing the same drop in clarity that I've seen between DK2 several months ago and DK2 post-2.0.7/1.3, and if CV1 users are NOT, there must be some change that was made by FD that was hard coded to assume a CV1 display resolution.
Guys after a lot of experimentation, I think this is completely a texture filtering issue and nothing to do with render resolution or edge aliasing. I know the wiki already made some assertions along these lines but I'll go ahead and waffle a bit anyway.
Super-sampling and/or AA help the edges of polys - panels on ship, edges of surfaces, etc. but doesn't do much to help the scaling of textures. In the cutter one can see a marked difference going from AA off to AA on when looking at the edges of the dark panels in the cockpit, for example, but no benefit looking at the "warning" signs on panels or any of the text in the UI.
I think the reason that distant stuff looks bad and cockpit stuff looks pretty great is because the distant stuff is using the lower LOD models, in which the textures do more "work" when it comes to representing details. That is, when you get close to a wall in the station, the pipes, panels etc are actually modeled and so they look fine (at least as good as any other Vive game), but as you get further from that wall it is swapped out for a flat quad with all the details represented by texture only. The textures aren't filtering properly so we see that "shimmer" effect.
Text is always a texture, so it always looks a bit dodgy, and especially so at distance.
Does that sound plausible to anyone else?
It seems plausible that could be contributing to the problem, but I'm fairly certain supersampling does affect textures also (you're right about normal AA, though). I believe the idea with SS is that the frame is rendered for the higher resolution at every step along the pipeline, until the final image is downsampled to the display resolution at the very end. As far as I know, enabling supersampling should affect every pixel in the frame similarly.Originally Posted by blammotoken
I can't decide whether I think your idea explains everything... Bear with me, I'm kind of thinking "out loud" here. The first game in which I messed around with applying SS was Skyrim, and I ended up going back to regular MSAA. The reason was that I started noticing that supersampling was smoothing out the textures to the point where I was losing a lot of the fine detail of the dozens and dozens of high-resolution, user-made texture packs I had installed. In hindsight, I bet the reason for this was that supersampling caused the textures, which were already probably 5 times the screen resolution, to be rendered with such fine details that rescaling the frame overall smoothed everything too much. Whereas, when I was just using MSAA, my GPU driver was using the usual AF and texture filtering techniques that are specifically designed to map texture pixels to display pixels.
I guess, then, that if for some reason the textures in ED were being filtered incorrectly, and therefore not being properly represented in screen space, all that supersampling would do is rescale a blocky image into a smaller, slightly smoother blocky image. That could possibly fit what I've experienced... I will look at some of the screenshots I've taken from the mirror window at 1920x1080 and see if your theory fits the observed evidence
No, that's not it. See the Wiki entry, it's sending a 1512x1680 per eye texture to the compositor which matches what other Vive apps do. However, the OpenVR API docs for GetRecommendedRenderTargetSize say that this is the minimum recommended size, hence my recommendation in comment #155 above that it would be worth a try to allow a larger slider range so that people can select values greater than 1.0.Originally Posted by spameroo
The resolution set in Elite Dangerous graphics options is just the size of the mirror image shown on the desktop, it doesn't affect the rendering in the headset at all. The reason it looks blocky is that it's a magnified view of the center of the headset view, it doesn't get rendered separately. For comparison, you can turn on mirroring of the raw eye view in SteamVR, you'll see that the round headset view has a far larger field of view than the rectangular view window.
Yes, that's accurate. Most (see below) antialiasing methods only improve geometry edges, they don't do anything to make textures look better. Texture sampling has its own antialiasing methods based on interpolation and mipmapping, but /u/CrossVR confirmed that there are no mipmaps for the UI textures. Since they get rendered in far fewer pixels in VR than onscreen, the lack of a mipmap means that they get undersampled, leading to severe aliasing issues. I've tried to illustrate that in the ASCII art in comment #152 above.Originally Posted by blammotoken
Yes, supersampling is an antialiasing method that does improve texture details if they are aliased, though this shouldn't normally be necessary if they are properly sampled with mipmaps. I think that the fact that supersampling does improve text quality noticeably confirms that there's something wrong with texture sampling.Originally Posted by spameroo
There's an additional problem here though. It's not "downsampled to the display resolution at the very end". It's downsampled to the minimum recommended 1512x1680 render texture size, then that texture gets passed on to the compositor which distorts it to fit in the 1080x1200 half screen size. This resamples it to a different grid - it's roughly 1:1 scale near the center, but pixels boundaries aren't at the same place, so this introduces additional blur as a single pre-antialiased pixel gets spread out among 4+ pixels it overlaps.
Supersampling would work much better if it would keep the higher resolution all the way until the final step, and I'm pretty sure that this is what would happen when setting HMDPixelsPerDisplayPixel to a value greater than 1.0 while leaving Elite's supersampling setting at 1.0. This assumes that SteamVR supports proper downsampling for large input textures, but I'm fairly confident that it does. If not that should be a fairly easy fix.
I think a good hint is that some detail from letters just seems to go missing even though they are roughly pixel sized. If properly sampled, the orange letter lines should get spread among neighboring pixels if it overlaps them, but that doesn't seem to be happening consistently.Originally Posted by spamerooI guess, then, that if for some reason the textures in ED were being filtered incorrectly, and therefore not being properly represented in screen space, all that supersampling would do is rescale a blocky image into a smaller, slightly smoother blocky image. That could possibly fit what I've experienced... I will look at some of the screenshots I've taken from the mirror window at 1920x1080 and see if your theory fits the observed evidence
If you want to experiment, try varying the distance from the displayed text panel. If the "undersampled texture" theory is right, text quality should degrade more rapidly than expected when moving further away, and improve more than expected when getting closer.Originally Posted by spamerooI will look at some of the screenshots I've taken from the mirror window at 1920x1080 and see if your theory fits the observed evidence
If I remember right, the lines drawn on UI panels seem to have gaps instead of showing antialiased stairsteps when tilted. Does a thick line at large distance look noticeably worse than a thin line at close distance? Do the stairsteps degrade more? Having a line develop large gaps or disappear at bigger distances would be pretty conclusive evidence.
