EDVR 0.18.3

0.18.3 replaces 0.18.2 as the Latest release. It is a patch release. In the desktop edition, DLAA, DLSS and FSR now keep running with a weapon drawn, while aiming and at settlements on foot. In VR, a planet approached in supercruise no longer blurs, and the supercruise orbit lines, bars and space dust are made at the HUD's resolution. One setting changes its default, the desktop edition's capture key, which is now NumLock (it was F10). No VR setting changes its default.

Choose edvr-installer-0.18.3.zip for VR or edvr-flat-installer-0.18.3.zip for the desktop edition. The full packages, edvr-0.18.3.zip and edvr-flat-0.18.3.zip, also include their respective installers and files for a manual install.

What changed since 0.18.2

• In the desktop edition, DLAA, DLSS and FSR skipped every frame in which the weapon and the world were drawn with different cameras, and every on-foot frame at a settlement. Those frames showed the game's picture with spatial smoothing only, while EDVR's own TAA kept working. EDVR now follows the weapon's animated geometry from one frame to the next, so the weapon keeps its own motion and the world keeps the upscaler's result.
• In the desktop edition, plasma weapons switched the upscaler off for the world. Their glow is drawn with a blend mode EDVR refused to protect, and the whole frame lost its anti-aliasing. EDVR now protects those overlays and keeps the world anti-aliased.
• In the desktop edition, with Elite's Supersampling at 1.5 or 2.0 on a 4K screen, DLAA, DLSS and FSR never ran on foot: the render size was past a limit of about 16 million pixels, so every frame used spatial smoothing only. The limit is now about 64 million pixels and those frames run the upscaler.
• In the desktop edition, with Supersampling below 1.0, where DLSS and FSR upscale, every frame with the weapon up skipped the upscaler. It now runs with the weapon up.
• In the desktop edition, aiming down sights switched DLAA, DLSS and FSR off for plasma weapons and for any weapon with sights. While aiming, the weapon's camera takes the world's near plane, and EDVR read its depth pass as part of the world. EDVR now tells the two apart by their projection, and AA stays on while aiming.
• In the desktop edition at Supersampling 1.0 and above, the world seen through a sight lost its anti-aliasing where the sight's glow and lens covered it. The sight's own light is now added on top of the anti-aliased world.
• In the desktop edition, the weapon itself flickered between processed and raw while you moved, on about four frames in five. The game reorders the weapon's geometry every frame, and EDVR was matching last frame's copy by its place in that order. It now matches by the geometry's content.
• In the desktop edition, EDVR's own TAA used to check last frame's depth at a single point, which at a jittered silhouette flips between the roof and the sky from frame to frame, so edge pixels lost their history on alternate frames. It now takes the best of the four points around the previous position, the rule the steady-detail check already used. This targets the standing-still shimmer on the top bevel of settlement roofs.
• In VR, a planet approached in supercruise blurred under DLSS. The camera motion EDVR hands the upscaler loses the ship's translation, so the planet moved by under 1% of its real growth. EDVR now reads each body's own motion from the planet's surface-patch constants and uses it on that body's pixels, for DLSS, FSR and EDVR's own TAA. It runs while fix.temporal_aa does and has no setting of its own.
• In VR, the orange orbit lines and cyan rings the game draws in supercruise looked heavy beside the HUD panels once fix.ui_quality made the panels sharp, because the game draws them a fixed number of pixels wide at the render size. While the panels are scaled they are now drawn narrower by the same factor: half as wide at the default 100 with HMD Quality 0.50, 0.4 of the width at 125. At or above your HMD Quality they are as the game draws them.
• In VR with fix.temporal_aa on, where the HUD layer is wider than the game's render (HMD Quality below the fix.ui_quality target), the orbit lines, the faint vertical bars of the supercruise display and the space dust are drawn into the layer at its own size, so they are no longer upscaled with the world.
• The desktop edition's capture key is NumLock (it was F10). A plain press writes a short report covering about one second, and Shift plus the key requests the full capture, which is slow and large. The earlier window ran two minutes and lowered the frame rate while it ran. The F8 warning, the installer's status line and the desktop README name NumLock.
• In both installers, Save logs now writes the zip to your Desktop in pieces, so a large bundle no longer has to fit in memory. It collects the desktop edition's NumLock capture folders (the allowance for captures rises from 512 MB to 1.5 GB), and a capture that is incomplete, from an older session or too large is left out with a note that names it. A log that changes while it is copied is left out with a note. If a capture file changes during the copy, the bundle fails with a message: close the game and press Save logs again.

Configuration changes

• hotkey.dump_draws defaults to NUMLOCK in the desktop edition (it was F10). The VR edition leaves it empty, which is off, as before. A dump_draws line already in your edvr-flat.ini decides the key, and the 0.18.2 desktop installer wrote dump_draws = F10 into new files, so check which key yours names after updating.
• No other setting changes its default, and the F8 menu and the settings window gain no rows.

Reporting a problem

• The second line of every log names the build and must read version v0.18.3. A log naming another version is not from this build; an update that did not take and Windows Defender quarantining a DLL have both caused that.
• Run edvr-installer.exe (or edvr-flat-installer.exe) and press Save logs: it writes one zip to your Desktop with both logs of the last session, edvr_breadcrumbs.txt and your settings file. Then open an issue and attach the zip.
• In the desktop edition, press NumLock while the problem is on screen before you save the logs, so the log holds a report from that moment. Use Shift plus NumLock only when asked.
• By hand, attach both files from edvr_logs. For VR, say which headset, runtime and HMD Quality you use; for the desktop edition, include your GPU, resolution, AA choice and any graphics mods.

Checksums

The installers are unsigned, so Windows will warn about them and the hash is the way to check where a file came from. SHA-256 of the executable inside each zip:

• edvr-installer.exe: 53c4c4ffbf7aced0ac8682f4c25eb896d65edfcdb36cdf095d7267832768d60a
• edvr-flat-installer.exe: cf6337b13d3efbacfe44efee2d3fb7968bd46f942c832ed00bfdd8e7173ca38a

SHA-256 of the zips as downloaded:

• edvr-installer-0.18.3.zip: 48582278e272642a603816e839e89e82b68dcd1532cdeb3f308d8ef11fc07635
• edvr-flat-installer-0.18.3.zip: 719d6428a0138cb232bd075fe30459fd2df13394f7001cb2b865fc5033198767

Thanks

Thanks as well to everyone who opened an issue or sent logs for this release. Those reports are how the fixes above were found and checked.

EDVR 0.18.2

0.18.2 replaces 0.18.1 as the Latest release. This patch focuses on the desktop edition's anti-aliasing. No setting changes its default; VR behavior is unchanged. Everything in the 0.18.1 notes still holds unless this page says otherwise.

Choose edvr-installer-0.18.2.zip for VR or edvr-flat-installer-0.18.2.zip for the desktop edition. The full packages, edvr-0.18.2.zip and edvr-flat-0.18.2.zip, also include their respective installers and files for a manual install.

What changed since 0.18.1

• In the desktop edition, drawing a weapon could turn off anti-aliasing for the world around it. EDVR now keeps track of the weapon and world separately through the game's drawing and clearing passes, including weapon details drawn into depth before their colour appears and overlays drawn late in the frame. Testing with several weapons confirmed that world AA stayed engaged; the matching log recorded 300 of 300 sampled frames treated in successive windows, with zero capture refusals.
• The desktop renderer avoids building and copying draw records that it does not need and repeating camera checks already made for that draw. This incorporates @arturbac's profiling-backed work in PR 72. Moving objects keep their exact game-provided motion while the renderer does less work for each draw.
• Desktop F10 diagnostic captures now finish large draw traces that previously ran out of room, and retain more evidence about which camera or game pass first prevented AA from running.

Known limits

• In frames where the weapon and world use different cameras, the desktop edition may use temporal AA (TAA) even when DLSS is selected. Shimmer on settlement buildings while landing remains under investigation.
• The on-foot resolve and the sharp on-foot maps are on by default when fix.temporal_aa and fix.ui_quality are on. If either looks wrong, experimental.temporal_aa_on_foot_world = off brings back the per-eye upscaling and experimental.on_foot_maps_sharp = off the old map handling. Both need EDVR's own OpenXR runtime, so Elite's native Oculus path keeps the older on-foot picture.
• The HUD's bloom halo is gone in the layer, and the yellow <> marks at the scanner rim still smear. Thin station structure such as Coriolis crossbraces can still blur while the station turns.
• The Quest 3 / Virtual Desktop headset-image lock on foot remains unresolved. Two logs show the game falling to a hard 10 fps limit while waiting inside Virtual Desktop's runtime, including a second occurrence on 0.18.1.
• If you install the VR edition by hand, copy both DLLs from this release.

Reporting a problem

