Just a heads up, I guess I was too impressed earlier by the clarity and the FOV, so not minding the low FPS, but after some playing I put SteamVR SS override to 100%. Which means, right now, I have everything set to 100% everywhere. Anyway the setup I use allows using SteamVR override as the only point of change with enough room on either side of the SS scale.
After some (quite prolonged) play of ED, I wonder if anyone tried to contact FDev about Pimax and its peculiar geometry and if it could be possible to implement native support into ED, without using āparallel projectionā thingy, because it both degrades the performance and the quality of the image.
I am not sure how exactly the ED engine works, if it uses any specific VR features of Nvidia (e.g. multiview rendering) and if it could bring any additional bonus. I full support for non-parallel multiview rendering on RTX cards could improve the perf significantly, but I am curious if anything could be done also for the old GTX cards.
Does anyone from here who follows ED forums know if this was discussed? I see the audience of ED commanders having great potential for buying Pimaxes in the future.
This may just be cynicism speaking, but I quite doubt FDev even uses SteamVRās hidden area mask, utilisation of which, alone, could save quite a but of shader workā¦
I have, for one, a few times brought up the matter of canted screens on the Elite Dangerous forums (should be an easy fix, I imagine - just update to recent OpenVR standards and fully use its projection matrices, rotating the cameras according to them), as well as other things, such as lens-matched shader masks, that would work on GTX cards (EDIT: ā¦as well as other brands, without messing with proprietary APIs), although maybe not nearly as efficiently as VRS; But I have never directly addressed Frontier.
There wasnāt a separate topic about it and i didnāt came across such discussions.
However, we guess that developers donāt read/care about the sub forum anyway really. So your job would be to raise a bug report via the online forumā¦
Once that is done you could/should beat the drum here and in the other forums pimax threads so other users can chime inā¦
(you might get redirected to here, but my 1st bet would be on bug reporting)
Does ED Profiler tone maps work again?
I donāt think so. It wouldnāt surprise me if tone-map functionality was permanently dropped from ED, with the switch to the new lighting model.
Part of this old ātone mapā is in my pastebin file, plus couple of my findingsā¦
I modified it a bit since my first post.
e.g in IBL section is saturation 0.17 , if you like more you can change it to 0.19 or 0.21 but be carefull becouse some stars can burn your eyes:)
Did you update the pastebin with your new changes or is it the same one?
I have been launching end exiting Elite a whole bunch of times this evening, and thought Iād share a little observation:
Remember how one user observed, in another thread, that resolution seems to go down, when upping oneās PiTool FOV setting, sharing a table of render targets he had noted down, for different FOV and Allow Parallel Projections settings?
It seems that there may indeed be a resolution cap being applied, somewhere along the line, in some mannerā¦
So Iāve been experimenting a bit with Pimax quality, SteamVR supersampling, and Eliteās HMD Quality, looking only at perceived visual quality, without paying much attention to framerate or such (other than in the sense that things crawl to a stop, when pushing the envelope, making the UI reeeeally syrup-y), and it seems to me that regardless of what the numbers in the SteamVR settings window may say (and they go up unrestricted, as one would expect), the actual render target bitmap size Elite renders, with its own two options at 1.0, does not go above 4k wide.
Given SteamVR supersampling levels that results in up to a 4096 pixel wide (ā¦and probably tall too, had that been the larger value) bitmap, SteamVR supersampling appears to ātakeā, and the output image is that much sharper for it. Above this, however, no visual improvement can be discerned.
BUTā¦ increasing HMD Quality in-game does produce the expected supersampling.
I am inclined to speculate that it could be Elite, that does not accept being asked for a larger bitmap than 4k, and adjusts any such request, although it is perfectly happy to subsequently go beyond that point, on its own terms.
Whilst the RenderTarget size seems to be limited at some point: Once the oversized bitmap has been rendered, it seems to make it perfectly fine, all the way back from the game, through SteamVR, to Pimaxās compositor, which does seem to fully utilise it when producing the final native resolution output.
This could possibly also help explaining why so many seem to be under the misapprehension that the point of diminishing returns from supersampling is way lower than it actually isā¦ (EDIT: Pure visual quality returns, that is: When one make a quality-to-performance_cost judgement, one may see things differently :7)
I donāt think this is something we can blame on ED. Iām playing it at a resolution of 7680x4320 (using nVidiaās āDynamic Super Resolutionā option).
Therefore, I think the 4K limit is somewhere in the VR rendering code (in ValveVR or PiTool). Iāve also seen reports of this 4K res limit in other games.
Okā¦ Next suspect down the line would be the bit of SteamVR that issues its render target size request to the game, thenā¦ :7
(The UI really, really bogs down and becomes unresponsive at low framerates, by the way (be warned, should you decide to try causing them): Input and animation seems tied to UI frame render count, rather than time. Scaleform, is it? To think weāre still prisoners to Flash, after all these yearsā¦ :P)
thatās sounds bad for pimax 8k-x users
no yet , becouse i need to do more test in bubble , right know exploring SAG A area
Yeah. I hadnāt actually thought about that. This limit needs to be raised, for future high-res headsets to be worthwhile.
I did some tests today, simply by starting ED waiting until it gets into the game menu (hangar with the Scarab and the Viper) and checked the frame times for the GPU and the CPU reported by āAdvanced Frame Timingā in SteamVR:
SVR SS | SVR ED SS | ED HMD | ED SSAA | X res | Y res | CPU (ms) | GPU (ms)
100% | 100% | 1,0000 | 1,0000 | 3852 | 3291 | 4 | 16
120% | 100% | 1,0000 | 1,0000 | 4220 | 3605 | 4 | 18
200% | 100% | 1,0000 | 1,0000 | 5448 | 4654 | 4 | 18
112% | 100% | 1,0000 | 1,0000 | 4077 | 3483 | 4 | 18
88% | 100% | 1,0000 | 1,0000 | 3613 | 3122 | 4 | 15
100% | 100% | 1,2000 | 1,0000 | 3852 | 3291 | 4 | 20
100% | 100% | 1,0000 | 1,2000 | 3852 | 3291 | 4 | 20
100% | 100% | 1,0955 | 1,0955 | 3852 | 3291 | 4 | 20
SVR SS - SteamVR global override
SVR ED SS - application override in SteamVR for ED (this a bit tricky to set as ED only shows up in the menu when it is running)
ED HMD - ED in game setting HMDRenderTargetMultiplier
in Custom.fxcfg
file
ED SSAA - ED in game setting SSAAMultiplier
in Custom.fxcfg
file
X res - reported X resolution in SteamVR (one eye)
Y res - reported Y resolution in SteamVR (one eye)
CPU (ms) - CPU frame time in milliseconds
GPU (ms) - GPU frame time in milliseconds
First row gives nominal readings (everything at 100%, no resampling).
Rows 2-4 confirm @jojon observation above. As soon as X size exceeds 4096 (or 4K?) the performance impact remains the same.
Row 5 shows that the perf. scales down correctly.
Rows 6-8 show that setting in-game HMD or SSAA sampling has performance hit which is not possible to achieve by SteamVR settings (even when I tried to change ED local SteamVR override).
On the other hand it looks like the in-game HMD and SSAA are simply factored as they have the same performance hit when used both.
The exact meaning of the HMD and/or SSAA factors however might not be linear but quadratic as the results for HMD=1,2 (or SSAA=1,2) do not correspond to SVR SS=120% (which is linear).
The conclusion might be that when rendering into the target < 4K SteamVR is sufficient to control the supersampling, while when one needs higher supersampling quality, one needs to tweak also in-game settings. I did not compare the visual quality so there might be some differences in VQ as well.
EDIT: One thought on HMDRenderTargetMultiplier
vs SSAAMultiplier
. I would expect that the latter simply sets SSAA internally, and at the end of the rendering rescales the final frame to the target rendering resolution, it means it applies equally in VR and non-VR.
For HMDRenderTargetMultiplier
I would assume that the game creates larger render frame and does not rescale it to the target render resolution before passing it onto the compositor as it seems that the target rendering resolution is actually recommended resolution and the app may render into any res it may choose, from the point of OpenVR API.
How this might work on Pimax however is unknown to me.
The scene I used for the benchmark:
Like your comparison - please paste your gfx card model
I also noticed that fpsVR app consume some resources like 3~6 fps per game. When you turn off fps app you will achieve better score in game built fps counter. Noticed that in ED and IL 2. So I suggest turn off fpsVr app during long game play sessionā¦
EDIT oh,sorry this is Steam Advanced Timingā¦
I did not use fpsVR (it was not running at all), but the built-in profiling in SteamVR, I assume it might have an impact on the performance too, but for the purpose of this exercise was not important.
My PC config is:
GTX 1080 Ti (ASUS ROG Strix - not overclocked)
Ryzen 5 2600X (also running stock)
16GB RAM (DDR4 3200 CL14)
Samsung EVO 970 1TB
What was your nvidia control panel set to ā¦?
1ā¦ āLet the 3D application decideā
2ā¦ āUse the advanced 3D image settingsā
3ā¦ āUse my preferences emphasizingā
Nice methodical testing and documenting, there.
ā¦as for the perceptual difference between using the already-downsampled output from the gameās internal SSAA, and delivering the full larger rendered framebuffer to Pimaxās software, via the combined influence of PiTool quality setting, SteamVR supersamplig, and game HMDRenderTargetMultiplier, it is my impression that this results in the exact same as I felt with Vive and Rift: You get a much sharper and ārealā, āsolidā, āsteadyā, āresponsiveā image out of the latter, even if it can exhibit some aliasing (which in itself is not entirely detrimental, since it allows you to perceive more resolution than what the displays have enough pixels to spatially reproduce, from the brainās sampling temporally), whereas the āprebakedā output of the former feels more like an improved āpictureā in front of you, than a better resolved āworldā, so to speakā¦ :7
(EDIT: Iād go so far as to say that the same thing that we get there, by carrying the full resolution all the way to the final image processing step (the barrel distortion), we have more than likely already benefitted from when the frame was rendered, where we got more accurate texture information from higher level mipmaps being brought in, as opposed to using the smaller ones, whose āpre-antialiasingā is essentially baked down āflatā, without projection in mindā¦ :7)
āUse the advanced 3D image settingsā, but the only thing I changed from the default settings was āTexture filtering - Qualityā to āHigh qualityā.