The "resolution" settings is supersampling (...or *sub*sampling, if using less than 100% values): It lets you render larger pictures, so that you get more rendered pixels for each pixel on the screens of the HMD - A screen pixel gets something like the average values of all rendered pixels that end up covering its area, after they have been moved to counter-effect the optical distortion caused by the HMD lenses, as well as scaled to the size (in pixels) of the screens.
Supersampling improves the final image, up to a point; When you go over twice both width and height, the downsampler that scales the big rendered frame down to the size of the screens may, in order to save work, start to ignore pixels, instead of including every relevant one in the averaging -- it depends on the quality target of the algorithm used.
Supersampling increases the amount of GPU work needed to produce a frame - twice as many pixels in the rendered frame tends to be roughly twice the work.
The base bitmap size is determined by the screens - generally with a multiplier applied, to get the size one need to render in order to get one rendered pixel for each screen pixel at the centre of the view, where the pixel concentration, as seen through the magnifying lenses, is the highest.
WMR get the resolution from the HMD drivers, and may apply any multiplier of its own, before passing it on to applications, as the resolution it recommends they render -- this includes SteamVR.
SteamVR in turn applies its two multipliers on the resolution that may or may not already have been multiplied by WMR -- they are both applied, so if you have 200% global, and 50% per-app, the two cancel each other out. It recommends this potentially thrice multiplied resolution to its client applications.
The game may then use this resolution as recommended, ignore it completely and substitue its own (infamously the case with many UnrealEngine4 games), or add its own modifiers on top...
Elite Dangerous has two such settings: "HMD Quality", which adds a fourth multiplier to those of WMR and SteamVR, that went before it, and: "Supersampling", which does the same, but crucially downsamples to it's "before" resolution on its own, before it hands the output frame over to SteamVR.
Elite's: "Supersampling" should only be used after the aggregate product of all other multipliers amount to twice the width and height of the base resolution, which corresponds to four times the amount of pixels to render (...which is the scale SteamVR uses: Its 400% is the same as x2.0 elsewhere), for reasons previously mentioned.
-You want as much detail as possible preserved until the last step in the process of bringing it onto your screens, but if that step can not use all rendered pixels, you may as well "bake in" the overshooting detail beforehand, and still benefit from it - that's what ED's "supersampling" effectively does, but your computer is likely to be overloaded long before you reach that point anyway, so it's a bit of a moot point. :7
I'd opine its best to set one's render resolution at the common start and end point in the chain of runtimes, which in your case would be WMR -- it is what will eventually receive the final frames and put them on screen, and leave everything else at 100%/x1.0.
Motion smoothing is one of many terms for a few techniques to produce synthetic filler frames, that are slotted in when your computer can not keep up with the refresh rate of the HMD - every vendor has its own implementations and names for them.
...so if the HMD wants 90 frames per second, but your computer can only render 45, the responsible VR runtime will slot in a synthetic frame every other refresh cycle, where the game failes to produce a proper rendered frame in time.
In this case, I believe we are talking motion vector extrapolation, which does in some ways the same thing as when you compress video: It analyses the last two consecutive frames, and tries to determine how the features represented by each pixel have moved from one frame to the other, and then predicts by dead reconning where they should end up in the next frame.
This tends to produce the same sort of artefacts as you can often see in digital video (...and which I personally find utterly unacceptable in VR, but others find indistinguishable from "real" frames), but does account for the player and things in the scene moving - something of a "six degrees of freedom" solution, if you like.
A simpler alternative, is one where you reuse the last full frame as-is, but pans it left-right/up-down in a way that corresponds with how much you have turned your head since that last frame. This keeps the rotational orientation responsive, and consistent with your looking around, but any motion is halted relative to the last frame, producing something of a "stop motion film" effect.
Hope that helped somewhat, and wasn't too much of a "eyes-glazing-over-y" info dump...
EDIT: If you click the menu button on the SteamVR status window on the desktop, you will find - in the developer sub-menu - an option to open the: "advanced frame timing" window, which shows a running graph of how long it takes to render a frame.
There is a check box you can tick, which will make this graph draw inside your VR environment, attached to one of your hand controllers.
You'll want this "frame time" to be below the refresh interval of the hmd, plus a bit, which for 90Hz is 1/90 rounded up to 12 milliseconds (this is centered vertically in the graph), for smoothest and most accurate results. If it goes over, synthetic frames will be substituted - as per your preferences. (EDIT2: It's your choice, really: You can reduce the graphics quality until your frame times get short enough; Or favour graphics quality and suffer the reduced frame rate, if you find that a more palatable trade-off.)
![jonny909 [VR]](https://forums-cdn.zaonce.net/data/avatars/m/74/74727.jpg?1628253880){kind=avatar}