• The second line of every log names the build and must read version v0.18.2. A log naming another version is not from this build; an update that did not take and Windows Defender quarantining a DLL have both caused that.
• Run edvr-installer.exe (or edvr-flat-installer.exe) and press Save logs: it writes one zip to your Desktop with both logs of the last session, edvr_breadcrumbs.txt and your settings file. Then open an issue and attach the zip.
• By hand, attach both files from edvr_logs. For VR, say which headset, runtime and HMD Quality you use; for the desktop edition, include your GPU, resolution, AA choice and any graphics mods.

Checksums

The installers are unsigned, so Windows will warn about them and the hash is the way to check where a file came from. SHA-256 of the executable inside each zip:

• edvr-installer.exe: 28710c237002ce0035e665663a8d1be773d4613a51e99509000aa80849631e29
• edvr-flat-installer.exe: bc119601e0df5fe1634fe1d5f241cb1166c60406c70f3cb98e95db97ffa7f64d

SHA-256 of the zips as downloaded:

• edvr-0.18.2.zip: 88f400ba40bb7b1c91dde301d1a76c2276094bac70877a351af2a98bd29abc88
• edvr-installer-0.18.2.zip: 6f859bb61a3b77724cf1be98afbbc0f8ba50bfb74cd01e212893eb64a4a7b085
• edvr-flat-0.18.2.zip: 4806b6178aeca6f613f9d80773cf8d54d5fe64b2c63002bb7d1919e1e8b3f7be
• edvr-flat-installer-0.18.2.zip: 3f749923b54dd11f92677c4efe9627a3dd0a7eb8804af0f0d7843aef33a1c0f9

Thanks

• @arturbac: profiled the desktop renderer under Proton and contributed PR 72's changes to create draw records only when needed, reuse verified camera hashes and avoid repeated setup of empty projection recipes. His measurements and comparisons helped reduce the renderer's per-draw CPU work while preserving the motion information used for AA.

Thanks as well to everyone who opened an issue or sent logs for this release. Those reports are how the fixes above were found and checked.

EDVR 0.18.1

0.18.1 replaces 0.18.0 as the Latest release. It is a patch release: fixes on top of 0.18.0, and no setting changes its default. Everything in the 0.18.0 notes still holds unless this page says otherwise.

What changed since 0.18.0

• On a rig with a force-feedback wheel (likely a Logitech G29, reached through the Steam overlay), Elite died within 30 s of every other launch and started flat on the next one (issue 45). EDVR's menu keyboard gate now leaves every DirectInput device that is not a keyboard alone.
• The VR runtime's four startup shaders are now built into the DLL, so the runtime no longer compiles them, or loads Microsoft's shader compiler, while VR starts. That compile took about 0.4 s in an earlier measured launch; the picture does not change.
• In the desktop edition, anti-aliasing that stayed off during gameplay for three supporters now runs for all three. On an RX 9070 XT with FSR a game image filter that EDVR did not recognise held it back, and EDVR now admits that filter; the other two, both running EDHM, report it working after updating.
• Under Proton the desktop edition spent about 25 ms a frame reading the game's constant buffers back from DXVK's mapped memory (issue 65). EDVR now gives the game cached memory for those buffers wherever it measures such reads as slow.
• Under Wine or Proton the desktop edition no longer times its own CPU work by default, because on a Proton station concourse that timing cost a sampled frame about 21 ms and showed as a hitch. Windows keeps it on, and EDVR_FLAT_CPU_CLOCKS set to 1 or 0 decides either way. The measurements are arturbac's, from their own Proton build.
• In the desktop edition, cockpit panels drawn with Elite's Disable GUI effects on are now treated like the stock panels.

Known limits

• The on-foot resolve and the sharp on-foot maps are on by default when fix.temporal_aa and fix.ui_quality are on. If either looks wrong, experimental.temporal_aa_on_foot_world = off brings back the per-eye upscaling and experimental.on_foot_maps_sharp = off the old map handling. Both need EDVR's own OpenXR runtime, so Elite's native Oculus path keeps the older on-foot picture.
• The HUD's bloom halo is gone in the layer, and the yellow <> marks at the scanner rim still smear. Thin station structure such as Coriolis crossbraces can still blur while the station turns.
• Open reports: a black screen in VR after choosing a game mode, seen after updating with an older edvr.ini and cleared by a clean reinstall (issue 67); 1 to 2 s freezes on Index with EDHM (issue 63), where the logs so far show Elite's render thread stalled outside EDVR's own work; crashes near planetary surfaces (issue 62), which the reporter says predate EDVR; and a Quest 3 on Virtual Desktop whose headset image locked on foot while the game fell to 10 fps, with every frame waiting inside Virtual Desktop's runtime.
• If you install by hand, copy both DLLs from this release. A 0.18.1 d3d11.dll beside a 0.18.0 runtime cannot exchange its per-frame signal with it, and the log reports a layout mismatch.

Reporting a problem

• The second line of every log names the build and must read version v0.18.1. A log naming another version is not from this build; an update that did not take and Windows Defender quarantining a DLL have both caused that.
• Run edvr-installer.exe (or edvr-flat-installer.exe) and press Save logs: it writes one zip to your Desktop with both logs of the last session, edvr_breadcrumbs.txt and your settings file. Then open an issue and attach the zip.
• By hand, attach both files from edvr_logs, and say which headset, runtime and HMD Quality you use.

Checksums

The installers are unsigned, so Windows will warn about them and the hash is the way to check where a file came from. SHA-256 of the executable inside each zip:

• edvr-installer.exe: 6c71da3f32aacb78158bdc17156771f3246670ac0dded840c40790d9322f978c
• edvr-flat-installer.exe: 203515bd595de2cac3e860887c7dac64167e8d61ed16ad6f436116aa5174bb78

SHA-256 of the zips as downloaded:

• edvr-installer-0.18.1.zip: 566542052ca818f195f442652535c3c62692592d0fb0aeae3b2bc4a4257b1f9d
• edvr-flat-installer-0.18.1.zip: 46707939753127ee2bdb8bb44ddd1657ecbc06fe9d05f22b8ba885870d4c588a

Thanks

• @arturbac: diagnosed the Linux/Proton cost of EDVR's constant-buffer copies in issue 65 with a PDB build, perf and AMD LBR profiling, showed that reads of DXVK's write-combined mappings were the cause, proposed staging those maps in cached memory and supplied a working patch with Proton measurements in PR 66. The map cache in this release builds on that diagnosis and approach, and arturbac wrote the Proton CPU timing clock policy that is merged in PR 66.
• @dmnemec: found and fixed the launch crash behind issue 45 in PR 68, so the keyboard gate now touches keyboard devices only, and tested it with the reporter.

Thanks as well to everyone who opened an issue or sent logs for this release. Those reports are how the fixes above were found and checked.

EDVR 0.18.0

0.18.0 replaces 0.17.0 as the Latest release. It builds on 0.17.0's native OpenXR runtime with a cockpit interface drawn at full size and kept out of the upscaler, station and hangar motion taken from the game's own records, a cheaper and steadier picture on foot, and safer installs and settings. It was tested through five pre-releases, and a separate download brings temporal anti-aliasing to desktop Elite.

Read this before you update

• The installer now comes zipped: download edvr-installer-<version>.zip, unzip it and run edvr-installer.exe. Desktop players want the separate flat edition below.
• fix.temporal_aa still ships off, and most of what follows acts only once you set it to DLSS, FSR or TAA.
• fix.ui_quality is new and ships at 100, so the cockpit panels are made at their HMD Quality 1.0 size from the first launch. The menu and HUD layer described below also needs fix.temporal_aa on. It costs video memory; set off to go back.
• fix.vscreen_res_width now ships auto (it was 1920), so the on-foot screen and HMD Cinema come up sharper after one VR session. It costs GPU time in proportion; type 1920 for the stock screen.
• With fix.temporal_aa on, VR on foot now resolves the world once and draws the maps sharp by default. Each part has flown, but making them the default has not been flown yet; Known limits has the rest.
• The OpenXR runtime's frame-end overlap is on by default now. There is nothing to set.
• On update the installer keeps every value you changed and adopts a new default only where your file still held the old one, and its report lists which settings went which way. A line for a removed setting is kept at the end of its section under a comment and does nothing.
• The three field-of-view trims left the F8 menu and the desktop settings window. The installer moves a value you set to its new place in edvr.ini, and it keeps trimming.

The cockpit interface and menus

• fix.ui_quality has the game make its cockpit panels at the size they would have at HMD Quality 1.0 (100) or 1.25 (125), whatever HMD Quality the 3D scene renders at, so panel text is no longer drawn small and stretched. It takes off, 100 or 125 and is live.
• A value changed live in F8 resizes the panels at the next panel init or view change, so set it before launching when you compare values.
• With fix.temporal_aa on as well, the menus, station services, the loading screen and the cockpit HUD (holo panels, flight HUD, target sprite, radar icons, ship and target holograms) are drawn into their own layer after DLSS or FSR, so HUD text no longer smears below HMD Quality 1.0. In flight Sean judged the HUD good and the menus sharp.
• The layer costs video memory, and 100 is cheaper than 125; the comment above the key in edvr.ini gives the price.

