Vive Pre - I've got to be doing something wrong. Anyone else?

[spameroo]

Nope, there is more to it. The game renders perfectly fine in the Rift and both headsets offer the same resolution, FoV notwithstanding. There are issues here, that's all there is to it.

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.

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.

 

[blammotoken]

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?

 

[spameroo]

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.

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

 

[Ragnar Drake]

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.

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.

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.

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.

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.

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.

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.

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 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

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.

 

[Ragnar Drake]

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.

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.

 

[blammotoken]

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.

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.

This is certainly what I've observed. Just sitting in the hanger and observing the far wall you see terrible swimmy shimmer on any lines in the texture. At the same distance, lines in geometry (at the top of the wall, for example) are slightly jaggy (AA helps this) but don't look nearly as bad.

 

[spameroo]

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.

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.



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.

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.

Thanks for your reply and corrections. I think the explanations you give are essentially what I was trying to put into words, but I had a feeling as I was writing it that I was mangling the terminology horribly...

Anyway, to a few of your points:

I know changing the resolution in the graphics menu is only affecting the size of the mirror window and not the VR rendering. I guess from what you're saying, the window is going to be showing the same subset of the HMD pixels regardless of its size? Is there a way to figure out what the dimensions of that subset are, exactly? (Bearing in mind that I'm working with a DK2 and Oculus runtime, not SteamVR...) I'd like to be able to see what the image looks like at its native resolution on the TV screen.

What you described regarding texture resampling, mipmaps, etc., are what I was thinking of when I was talking about texture filtering and converting to screen space... I just had no clue what the proper language is to refer to those processes

I believe you're correct that raising the upper limit on the HMDPixelsPerDisplayPixel slider would address much of the problem, though I still want to know what the change was that caused it. The most likely explanation I've come up with is that FD simply lowered the maximum value of the multiplier, and just renormalized it to fit the 0-1 range. That would go a long way toward explaining why I was previously getting an incredibly clear picture and sharp text, using 1.5x supersampling and maxed slider, but prohibitively low frame rates at 2.0x SS; but am now getting a terrible picture at 2.0x SS with very little loss of framerate.

 

[hadri]

Hi all,

Just to chime in, having read the posts I'm having similar problems. I recently got my Vive running so haven't had time to play around with the settings but, played the setup wizard thing and a but of fantastic contraption with no issues. I fire up Elite and get TERRIBLE fps and AA in the main menu and when in ship - I haven't played beyond that. The FPS is my biggest concern. My machine destroys this game in 2D, and given other people don't seem to report FPS problems, I'm thinking this must be my end.

System specs:
5930k, 4.5ghz
x3 980s
32gig DDR4

The game is mirrored on a G-Sync monitor and runs butter smooth when I take off the headset and move it around in my hand (this is the weirdest part). Turning off G-Sync does nothing. I haven't tried lowering the settings tgf, but surely my system specs should tackle this!?

 

[ntsarb]

Hi all,

Just to chime in, having read the posts I'm having similar problems. I recently got my Vive running so haven't had time to play around with the settings but, played the setup wizard thing and a but of fantastic contraption with no issues. I fire up Elite and get TERRIBLE fps and AA in the main menu and when in ship - I haven't played beyond that. The FPS is my biggest concern. My machine destroys this game in 2D, and given other people don't seem to report FPS problems, I'm thinking this must be my end.

System specs:
5930k, 4.5ghz
x3 980s
32gig DDR4

The game is mirrored on a G-Sync monitor and runs butter smooth when I take off the headset and move it around in my hand (this is the weirdest part). Turning off G-Sync does nothing. I haven't tried lowering the settings tgf, but surely my system specs should tackle this!?

Just wondering if by any chance your low fps issue is due to headset tracking rather than an fps issue? Also, try with x2 980 sli. Do you still have this issue? Very strange...

 

[Kroy]

I don't have a source handy, but I think it was @shen on twitter who suggested if you're running multiple cards, you have to make sure that ALL your outputs come from the one card (monitors + vive) otherwise things are not optimum.

 