Stations and terrain

• At stations, in hangars and on foot, the temporal pass takes object motion from the game's own per-frame records instead of estimating it, which steadies a rotating station's hull. Station rotation and the hangar flew clean and Sean judged them good, and the close-range hull shaders have flown too.
• Planetary terrain now takes the camera's motion, and the separate terrain pass, which cost about half a millisecond of CPU a frame, is gone. A low-flight comparison saw no smearing either way.
• If distant hills shimmer in VR, turn off terrain checkerboard rendering in Elite's graphics options. Every stock VR preset turns it on, it halves the horizontal detail DLSS receives for distant terrain, and turning it off removed the shimmer. EDVR now says so in the headset when the option is on.
• If Elite's own Supersampling is below 1, EDVR shows a headset notice suggesting HMD Image Quality instead, since the game then upscales the world before DLSS sees it.

On foot

• On foot, Elite draws the world flat into a 2D screen and shows that screen to both eyes. With fix.temporal_aa and fix.ui_quality on, EDVR now anti-aliases that world once a frame instead of upscaling each eye's view of it, which cut EDVR's own GPU time on foot by about a third in its first flight (an estimate against earlier windows in lighter scenes).
• Fine repeating textures such as grates, hose spools and fences no longer shimmer on foot, in VR or on the desktop. Sean reported no ghosting or trails in his flights since.
• The galaxy and system maps and other panels shown on the on-foot screen no longer smear when you drag them, because they are composited after the upscaler (same two settings). Sean's flight of it: "it all looks perfect to my eye".
• If the on-foot picture or the maps look wrong to you, experimental.temporal_aa_on_foot_world = off brings back the per-eye upscaling on foot and experimental.on_foot_maps_sharp = off the old handling of the maps.
• fix.vscreen_res_width = auto sizes the on-foot screen (and HMD Cinema) from your headset: 125% of the eye width it rendered last session, or a smaller fitted width when the on-foot resolve runs, since the eye shows only part of the screen. A typed width is used exactly and the height always follows at 16:9.
• fix.panel_curvature now bends the intro movie and the splash as well as the on-foot screen, and the on-foot resolve works with a curved screen.

DLSS, upscaling and frame pacing

• DLSS now asks NVIDIA about all four of its modes before it gives up on an input size. Below HMD Quality 0.5, where no DLSS mode serves an input under half the output, EDVR asks for a smaller output and lets the runtime upscale the rest.
• The OpenXR runtime now finishes one frame while the next one starts, by default, and Elite's render thread no longer waits for it at the Present handoff or inside a loading screen. It has flown on Pimax's runtime and on SteamVR's OpenXR runtime, and Sean called it "Much better."
• The interface resolve, the journal reader and shader loading each take less time from Elite's render thread.
• fix.settlement_detail is a frame-rate governor for busy settlements, and it ships at game, which leaves the game's detail untouched. auto thins distant detail beyond about 100 m in the cockpit only while frames run long, and reduced always thins it.

Holograms and radar

• With fix.temporal_aa on, cockpit holograms, the supercruise radar's star icon, the distance digits and the weapons panel text keep their own cockpit depth under the temporal pass instead of the sky's, so they stay steady under DLSS and FSR. Sean: "That fixed the holograms and the radar." Station text in the hangar is fixed the same way.

Known limits

• Not yet seen in a headset: the DLSS handling below HMD Quality 0.5, the frame-end overlap on Quest runtimes, the HEATSINK label's doubling fix, the terrain checkerboard and Supersampling notices, the curved intro and splash since a mirroring bug found in their first flight was fixed, and the fix for cockpit panels drawn with Elite's Disable GUI effects on.
• The on-foot resolve has flown four times, all on Sean's rig: the first priced it, the next three found and fixed the texture shimmer, and in the last Sean judged on foot and HMD Cinema good. The map fix has flown once, with the resolve off. Neither has flown as a default, and neither has the fitted screen width or the resolve on a curved screen.
• The on-foot resolve and the map fix need EDVR's own OpenXR runtime, so Elite's native Oculus path keeps the older on-foot picture.
• The HUD's bloom halo is gone in the layer, the yellow <> marks at the scanner rim still smear, and no flight has checked whether the mouse cursor can still hide behind panels.
• Thin station structure such as Coriolis crossbraces can still blur while the station turns; a repair is built but has not been confirmed by eye.
• Open reports: crashes near planetary surfaces (issue 62); 1 to 2 s freezes on Index with EDHM (issue 63); one Valve Index rig whose game alternates between dying at launch and starting flat (issue 45); crashes on one Windows 10 rig with Windows Mixed Reality, where EDVR has never been tested.

Configuration changes

• Added: fix.ui_quality (off, 100 or 125; default 100), fix.settlement_detail (game, auto or reduced; default game) and menu.fps_overlay_lock (default off), which keeps the FPS readout visible inside the F8 panel.
• Added for VR on foot, both on by default and both needing fix.temporal_aa and fix.ui_quality on: experimental.temporal_aa_on_foot_world (auto or off) and experimental.on_foot_maps_sharp (on or off).
• Changed: fix.vscreen_res_width defaults to auto and is now in the F8 menu as well; fix.panel_curvature is labelled "Screen curve (on foot, intro, splash)"; the FSR choice of fix.temporal_aa is labelled FSR 3.1; log.max_mb defaults to 16.
• Moved out of the menus: fix.fov_trim_vertical, fix.fov_trim_outer and fix.fov_trim_nasal are ini-only now, under new names the installer fills in for you.
• Removed with their rows: fix.eye_mask and fix.eye_mask_trim (measured, the eye mask was not worth its frame time), fix.head_offset_view_bridge (inert in practice) and fix.vscreen_res_height (the height follows the width at 16:9), along with the installer window's Resolution dropdown.
• Developer-only keys went too. The two that were on by default, the terrain pass and the per-object motion estimates, are replaced by the camera's motion and the game's own records described above.
• A leftover line for a removed key does nothing and is not an error. The log notes such lines once a session and names the settings file it read.

Installer and settings

• When the installer is pointed at the wrong executable it now says which case it is: Horizons (not supported), an Odyssey revision this build does not know, or a file it could not read.
• A file that a scanner holds open for a moment no longer fails the install; the installer ret...

EDVR 0.18.0-rc.5

This is the fifth pre-release of the 0.18 line, published for testing, and it replaces rc.4. It is not marked Latest: 0.17.0 stays the release for anyone who is not here to test. Since rc.4 the flat edition has a new default route and its first working flight on a Mac under CrossOver, and VR gets an experimental on-foot route that ships off. Everything in the rc.4, rc.3 and rc.2 notes still holds unless this page says otherwise.

Read this before you update

• No default changes for VR, and no new VR setting ships on. A default VR install behaves as rc.4 did, apart from the fixes listed below.
• The new on-foot world route for VR, experimental.temporal_aa_on_foot_world, ships off. Leave it off unless you are testing it on purpose: this build does not jitter the world, and its one flight judged only cost and plumbing.
• Flat only: the new experimental.temporal_aa_before_post ships auto, so flat anti-aliasing resolves the game's HDR image before bloom, depth of field and the tone map whenever Elite renders at least at the output size. The installer writes the line into an existing edvr-flat.ini as auto, and a file without the line reads auto too.
• That route flew in the main-menu hangar on DLSS and Sean made it the default. On Windows the FSR, EDVR TAA, game AA and ReShade legs have not flown; set it to off to get rc.4's behaviour back.
• Twelve retired keys leave the ini. None of them was on by default, so a default install loses nothing.
• On a Mac under CrossOver, the flat build has one good flight with this fix; read the macOS section before you try it.

What changed since rc.4

• Flown: VR on foot has an experimental route that resolves the world once a frame instead of upscaling each eye's view of it, because on foot Elite draws the world flat into its 2D screen and shows that screen to both eyes. Set experimental.temporal_aa_on_foot_world = auto to try it; it needs fix.ui_quality on and fix.panel_curvature at 0, and it is untested outside EDVR's own OpenXR runtime.
• Flown: in its first flight (Pimax Crystal Super, DLSS, standing in a station) the route owned most on-foot frames and cut EDVR's own GPU time on foot by about a third (3.50 against 5.06 ms) compared with earlier key-off windows on the same rig; that log has no key-off baseline of its own and the scenes differed, so treat it as an estimate. The world was not jittered, so that flight says nothing about image quality, and no weapon was drawn.
• Flown: advanced.vr_camera_census, default off, a diagnostic that watches the game's camera refresh in VR without changing anything and logs which camera is which. It ran through the route's flight without a fault, and python tools\edvr_log.py --camera-census reads its lines.
• Flown: with the HUD layer on (fix.ui_quality and fix.temporal_aa both on), the cockpit HUD no longer shows through the station menu's frosted panel, and the mirrored smear the first fix left in that panel is gone too. Sean called the result fixed in a flight on 2026-09-30.
• Unchanged: the mouse-cursor fix from rc.3 is still unconfirmed. Its rule ran in the station-menu flights and took every draw it saw, but no flight looked at the cursor, so please sweep it across cockpit panels, station services and the menus.
• Open: a report that the cockpit side panels look the same at every fix.ui_quality value is not explained. The likeliest cause is that a value changed live in F8 resizes the panels only at the next panel init or view change, so set it before launching when you compare.
• Built, not flown: three fixes never saw a draw when every other feature that watches draws was off: the wake pulse fix, night vision and fix.witchspace_stars = off, which left the starfield in place. Default settings kept them working, which is why nobody noticed.
• Built, not flown: the hologram depth pass's near-light step could read the game's image as empty when the game left it bound as a render target, and now clears that binding first. Round 10 from rc.4, aimed at the doubled HEATSINK label, is still not flown.
• Open: one tester on Windows 10 with Windows Mixed Reality had three crashes in four rc.4 sessions. EDVR has never been flown on Windows 10 or WMR and the cause is not known; Reporting below says what helps.
• Open: issue 45, where one Valve Index rig alternates between a launch that dies within 30 s and a launch that starts flat. This build does not fix it; the flat launch is EDVR's crash guard keeping its hooks off after the death, and the death itself is unexplained.
• Unchanged: still built, not flown from rc.4: the DLSS served-floor handling below HMD Quality 0.5, the Coriolis rigid-part repair, the sharpen pass's release on a device change, the graphics DLL pin and the frame-end overlap on Quest runtimes. HMD Quality 0.45 on a DLSS card is still the most wanted data point.
• Unchanged: still open from rc.4: the dead world-path vector after a long parked stay, the HUD's missing bloom halo and the yellow <> marks at the scanner rim. Transition flash behaves as the rc.4 notes describe.

Configuration changes

• A line in your settings file that this build does not read does nothing and is not an error. The log notes such lines once a session and now names the file it actually read, edvr.ini or edvr-flat.ini; the installer's merge keeps your value under a comment saying this version no longer uses it.
• Removed with three HUD experiments that the cockpit HUD layer replaced: experimental.hud_icons, experimental.holo_panels and experimental.hud_grain, with their tuning keys advanced.hud_icon_scale, _sharpen and _vs, advanced.holo_panel_scale, _sharpen, _size and _vs, and advanced.hud_grain_level and _vs.
• All twelve shipped as commented defaults at stock, had no F8 row and never flew, so default behaviour is unchanged. Only an active line you added yourself stops doing anything.
• Added for VR: experimental.temporal_aa_on_foot_world, default off, and advanced.vr_camera_census, default off, both described above. Both are live, and the flat build reads both as off.
• Added for flat: experimental.temporal_aa_before_post, default auto. off keeps the old copy route alone, any other value reads as off, and it has no F8 row, so change it in edvr-flat.ini. The VR build never reads it.
• The shared edvr.ini carries the new keys to every install, and each build ignores the other's keys without a note.

Installer and settings

• Messages now name the settings file the process actually read or wrote. A flat install that reads edvr-flat.ini says so in the F8 panel's "written to" lines, the config notes and the installer merge's "carried over from your" note, where rc.4 said edvr.ini and could send you to the wrong file.
• Nothing else in the installer changed, and its log bundle collects the same files as rc.4's, edvr_breadcrumbs.txt included.

The flat (non-VR) installer

If you fly in a headset, skip this section.

• edvr-flat-installer-<version>.zip is still a separate, early, experimental build for desktop Elite, and it is not to be installed over a VR copy. On Windows it is still tested on the Epic Games install only.
• The HDR route has flown and is the default: with experimental.temporal_aa_before_post = auto, EDVR resolves the game's HDR scene before bloom, depth of field and the tone map, so a post-processing chain it has never seen should no longer block anti-aliasing. It applies when Elite renders at least at the output size (Supersampling 1.0 or more) and leaves the old route in charge below that; the game's own anti-aliasing still filters the result again, which looks softer.
• Two rc.4 users had every frame refused because their bloom, depth of field or game AA put passes EDVR did not know between the tone map and the final copy. The HDR route is meant to cover those chains at Supersampling 1.0 or more, and no flight from either user is recorded yet.
• When every frame is refused for 5 s, the flat work now stands down and checks every 1.5 s whether it can resume, and the F8 panel says anti-aliasing is not active and names the Elite settings to turn off. Below Supersampling 1.0 it adds that raising it to 1.0 lets EDVR anti-alias before bloom and depth of field. Both flew on Epic.
• The treated path does less CPU work: in a hangar flight the draw wrapper's D3D calls per substituted draw fell to about a tenth, and a flat cpu 5s: line now prices EDVR's own flat work. A new F8 note names the file that handles every graphics call when a wrapper such as ReShade does; that note has not flown with ReShade.
• Every flat log still carries a startup line saying advanced.context_hook_mode = "off" is not one of auto, shared, private or live. It is spurious and you can ignore it.
• Still open for flat: station and on-foot projection coverage, mixed-camera HDR ownership, the corona-smear regression, mod effect ordering, the hangar-floor defect in the menu and VR regression testing of the shared temporal code.

macOS and CrossOver (flat)

If you do not play Elite on a Mac, skip this section.

• On a Mac, Elite runs through CrossOver, whose d3d11.dll is DXMT, a layer from D3D11 to Metal. With rc.4's flat build there, one log showed no frames treated and later builds made the game exit about 30 s in.
• Flown: the exit is fixed. DXMT ended the process when EDVR swapped the game's context state, so on DXMT the flat resolver now saves and restores that state itself, and every other device keeps the old path.
• Flown: on Sean's Mac (Apple M4 Max) the HDR route created DLSS and, after a switch in the menu, FSR, and treated nearly every frame for about a minute. By eye the black outlines on floor markings that rc.4 drew are gone and edges look anti-aliased with Elite'...

EDVR 0.18.0-rc.4

This is the fourth pre-release of the 0.18 line, published for testing, and it replaces rc.3. It is not marked Latest: 0.17.0 stays the release for anyone who is not here to test. One default changes (fix.ui_quality now ships at 100) and 26 retired keys leave the ini. Everything in the rc.3 and rc.2 notes still holds unless this page says otherwise.

Read this before you update

• fix.ui_quality now ships at 100, where it used to ship off. It takes off, 100 or 125, in percent of HMD Quality 1.0, and at 100 the cockpit panels are made at the size they would have at HMD Quality 1.0.
• As a default this is built, not flown: every flight on this page ran with the key set by hand.
• When the installer updates an install, its merge moves an off to 100, including an off you typed yourself, because it cannot tell yours from the old default. A 100 or 125 you set is kept.
• If you want it off, check the value after installing and set it back to off. A line you delete or comment out falls back to 100.
• With the shipped fix.temporal_aa = off, only the panel sizing changes; the HUD layer described below needs fix.temporal_aa on.
• In memory, the menu and loading-screen layer at 100 is 37 MB an eye at 3070x3032, and the cockpit HUD adds an HDR layer of 128 MB an eye at a 4074x3938 door (50 MB on a Quest 3), plus depth-stencil targets once a draw tests depth or stencil. The ini's own price list has the rest, and 100 is the cheaper setting.
• A leftover line for a removed key does nothing, and the log carries one note about such lines once a session.

What changed since rc.3