[Faster than Jesus [VR]]

I wasn't going to chip in with too much whining for reasons that will become apparent, but thought I'd add my voice nonetheless.

I picked my Vive up two weeks ago and have been having a fair bit of fun with it. My system is underspecced, albeit the I get 7.7 from the SteamVR tester:

Phenom II x6 @3.8Ghz/8GB RAM/R9 290X @1150Mhz

My plan is for a massive upgrade, but with all the new CPUs/GPUs due this year, I'm just waiting it out. I wasn't expecting miracles but I've got Elite kind of playable in a number of circumstances. Planetary landings are out, I tried it once and nearly suffered a cerebral aneurysm.

Elite does look crap no matter what I do, but settings make it tolerable:

• Low VR
• No AA
• Supersamping @1.0
• AMD superscaling (or whatever it's called) enabled - basically built in SS
• Getting the centre calibration correct
• Minor adjustments to headset position make a large difference (particularly with text)

AA can help, but only at those times where the machine can still maintain 90fps (mostly I'm at 45fps). The text is easily the biggest problem I've had, and with all of the above whilst maintaining 90fps, it's just about tolerable.

I still contend that there is an issue with supercruise. If anyone saw the AMD support thread regarding the Windows 10 AMD supercruise bug, a few people (myself included) felt there was an optimisation issue with supercruise.

 

[hadri]

Ah well I'm definitely running all outputs (including the vive) from the first card so thats no an issue. It MIGHT be a tracking issue, when I was stood up everything was fine, but maybe sitting down with Elite caused the lighthouses to lose the headset? The way I have my lighthouses set up atm (it was very quick last night, picking up on existing holes in the walls!) would mean I have my back to them. God I hope its that simple!

I don't think its SLI, I initially thought it was caused by the sli bridge no being fully seated (just rebuilt PC) so SLI wasn't even on with my first attempt.

I'll have a good bash tonight, but anything people can suggest that I can try would be most helpful

 

[Faster than Jesus [VR]]

Ah well I'm definitely running all outputs (including the vive) from the first card so thats no an issue. It MIGHT be a tracking issue, when I was stood up everything was fine, but maybe sitting down with Elite caused the lighthouses to lose the headset? The way I have my lighthouses set up atm (it was very quick last night, picking up on existing holes in the walls!) would mean I have my back to them. God I hope its that simple!

The SteamVR app shows if anything isn't tracking by flashing the corresponding icon. Maybe take the headset off but hold it where it would be if you were playing and see what the SteamVR dashboard does.

 

[hadri]

Ah yes you're right, it's not my lighthouse set ups then! Taking the headset off and moving it around, the monitor dashboard display is butter smooth. But looking through the head set its like 10fps! I shouldn't have to, but would disabling frame re-projection help? It's doing my head it that no one else is experiencing this!

 

[Faster than Jesus [VR]]

Does the headset icon and the lighthouse icons stay solid green whilst your doing that?

 

[Jonathan E]

I'd take it down to a single 980 (i.e. remove the others). Also, check that the 980 you are using is in a x16 PCI slot.

 

[hadri]

Does the headset icon and the lighthouse icons stay solid green whilst your doing that?

Good shout, will check tonight. I hope its that simple!

I'd take it down to a single 980 (i.e. remove the others). Also, check that the 980 you are using is in a x16 PCI slot.

I'm pretty sure sli was disengaged by accident and then reengaged with no effect but I will purposefully disable sli tonight to test. The primary card is definitely in the x16 slot!

Edit:
I doubt this is related, just throwing it out there. I used to run a triple surround setup @60hz, with v-sync. I initially had massive stutter issues until I unparked the CPU cores, this was in all games and back in win7. When I upgraded to win10, everything was fine. BUT when I did a complete wipe and fresh install directly to win10 some time later, the problem returned and I couldn't fix it. The only get around was to run without v-sync until I eventually went to a single g-sync monitor.

 

[Jonathan E]

Out of interest, does your mobo run the three cards x16/x8 x8 x8? or is the last on x4? I had loads of problems when I had an x4 in my last sli rig as it brought all the cards down to x4.

 

[hadri]

Out of interest, does your mobo run the three cards x16/x8 x8 x8? or is the last on x4? I had loads of problems when I had an x4 in my last sli rig as it brought all the cards down to x4.

That's exactly it, it's a Rampage V so in x3 SLI, it runs x16, x8, x8. Confirmed this in the BIOS yonks ago. Never had any issues with SLI in 2D

EDIT:

OK its defiantly SLI! 2 or 3 way, it doesn't matter. As soon as I run SLI the FPS is 45 regardless if I run re-projection or not.

Anyone else seeing issues with SLI and elite?

 

[CMDR Minion Blob]

Vive w/2-way 980Ti SLI

That's exactly it, it's a Rampage V so in x3 SLI, it runs x16, x8, x8. Confirmed this in the BIOS yonks ago. Never had any issues with SLI in 2D

EDIT:

OK its defiantly SLI! 2 or 3 way, it doesn't matter. As soon as I run SLI the FPS is 45 regardless if I run re-projection or not.

Anyone else seeing issues with SLI and elite?

I have a dual Asus Matrix 980Ti 6GB running on an Asus Maximus VIII Extreme Assembly motherboard with the latest drivers/BIOS attached to a Predator X34 GSync monitor.

Got the Vive on Friday, spent nearly a day fiddling with trying to make it work with ED, etc. My setup includes a Warthog HOTAS with TrackIR 5 Pro/Voice Attack. I also have an Xbox 360 controller configured for the SRV profile in my .binds file.

Plugging in the Vive and its two Wireless Controllers screwed everything up, including my .binds file automatically just by launching the ED VR app from SteamVR. Luckily I had a backup which I had manually restored.

Even with this souped up configuration I have--the whole system is less than 2 months old--ED VR looks like crap in Vive, while running it on the X34 is buttery smooth at 100Hz in Ultra setting.

It's very disappointing to see a retail product released and advertised as Vive compatible performs so poorly. Shame on FD; it's their advertised retail product "compatible" with the Vive. We are not talking about some lack of optimization; the product is completely unwatchable and unplayable with all the shimmering, binning and 15 fps-level "performance." They should immediately withdraw the Vive-specific version from Steam until these issues are remedied and the software performs to the extent the current Vive hardware visuals allow it. If it doesn't not support SLI configurations, it should be noted accordingly instead of customers finding it out thru trial and error wasting countless hours of their time.

SLI or not, ED VR at the moment runs completely unacceptable and far below to what quality could be expected from a single 980Ti even without any OC. I do say this, however; if I keep my head completely still, ED VR will be THE WAY the ED Universe is to be experienced even when comparing it to the 34" curved X34. The thru 3D virtual world is just an awesome way to immerse anyone in the cockpit of their ship. It's completely stunning, or at least it would be if they'd get rid of the artifacts ruining the experience at the moment.

My last attempt will be replacing the HDMI cable with a DP-to-MiniDP cable and plugging it into the same 980Ti as the X34 uses. HTC claims the miniDP port is supported "if the computer doesn't have an HDMI port." Will see if it's any better or not.

Starting up the Steam VR app--which activates the Vive components--immediately drops the X34 out of GSync to 60Hz. Stopping Steam VR immediately resumes GSync.

I have called HTC Customer Support and requested an RMA. If this doesn't work I have no use for this product; the available software is essentially a collection of demos. Interesting and it'll be awesome a few years from now...just not..yet.

Also, in general the resolution of the Vive is very crude. The individual pixels are quite noticeable and annoying no matter what app is being used. Oculus seems to be a bit better quality if the few YouTube reviews are correct; perhaps ED will run better on that platform also. My preorder was delayed until the end of June, so if the Vive won't work out I'll try that next.