• Flown: the cockpit HUD now takes an HDR layer and is composited after the upscale. Until this build the holo panels, flight HUD and target sprite went through DLSS or FSR with the world, which is why HUD text smeared below HMD Quality 1.0; with fix.ui_quality at 100 or 125 they go into a per-eye layer at the UI size, along with eight radar and icon hologram families, and EDVR re-issues the game's own tonemap for it.
• Flown: phase 1 flew on the Steam install on 2026-09-27 and 28 (Sean: "cockpit looks good"), and later Frontier flights drew Sean's verdict that the HUD looked good. That is a qualitative check, and bloom parity was not measured.
• Flown: those flights found three regressions, each fixed the same day: the in-flight menu drew under the cockpit panels, the main menu was still drawn before the AA pass, and at HMD Quality 0.50 with fix.ui_quality = 125 the cockpit panels vanished. A frame whose tonemap EDVR cannot find now falls back to stock so the HUD is not lost, and a later flight recorded the menus fixed and sharp.
• Open: the layer has known limits. The HUD's bloom halo is gone, because bloom is computed from the HDR target and the taken elements are no longer in it, and the yellow <> marks at the scanner rim are still unidentified and still smear.
• Flown: ship and target holograms in the layer. In the Frontier flight of 2026-09-29 both the target and own-ship models were present and detailed in the final composition and Sean said both look great; that flight checked model presence only, with no controlled alpha or occlusion test.
• Built, not flown: the mouse-cursor fix from rc.3, since no flight in the record looked at the cursor with the layer on. Please sweep the cursor across cockpit panels, station services and the menus, and say whether it ever hides behind them.
• Flown: Elite's render thread no longer waits behind the OpenXR runtime's deferred frame end (frame_end_overlap, on by default since rc.2), either at the post-Present handoff or inside the loading boundary. In flight the handoff wait read 0.001 ms at p50 and p95 (Sean: "Much better."), though the flights do not show a controlled whole-frame gain.
• Built, not flown: the overlap path on Quest runtimes, since the two-wait flights used a Pimax Crystal Super through SteamVR's OpenXR runtime. If you fly a Quest runtime, native_frame_end_overlap_summary should read failures=0; please also watch loading screens, jumps and docking.
• Flown: rc.3's phantom-motion fix is now covered by flights, and so are its two review fixes, which rc.3 called bench-verified only.
• Flown: the close-range station shaders that rc.3 called harness-proven, and three more hull material pairs keyed since. The thin structure still blurs: in eye run 061832 Sean still saw crossbraces and building-like hull structures blur.
• Built, not flown: tracking Coriolis rigid parts through the game's native copies, the repair aimed at the remaining braces. It is built and installed on Frontier but not yet visually verified, so expect the crossbraces to look as they did in rc.3 until a rotating-station capture on this build says otherwise.
• Open: a parked stay can still carry a dead world-path vector, and this build does not fix it; later eye runs do not reproduce it, so it is a long-stay problem. If the hull blurs during a long parked stay, attach the log's camera parked at and registration, the rest lines.
• Unchanged: the DLSS served-floor handling is still built, not flown, because every 0.5 flight sits exactly on the floor and does not exercise it. HMD Quality 0.45, or any value under 0.5 on a DLSS or DLAA card, is still the most useful data point; the log line to watch for starts dlss floor: the game's ... is under the ... floor NVIDIA names.
• Built, not flown: round 10 of the hologram depth pass, which stops the resolve writing a UI-covered pixel and is aimed at the doubled HEATSINK label. Look at that label, a target inside 10 m and the reticle's triangles.
• Flown: the UI resolve no longer fetches inputs it was not given. With the optional inputs unbound the bench read 0.109 ms an eye, down from 0.245, and in flight 132352 the change applied almost always.
• Flown, effect not measured: smaller CPU changes that ran in the flights above but have no recorded before-and-after figure. The journal watcher's file work moved off Elite's render thread onto its own (the log says journal: reading on its own thread (N)), the pool copier no longer takes the engine mutex on Elite's job threads, and 76 more fixed shader variants are precompiled.
• Built, not flown: the sharpen pass behind fix.render_sharpness now releases everything it holds when the game recreates its D3D device, in VR as well as flat. Before, it kept resources from the old device, and in flat the sharpening stood down for the rest of the session. It passed its rig.
• Built, not flown: the graphics DLL now pins itself in memory at the first device creation, so an unload cannot unmap it under a worker thread. The one real case in shipped code was the HMD Quality refresh behind fix.ui_quality. The log says graphics module pinned=1 once a session.
• Open: at a busy fleet carrier with fix.ui_quality at 100, fix.sun_glare = stock measured worse on the GPU in the same scene, and the cause is not established. Leave fix.sun_glare at vivid or realistic when testing UI quality.

Transition flash

• The shipped behaviour is the trap, unchanged from 0.17.0: fix.transition_flash = 1 detects the one wrong-viewpoint frame at a transition and shows the previous good frame in its place, so do not expect transitions to look different.
• advanced.transition_flash_prevent is deleted, because a flight refuted the engine chain it hooked. It defaulted off, and a leftover line for it is ignored.
• advanced.transition_flash_eye_base still exists and still defaults to off, but once set to watch, on or alternate it is live and hooks the game's camera driver. Nothing in the docs declares it verified and no recorded flight shows a flash removed by it, so leave it off unless you are testing it on purpose.

Configuration changes

• A line in your edvr.ini that this build does not read does nothing and is not an error. The log carries one note about such lines once a session, and the installer's merge keeps your value under a comment saying this version no longer uses it.
• The three FOV trims moved and are ini-only now: fix.fov_trim_vertical, fix.fov_trim_outer and fix.fov_trim_nasal became experimental.fov_trim_vertical, experimental.fov_trim_outer and experimental.fov_trim_nasal, and their F8 Trim view rows are gone. Behaviour is unchanged and a value you set carries over.
• Removed with the eye mask: fix.eye_mask and fix.eye_mask_trim, with their F8 and desktop settings rows.
• Removed with foveated shading: experimental.foveation and its tuning keys advanced.foveation_inner, _outer, _distance, _passes, _monocular_edge, _overlap and _outer_rate.
• Removed with the camera-view heap scan: d3d11.camera_index_track and its tuning keys d3d11.camera_index_type_offset, _ordinal, _value_offset, _plausible_max and _mb_per_frame, plus fix.head_offset_view_bridge, which only held the last view that scan read.
• Removed Full System Scanner experiments: experimental.fss_theater, experimental.fss_ring_feed, experimental.fss_scan, advanced.fss_scan_level and advanced.fss_composite_probe. fix.fss_eye_sync superseded them and stays.
• Removed developer probes: advanced.eye_split, advanced.resolve_probe and advanced.stencil_probe.
• Removed with the in-engine flash module: advanced.transition_flash_prevent, as described under Transition flash.
• Default behaviour is unchanged for every removed key, because each was off, commented out or already inert, so the fix.ui_quality flip is the only change to what a default install does.
• One key is added: advanced.flat_camera_producer_probe, default off, a flat-profile diagnostic. There is nothing to set unless you are asked to.

Installer and settings

• A file that a scanner or indexer holds open fo...

EDVR 0.18.0-rc.3

This is the third pre-release of the 0.18 line, published for testing before 0.18.0 proper. It replaces rc.2. It is not marked Latest: 0.17.0 stays the release for anyone who is not here to test. Everything from rc.2's notes still holds except where a section below says otherwise.

A phantom-motion fix at parked stations, flown once, then hardened by review — not yet reflown

A culled object record could keep its last known motion and replay it forever, and Elite's station is exactly that kind of object when you're parked near it. A record the game stopped updating kept its last pose pair and marker; EDVR's compose kept reading that stale delta every frame instead of noticing it was frozen, which showed as a slow constant drift — about 0.2 px/frame parked at a Coriolis station, growing to about 3 px through a head move. The present-frame clock is now folded into the marker check, so a joined record only certifies motion at its own frame; an older one declines to the camera's own motion instead of repeating a stale number.

Flown 2026-09-26 (two eye runs, parked 10 km out): the drift was gone. The engine-record motion tracked the camera term within 0.1–0.3 px every frame, including through a 5 px head move, where before there was a constant parked drift. The station hull's treated edge-energy retention roughly doubled (0.23 → 0.47–0.55; cockpit stays ~1.0).

Since that flight, a code review found and fixed two more issues in this same code, neither yet reflown. One is a memory-safety cleanup (a 16-byte GPU upload was reading from a 4-byte source variable; only the first word was ever consumed, so this is not expected to have changed what the flight above saw, but it was undefined behavior regardless). The other is a real correctness fix: a probe used to detect the game's own pixel shaders could mistake EDVR's own installed patch for original game state, corrupting the saved copy it needed to restore from later. Both are bench/rig-verified (1,157–1,162 checks) but not confirmed by a flight against this exact build — if the station looks any different from the 2026-09-26 result above, that's the regression to report. If you noticed the station looking a little softer than fix.temporal_aa = off at long range in rc.1/rc.2, most of that was the original drift bug — the remainder is normal reconstruction softness on a dense distant structure, not a motion bug.

Close-range station shaders: harness-proven, not yet flown as part of a whole build. A follow-up investigation found that at close range (parked at the pad) the station hull is mostly drawn by stock pixel shaders rather than the keyed ones (vs_4361/vs_889A drew zero keyed binds there), and the stock path's own camera-motion term had gone dead across that same dump. Three more shader pairs are now keyed to close that gap (ps_51EE.../vs_4361, ps_D31D.../vs_889A, ps_4504.../vs_61AE), each proven against a 40,960-texel corpus with zero mismatches on the bench, but no flight yet exercises this exact set together. If you park close to a station pad, that's the case to watch.

fix.ui_quality: a mouse-cursor fix for the still-unflown menu/layer half

Built, not yet flown. A field report that the mouse cursor could hide behind cockpit panels when fix.ui_quality was on has a fix: what the game draws into an eye after the layered interface (the cursor, overlay effects) is now taken into the same layer, after the UI, so it stays on top instead of underneath. A review pass since then found the retry path could drop two of the original decision's exclusions (the UI-depth shader exclusion and the held world-screen identity); both are now preserved through the retry. This only affects the menu/layer half of fix.ui_quality, which — as in rc.1 and rc.2 — is still built but not flown in this form; the panel half remains flown OK and unchanged.

Installer: a clearer message when it's pointed at the wrong executable

Previously, any executable that failed the installer's pinned-build check got the same message ("not supported by this OpenXR build"), which was actively misleading for someone who pointed it at Elite Dangerous (Horizons) rather than Odyssey, or at an unreadable file. The installer now tells the three cases apart: Horizons (not supported at all, by design), an unrecognized Odyssey revision (needs a newer EDVR build), or a file it couldn't read (check your game files). No change to what the installer actually accepts — only to what it tells you when it refuses.

The flat (non-VR) installer: qualification work continues

No news for VR testers. Since rc.2, most of the change on main has gone into qualifying edvr-flat-installer's experimental desktop temporal-AA build — still a separate, early, non-VR-only artifact, still not something to install over your VR copy. A review pass found and fixed four more issues specific to that track (shader classification, a DLSS-negotiation timing gap, and a capture-loading check); none of it touches the VR path. If you're not specifically testing flat/desktop Elite, there's nothing here for you.

Reporting from this build

The second line of every log names the build: it must read version v0.18.0-rc.3. Please say whether you were parked at a station (near or far) and for how long, since that's exactly the condition the phantom-motion fix and the close-range shader keying both target.

EDVR 0.18.0-rc.2

This is the second pre-release of the 0.18 line, published for testing before 0.18.0 proper. It replaces rc.1, which was built and packaged before the v0.18.0-rc.1 tag existed. The version string every DLL and installer carries — Windows' own file-properties version and the line the running log prints — comes from git describe at build time, so rc.1's copy of that string read something like v0.17.0-461-g<hash> instead of v0.18.0-rc.1: cosmetic only, nothing about what rc.1 actually does was affected, but if you flew it, the log's version line did not match what you were told to expect. This build is tagged before it is built, so the string reads v0.18.0-rc.2 everywhere it appears. It is not marked Latest: 0.17.0 stays the release for anyone who is not here to test. Everything else below is unchanged from rc.1 unless a section says otherwise.

New in rc.2: a separate installer for flat (non-VR) Elite, and zipped installers

edvr-flat-installer-<version>.zip is a new, separate installer for an experimental temporal-AA build of EDVR for flat (desktop, non-VR) Elite. It is not part of your VR install and does not touch it: a game directory runs either the VR profile or the flat profile, never both, and switching between them on the same install needs --convert-profile on purpose. This is early — the qualification record (docs/design-flat-temporal-aa-2026-09-23.md) still lists open items (on-foot camera coverage, a corona-smear regression, VR-regression testing not yet done) — so unless you specifically want to test temporal AA on a monitor, this is not for you; the VR installer (edvr-installer-<version>.zip) is what you want, exactly as in rc.1.

Every installer now ships zipped instead of as a raw .exe, to cut release bandwidth. Download edvr-installer-<version>.zip, unzip it, and run edvr-installer.exe as before — the installer itself is unchanged, only how it's packaged for download. The full manual-install archives (edvr-<version>.zip, edvr-flat-<version>.zip) are unaffected; they already shipped zipped.

Also: the F8 menu's embedded FPS readout (menu.fps_overlay_lock) no longer freezes. It shared a refresh clock with the floating FPS overlay, which reset the clock before the embedded copy's own check ever saw it due, so the embedded number showed once when the menu opened and then held stale for as long as it stayed open. It now has its own clock and refreshes twice a second like the floating one. Full build green (native_menu_test, 99 checks); not separately flown.

Engine-truth motion at settlements: stations, hangars and walking

Object motion at settlements and stations now comes from the game's own per-frame records, not from EDVR estimating it. Elite's engine already carries an exact world transform and orientation for every object, per frame, in records EDVR did not previously read. Where the temporal pass used to infer motion for stations and ships from screen-space heuristics (the old per-object-motion.md estimates), it now takes the engine's own delta for the stock station pixel shaders, keyed one shader family at a time. Nine shader families are keyed at the station now: vs_4361/ps_1694 (547 of the station's ~1,193 instances a frame — the biggest single family, and the main source of its old rotation blur), vs_889A/ps_B46E/ps_EBA9, and the ps_CB42/ps_451A pair.

Flown and judged good, build f05c84b, 16:27 flight (HMD Quality 0.5, DLSS performance mode at exactly the floor): the station's rotation, the hangar, and on-foot movement all ran clean in the same session — no faults, no stand-downs. Both keyed station families were live and substituting (2,982 then 29,422 draws in one window; 360 then 2,206 in the other); the joined station motion measures exact to 0.002 px against the records' own 0.106-0.110 deg/frame rotation. On foot, the same flight read "frames dropped: none" across two windows (764/764 then 5,398/5,398 given, zero invalidated) — the exact metric that used to fail during walking (every source frame dropped, 2,031/2,031, because a walked scene is drawn by more than one camera; the fix holds each source draw to the camera that names it) and in a hangar (nothing used to name the source at all, because a hangar has no terrain draw; it is now named by the screen's own depth instead). Sean judged the station rotation and the hangar good ("All looks good to me now").

Not yet flown as a whole build: since that flight, the old per-object motion estimates and the legacy kinematic motion tracker — already fully superseded and unused by that point — have been deleted outright, along with several more diagnostic-only code paths. That deletion should not change what you see (the paths it removed were dead weight, not live behaviour), but no flight has yet confirmed the build with them actually gone. If station rotation, hangars or walking near settlement objects look any different from "all looks good" above, that is the regression to report.

Config keys removed with the estimates: advanced.temporal_aa_objects_reach and advanced.temporal_aa_objects_ships_metres are gone from edvr.ini — if you had either set, it is now ignored. advanced.temporal_aa_debug's movers and objects debug views are retired with them; the replacement is motion_source, which colours each pixel by where its motion actually came from (green: an engine rig record's exact delta; red: a rig record with no usable history yet; blue: the camera's own motion; yellow: a surface whose recorded depth changed after it was drawn).

Open: walking NPCs and other articulated "walker" objects are not on this path yet (they wait on a bone-palette change in a later phase) and still blur; ships in free space are also not yet covered. Neither is a regression — they were never covered by the estimates this replaces.

fix.settlement_detail: a settlement frame-rate governor, shipped switched off

New key, ships default game (off — untouched). At a busy settlement Elite draws tens of thousands of small parts a frame; when that runs the frame longer than your headset's refresh allows, auto thins the game's own level-of-detail distance beyond about 100 m and gives it back the moment the frame fits again, cockpit only (on foot the game's own detail always stands). reduced thins by the full amount at every busy settlement regardless of frame time. Sean's call for this pre-release was to ship it off by default; auto and reduced are there to opt into and everything below still holds for them.

This is the most flight-tested single change in this build — eight flights across shadow and acting modes. At the pad, parked, it held sustained 90 Hz for 90 seconds before hitting its ceiling (fixed since by raising advanced.settlement_detail_max from 4 to 6); a refinement flight found every one of its step rules firing correctly, but at the ceiling itself a quarter to a third of cycles still take two display slots at 10.1–10.7 ms mean — the wall there is now the frame's tail, not its mean, which is past what a step-based governor alone can reach. The lever is also confirmed inert at close range: near enough to a settlement, it thins draws that were never the bottleneck to begin with.

Not yet flown: the newest refinement judges whether a step actually helped only on a stable scene, and prints the ceiling's outcome against a k=1 baseline from the same view. It is in the build; no flight has exercised it yet.

If you turn it on to test: try auto at a busy orbital or planetary settlement and watch the log's settlement detail: lines for the factor and what was dropped; reduced is the more aggressive of the two and easier to see working (or not) from the cockpit.

fix.ui_quality: the cockpit interface at an honest size

New key, ships default off. Today Elite draws its own interface — cockpit side panels, target panel, menus — at the scene's render size: at HMD Quality 0.65 the panels are drawn at 0.65 scale and then stretched back up by the upscaler along with everything else, which is why panel text can look softer than the rest of the picture. fix.ui_quality = 100 or 125 asks the game to draw those panels at the size they would be at HMD Quality 1.0 or 1.25 instead, independent of what the 3D scene itself renders at.

The setting has two halves. The cockpit panels half is flown OK (build f05c84b, 16:27): live, one write per panel resize, no stand-down, sized inside the game's own panel-layout code by a patch checked against this game build (docs/ui-sizing-owner-2026-09-23.md has the traced formula). If Frontier ships a client update that changes that code, the panels fall back to the game's own size until EDVR is updated for it, and the log says so. The menu/layer half — the main menu, station services, the loading screen and the on-foot 2D screen, composited into their own layer after the upscale so their text is never smeared by DLSS or FSR — is built but not yet flown in this form. It needs fix.temporal_aa on to engage. If you turn fix.ui_quality on, please look specifically at menu and station-service text sharpness, not just the cockpit.

Not layered by design: cockpit holo panels, the flight HUD and target markers, which the game draws before its own tonemap and which stay in the reconstructed picture, steadied instead by the interface depth and hologram fixes below.

DLSS mode selection and the served floor — built, not yet flown

Two related fixes to how EDVR asks NVIDIA's DLSS for a size, neither exercised by a flight yet. A supporter's log showed DLSS refusing an input it should have been able to serve; investigation found ensureFeature's mode-selection walk queried NVIDIA's four DLSS modes in order and gave...

EDVR 0.18.0-rc.1

This is a pre-release of the 0.18 line, published for testing before 0.18.0 proper. It is not marked Latest: 0.17.0 stays the release for anyone who is not here to test. Where 0.17.0 was one large, cleanly-flown change (the native OpenXR runtime), this build is a bundle of smaller ones at different stages of proof: a station-and-hangar motion fix that is flown and judged good, a settlement frame-rate governor that is flown extensively but ships switched off, an honest-scaling fix for the cockpit interface whose panel half is flown and whose layer half is not, a cockpit hologram/radar depth fix that is flown and confirmed, and a DLSS scaling correction that is built and self-tested but has not yet been exercised by an actual flight. Each is named below as what it is, not what it is hoped to be.

Engine-truth motion at settlements: stations, hangars and walking

Object motion at settlements and stations now comes from the game's own per-frame records, not from EDVR estimating it. Elite's engine already carries an exact world transform and orientation for every object, per frame, in records EDVR did not previously read. Where the temporal pass used to infer motion for stations and ships from screen-space heuristics (the old per-object-motion.md estimates), it now takes the engine's own delta for the stock station pixel shaders, keyed one shader family at a time. Nine shader families are keyed at the station now: vs_4361/ps_1694 (547 of the station's ~1,193 instances a frame — the biggest single family, and the main source of its old rotation blur), vs_889A/ps_B46E/ps_EBA9, and the ps_CB42/ps_451A pair.

Flown and judged good, build f05c84b, 16:27 flight (HMD Quality 0.5, DLSS performance mode at exactly the floor): the station's rotation, the hangar, and on-foot movement all ran clean in the same session — no faults, no stand-downs. Both keyed station families were live and substituting (2,982 then 29,422 draws in one window; 360 then 2,206 in the other); the joined station motion measures exact to 0.002 px against the records' own 0.106-0.110 deg/frame rotation. On foot, the same flight read "frames dropped: none" across two windows (764/764 then 5,398/5,398 given, zero invalidated) — the exact metric that used to fail during walking (every source frame dropped, 2,031/2,031, because a walked scene is drawn by more than one camera; the fix holds each source draw to the camera that names it) and in a hangar (nothing used to name the source at all, because a hangar has no terrain draw; it is now named by the screen's own depth instead). Sean judged the station rotation and the hangar good ("All looks good to me now").

Not yet flown as a whole build: since that flight, the old per-object motion estimates and the legacy kinematic motion tracker — already fully superseded and unused by that point — have been deleted outright, along with several more diagnostic-only code paths. That deletion should not change what you see (the paths it removed were dead weight, not live behaviour), but no flight has yet confirmed the build with them actually gone. If station rotation, hangars or walking near settlement objects look any different from "all looks good" above, that is the regression to report.

Config keys removed with the estimates: advanced.temporal_aa_objects_reach and advanced.temporal_aa_objects_ships_metres are gone from edvr.ini — if you had either set, it is now ignored. advanced.temporal_aa_debug's movers and objects debug views are retired with them; the replacement is motion_source, which colours each pixel by where its motion actually came from (green: an engine rig record's exact delta; red: a rig record with no usable history yet; blue: the camera's own motion; yellow: a surface whose recorded depth changed after it was drawn).

Open: walking NPCs and other articulated "walker" objects are not on this path yet (they wait on a bone-palette change in a later phase) and still blur; ships in free space are also not yet covered. Neither is a regression — they were never covered by the estimates this replaces.

fix.settlement_detail: a settlement frame-rate governor, shipped switched off

New key, ships default game (off — untouched). At a busy settlement Elite draws tens of thousands of small parts a frame; when that runs the frame longer than your headset's refresh allows, auto thins the game's own level-of-detail distance beyond about 100 m and gives it back the moment the frame fits again, cockpit only (on foot the game's own detail always stands). reduced thins by the full amount at every busy settlement regardless of frame time. Sean's call for this pre-release was to ship it off by default; auto and reduced are there to opt into and everything below still holds for them.

This is the most flight-tested single change in this build — eight flights across shadow and acting modes. At the pad, parked, it held sustained 90 Hz for 90 seconds before hitting its ceiling (fixed since by raising advanced.settlement_detail_max from 4 to 6); a refinement flight found every one of its step rules firing correctly, but at the ceiling itself a quarter to a third of cycles still take two display slots at 10.1–10.7 ms mean — the wall there is now the frame's tail, not its mean, which is past what a step-based governor alone can reach. The lever is also confirmed inert at close range: near enough to a settlement, it thins draws that were never the bottleneck to begin with.

Not yet flown: the newest refinement judges whether a step actually helped only on a stable scene, and prints the ceiling's outcome against a k=1 baseline from the same view. It is in the build; no flight has exercised it yet.

If you turn it on to test: try auto at a busy orbital or planetary settlement and watch the log's settlement detail: lines for the factor and what was dropped; reduced is the more aggressive of the two and easier to see working (or not) from the cockpit.

fix.ui_quality: the cockpit interface at an honest size

New key, ships default off. Today Elite draws its own interface — cockpit side panels, target panel, menus — at the scene's render size: at HMD Quality 0.65 the panels are drawn at 0.65 scale and then stretched back up by the upscaler along with everything else, which is why panel text can look softer than the rest of the picture. fix.ui_quality = 100 or 125 asks the game to draw those panels at the size they would be at HMD Quality 1.0 or 1.25 instead, independent of what the 3D scene itself renders at.

The setting has two halves. The cockpit panels half is flown OK (build f05c84b, 16:27): live, one write per panel resize, no stand-down, sized inside the game's own panel-layout code by a patch checked against this game build (docs/ui-sizing-owner-2026-09-23.md has the traced formula). If Frontier ships a client update that changes that code, the panels fall back to the game's own size until EDVR is updated for it, and the log says so. The menu/layer half — the main menu, station services, the loading screen and the on-foot 2D screen, composited into their own layer after the upscale so their text is never smeared by DLSS or FSR — is built but not yet flown in this form. It needs fix.temporal_aa on to engage. If you turn fix.ui_quality on, please look specifically at menu and station-service text sharpness, not just the cockpit.

Not layered by design: cockpit holo panels, the flight HUD and target markers, which the game draws before its own tonemap and which stay in the reconstructed picture, steadied instead by the interface depth and hologram fixes below.

DLSS mode selection and the served floor — built, not yet flown

Two related fixes to how EDVR asks NVIDIA's DLSS for a size, neither exercised by a flight yet. A supporter's log showed DLSS refusing an input it should have been able to serve; investigation found ensureFeature's mode-selection walk queried NVIDIA's four DLSS modes in order and gave up on the first failed query, so a real answer from a later mode (performance or ultra performance) never got a chance to be tried. The fix queries and logs all four modes every time, unconditionally, and only refuses when every one of them has genuinely been asked and none holds the input. A second, unrelated drift between two ratio-selection call sites (one with an epsilon, one without) is also closed to one shared rule. tools\dlaa_mode_test carries 61 checks against this logic with no NGX SDK or GPU needed, and it is in the build gate.

Separately, the same investigation found a real gap: NVIDIA's three upper DLSS modes (quality, balanced, performance) share one floor at exactly half the output size, and ultra performance is a single point at a third — so any input between a third and a half of the output, and anything under a third, is served by no mode at all, which is exactly the shape of Sean's report that "setting HMD Quality 0.5 causes DLSS to disengage." The fix asks NVIDIA for that floor and, only when the requested input would fall in the gap, raises the pass's own output just enough that DLSS's floor covers it, letting the runtime upsample the rest.

HMD Quality 0.5 was flown and sits exactly on the floor, not under it, so that flight confirmed the floor is real but did not exercise the new fix — a 0.5 flight will look unchanged either way. HMD Quality 0.45 is the setting that actually falls into the gap and has not been flown at all. If you can test at 0.45 (or any HMD Quality under 0.5 on a DLSS/DLAA-capable card), that is the single most useful data point this pre-release could get; watch the log for a line starting dlss floor: the game's ... is under the ... floor NVIDIA names.

Cockpit holograms and the radar star icon: flown and confirmed

**Flown OK, 2026-09-24. Sean: ...

EDVR 0.17.0

0.17.0 is the release of the OpenXR backend that the three pre-releases (rc.1, rc.2, rc.3) were testing, plus everything found since. It replaces 0.16.2 as the release to install. The VR half now speaks OpenXR itself: OpenComposite is no longer part of the install, Elite's native Oculus path no longer keeps Meta headsets out, the render resolution and a field-of-view trim are set per headset, and the legacy OpenVR proxy that 0.16.2 shipped is gone from the build. Since rc.3: fix.temporal_aa = fsr is a third upscaler, the mask around navigation objects near a star (#36) is fixed, planetary terrain no longer shimmers under DLSS and costs less to fly over, weapon stability on foot is done by frame pacing instead of a shader correction, a skipped intro no longer leaves its panel fixes running on the on-foot HUD, and three FSS defects on the native path are closed. Each headset and runtime pairing below was flown on its own; none has been flown across all of them in one pass, and the things that were installed and hash-verified but never seen through a headset are named in their own section. The code in this build is what flew on the last three sessions of 2026-09-17 (development build 91d5b75); the two commits above it are documentation.

The VR half speaks OpenXR

openvr_api.dll still answers Elite's OpenVR calls, and behind them it now runs a real OpenXR session through the Khronos loader bundled beside it (Openvr\win64\openxr_loader.dll, SDK 1.1.46), instead of handing the session to OpenComposite or to SteamVR's own openvr_api.dll. Which runtime that session lands on is whatever Windows names as its Active OpenXR Runtime — SteamVR, PiOpenXR, Virtual Desktop's VDXR or Meta's — so set that selector to the runtime you mean to use before launching. SteamVR is allowed there and no longer required. The installer validates the pair, keeps the game's original openvr_api.dll as openvr_api_orig.dll for recovery (always that name now; advanced.real_openvr_dll is retired), and writes a small edvr_openxr.ini beside it naming the loader and the graphics half. There is no backend choice: the package does not fall back to a legacy EDVR pair or to Elite's LibOVR path, and the legacy proxy's code is out of the build, not just switched off. The 25 settings that only it read are ignored if your edvr.ini still carries them — fix.launch_centre; advanced.launch_centre_angle, launch_centre_max_metres, gaze_probe, gaze_probe_summary_frames, gaze_probe_pvr, compositor_timing, real_openvr_dll, suppress_interfaces, cull_guard_submit, cull_guard_channel, submit_index, waitgetposes_index, observe_projection, pose_step_note_mm, pose_hold, handover_pose_log, projection_edit; experimental.submit_snapshot, fss_theater_scale, fss_theater_curve, fss_theater_aspect, supersample_resolve, supersample_filter, supersample_width — and the graphics log names them: edvr.ini: N line(s) name settings this build does not read. No surviving setting's default changed between 0.16.2 and this build.

Flown, each on its own: Pimax Crystal Super over PiOpenXR, Pimax over SteamVR's OpenXR runtime, Quest 3 over Virtual Desktop's VDXR, Quest 3 over Air Link on Meta's runtime, and Quest 3 over SteamVR's OpenXR runtime — the rc.3 build carried sessions of 14,153, 16,137, 7,983 and 22,340 stereo pairs on those, each clean to exit — and the development builds since rc.3 have flown dozens of sessions, almost all Pimax over PiOpenXR and Quest 3 over VDXR. Other headsets and runtimes are not implied to work, and no single session has yet covered them all.

Meta headsets no longer need a workaround. Elite probes LibOVR before OpenVR, so with the Oculus software installed it took its native Oculus path and EDVR's VR half never loaded; the README's "Getting a Meta headset onto OpenVR" section is gone because the reason for it is. EDVR now refuses that one probe — the specific LibOVR load call in the game executable — so Elite takes its OpenVR path, which lands on the OpenXR session above. This is pinned to the audited Elite executable: the installer checks the executable's profile and refuses an unknown revision before writing anything, rather than installing something that would silently take the legacy route. So when Frontier ships a client update, expect this installer to refuse until a profile for the new build is published — please open an issue if it happens. Flown on a Quest 3 over Air Link: the two probe calls were refused exactly, with zero failures, and the runtime named itself Oculus. A Rift or Rift S on the native SDK has not been flown; the mechanism is the same.

If VR fails to start after an update, that is deliberate. A half-updated pair — one DLL from 0.16.2 and one from this build — refuses to start rather than running with mismatched halves; the native log carries result,native_render_settings_query,-1. The installer's Repair, or python tools\install_edvr.py --verify-only, puts it right, and the README has a section on it.

Every session starts centred on you. On the native path the world is centred once at startup, from the tracked headset, always. A further change since rc.3 — recentring the seated origin when the intro movie or splash first appears, instead of on the first tracked pose at startup, which across ten sessions had varied by 77 degrees of yaw — is built and installed but not flown.

What the runtime is told about the headset. The refresh rate — this fixed a terrain-detail stall and a hang at exit that a flight found, and the follow-up flight confirmed it gone — the IPD, and the hidden-area mask. The mask is built and installed but not yet flown for visual correctness, and no GPU saving is claimed for it: in the one flight checked, the runtime's mask had zero triangles.

The submit path does less per frame. The FSS, temporal, sharpening and menu work that ran as separate graphics callbacks per stereo pair now runs as one, six callbacks down to three, and captured scenes are drawn straight from EDVR's own context instead of being recorded and restored. That is measured on the desktop only — no in-game frame-time saving is claimed, and there is no new setting; the log's recurring native_submit_window and native_submit_phases lines are where the timing lives. fix.render_sharpness (0 to 1, default 0; 0.3 is a fair start) is applied at submit as before; flown.

The Monitor page has fewer columns on the native path. Compositor GPU time, dropped frames, reprojection and exclusive app CPU came from the compositor, and the native path has no such source, so those stay blank; advanced.app_gpu_timing = on (new, live) measures EDVR's own GPU span from the first covered render command through both submits and shows it separately. The page's own CPU and GPU per frame — a 2-second warm-up, a 30-second sample and a 2-second drain, as p50, p95 and p99, -- where there is no sample, never CPU and GPU summed — is what every frame-time figure below was read from.

Starting VR beside EDHM

rc.1 never started VR on an install with EDHM chained ([advanced] real_dll = d3d11_edhm.dll): the game ran flat, and the native log stopped at error,D3D11Device,80070005 a few lines after size,0,… and size,1,…, then module_startup,…,result=124. The cause is 3Dmigoto's own loader hook: with load_library_redirect=2 in EDHM's d3dx.ini, its LoadLibraryExW hook answers a request for System32\d3d11.dll with the d3d11.dll in the game directory — which on an EDVR install is EDVR itself. The VR half now takes the System32 module the graphics half already mapped at startup, through GetModuleHandleExW by full path, which 3Dmigoto does not hook, and the identity check stays. The native log prints device_module,route=mapped,path=C:\WINDOWS\system32\d3d11.dll just before the device is created, so an rc.1 DLL (no such line) and a redirected module (a game-directory path there) are each distinguishable from success. Flown with EDHM chained, Pimax Crystal Super over PiOpenXR: route=mapped, result=0, 1,983 stereo pairs, clean exit. Nothing else about living beside EDHM changed, and the troubleshooting page carries the rc.1 signature for anyone reading an old log.

Anti-aliasing: DLSS, DLAA, TAA, and now FSR

fix.temporal_aa now reads off, on (EDVR's own TAA), dlss and fsr. The FSR mode is AMD's FidelityFX Super Resolution 3.1.2 through a community Direct3D 11 port (MIT; its licence ships as FIDELITYFX-SDK-DX11-LICENSE.txt). It runs on any GPU, NVIDIA included, needs no runtime file (DLSS needs nvngx_dlss.dll, which the package carries), and takes the same motion vectors, depth and UI handling as DLSS does. Two new [advanced] keys, live and FSR-only: temporal_aa_fsr_reactive (default off) and temporal_aa_fsr_debug (default off). The installer's settings window hides the DLSS preset row when FSR is chosen. The log says what it did: fsr3: the context is created for eye 0 at … with the working-surface memory, and fsr3: first asked for on … initialised in … ms. Flown three times: on the Pimax at 1.6–2.1 ms per stereo pair where DLSS took about 2.9–3.6 at the same size, and on a Quest 3 twice at 1.1–1.4 ms per pair, 86–90 fps. The honest verdict from those flights: slightly better than TAA, not as good as DLSS.

**The upscaler is warmed up on th...