Jump to content

actually_fred

Members
 View Profile  See their activity

  • Posts

    175

  • Joined

  • Last visited

 Content Type 

Everything posted by actually_fred

  1. actually_fred
    SteamVR supports OpenXR, and is one of the best OpenXR runtimes - but only when used for SteamVR-native headsets, like the BigScreen Beyond and the Valve Index. It tends to have issues/overhead when the headset is *not* SteamVR-native (e.g. when SteamVR is just wrapping other software from the manufacturer like Oculus Link or WMR). Most hardware manufacturers with their own runtime have done a substantially worse job than Valve have with SteamVR - especially the smaller manufacturers - and it takes engineering time from other things that are more useful. By asking BigScreen to create/support an alternative OpenXR runtime, you're asking BigScreen to spend significantly more time on software development for no concrete benefits, and a likely worse overall result. I understand some of you may dislike SteamVR, but that doesn't mean that SteamVR is technically bad or the wrong choice for all headsets.
  2. actually_fred
    Neither of those tools are suitable for OpenXR: https://github.com/fredemmott/XRFrameTools?tab=readme-ov-file#why-should-i-use-this-instead-of-my-favorite-tool-for-non-vr-games
  3. actually_fred
    Running things as administrator is a *really* bad idea, and can *create* issues that can only practically be fixed by re-installing windows (or chasing down a lot of undocumented filesystem locations and registry keys), as it can change things that should be owned by your user to require administrator permissions. It also puts your system security at severe risk when joining multi-player servers. It can help with OBS specifically because OBS contains explicit code to try and get high priority on the GPU, which requires administrator; running *everything* as administrator will not have the same effect as: - most software does not contain the code that attempts to use the only-available-to-administrator high GPU priority - even if it did, if everything has priority, effectively nothing does - it always takes away from *somewhere* - when you run OBS as administrator and it uses that to give itself higher GPU priority, this is taking away GPU resources from other things, including DCS
  4. actually_fred
    OpenKneeboard prepares the kneeboard images in VRAM regardless of whether or not it's visible - all that showing/hiding it affects is whether or not the result (a single image which is already in VRAM) is passed on to the runtime; this is *extremely* cheap compared to everything the game (and the main openkneeboard process) is doing. If your numbers are reliable, it means either: - your system is horribly overloaded - your OpenXR runtime is terribly optimized for composition quad layers, and you should report this as a bug to your OpenXR runtime vendor > OBS If you're using Jabbah's OpenXR API layer, that must do additional work when overlays are present (i.e. when OpenKneeboard is visible); I've not looked at how well it works or how well it is optimized. This would be an alternative to 'the runtime is terribly optimized'. > Reduce amount of images in the Kneeboard to reduce VRAM. (thanks Fred for the tip) To be clear, this was not a performance tip, just a statement that images stay in VRAM in OpenKneeboard. 'use less VRAM' does not improve performance unless you are reaching 100% full VRAM. When this happens, the game will generally crash or you'll get somewhere between single-digit FPS and 'seconds per frame'
  5. actually_fred
    Please keep in mind project is still in the 'early testing' stages Download: https://github.com/fredemmott/XRFrameTools/releases/latest Documentation: https://github.com/fredemmott/XRFrameTools/blob/main/README.md Summary: Every time someone uses any framerate measurement tool that was not specifically built for OpenXR, the numbers are not accurate, and are likely misleading. That said, it's not been entirely productive for me to keep saying that without offering an alternative, so... here we are OpenXR Toolkit's numbers are accurate; I had 3 things in mind when I started making this: OpenXR Toolkit is no longer maintained, and some games are incompatible I wanted to include power management data: "GPU time is 99% of frame time" has different meaning and implications if your GPU is running at maximum performance, vs when it's throttled, e.g. for thermal management More powerful logging: the option for 'every frame'; the binary logs are logged at every frame, but you can choose how many frames go into each row when exporting to CSV I wanted 'always-on' to be a reasonable option. Currently, the binary logging consumes 104 bytes per frame, which is 26mb/hour at 72FPS, or 43mb/hour at 120fps. Download: https://github.com/fredemmott/XRFrameTools/releases/latest More information: https://github.com/fredemmott/XRFrameTools/blob/main/README.md
  6. actually_fred
    If you're able to reach 90 non-VR that's a good starting point, but: - you might not be able to at all, depending on your monitor, and driver settings (especially vsync and related technologies) - if you are able to, you won't be getting the same performance with the VR1 - it is harder to produce the same framerate in VR than non-VR - the issues you're seeing might not actually occur in VR Of course, aiming to get things working non-VR first is good - just the target ends up being somewhat arbitrary and potentially unreachable. If that's fine with you, great If you're happy to sink in more time, you could also install varjo base; skip the headset setup, then click 'analytics window', then 'simulate' - you can now launch DCS in OpenXR, inside Varjo's simulator without a headset. Won't be entirely accurate for the VR1, but is as close as you can do without a headset.
  7. actually_fred
    Tools that are not specifically made for OpenXR can not produce absolute numbers that are meaningful for framerate/interval targets: https://github.com/fredemmott/XRFrameTools/blob/main/README.md#why-should-i-use-this-instead-of-my-favorite-tool-for-non-vr-games It can show when the mirror window framerate is spiking which can correlate with XR issues, but they're measuring the wrong thing (specifically 'Present' is not part of the OpenXR frame loop - it's used to show the mirror window on the screen)
  8. actually_fred
    Sorry, I misread the trace and mislead you, I'm following up with Somnium. From the OpenXR spec > A subsequent xrWaitFrame call must block until the previous frame has been begun with xrBeginFrame and must unblock independently of the corresponding call to xrEndFrame. It looks like DCS gets into the situation I described to Toge because the VR1 runtime does not do this. In this trace xrWaitFrame with predictedDisplayTime of 12388500800 is followed by xrWaitFrame with predictedDisplayTime of 12389312800, without a begin/end frame in between. The runtime should not return from the second xrWaitFrame (12389312800) until xrBeginFrame has been called for 12388500800
  9. actually_fred
    No, OpenXR Toolkit was never strictly required for anyone, regardless of headset/runtime. Some people may have been unable to get performance they were happy with without it though. The unrelated but similarly-named "OpenXR Tools for Windows Mixed Reality" is also not theoretically required, even for people with WMR headsets -the WMR openxr runtime is installed automatically when you plugin in the headset - but if the default OpenXR runtime had changed since installation, WMR users may need it or another runtime switching tool. For non-WMR headsets, it was widely incorrectly described as mandatory on these forums and elsewhere on the internet, but it was never a good idea for non-WMR headsets - it is unnecessary and frequently misleading.
  10. actually_fred
    This is just an ultraleap dev unit (https://www.ultraleap.com/product/stereo-ir-170/) in a custom case; any improvements here need to come from either Ultraleap or Eagle Dynamics. That said, install the latest drivers for it from leap motion rather than the obsolete ones that Pimax link to.
  11. actually_fred
    VDXR over link is primarily a development tool, not intended for actual use. being able to switch between link and VD as the backend helps isolate problems: if a bug only exists with VDXR using VD, it’s likely a VD bug, if exists with both VD and link as the backend it’s probably a VDXR bug.
  12. actually_fred
    The original rift shipped with an Xbox controller and PC dongle for a start - touch controllers didn’t exist yet
  13. actually_fred
    There have never been *any* reports of Openkneeboard’s lua *ever* causing a DCS crash. If the rest of openkneeboard isn’t installed, it deals with that fine. if you’re aware of any with evidence beyond “oh there’s a mod in the log, must be that”, please report it and I’ll be happy to investigate.
  14. actually_fred
    XRNS has some issues with overlays; you might want to try reordering it to be above openkneeboard. If that doesn’t work , try disabling both, and if that works , enable one at a time. https://gitlab.com/NobiWan/xrnecksafer/-/issues/15 And https://gitlab.com/NobiWan/xrnecksafer/-/issues/16 in particular make it impossible for the combination to work fully correctly.
  15. actually_fred
    Only API layers that depend on querying what extensions are available are broken. HTCC specifically has a workaround in the latest version and works fine. Some are broken, some are not. If things are broken, turn them all off, then *try turning them all on one at a time* - they're not all vulnerable to the bug, some are.
  16. actually_fred
    Sorry, I don't use XRNS, and I'm unable to support other peoples' software.
  17. actually_fred
    Also, that link is rather outdated - there's been 4 new versions since then. Please link to https://github.com/fredemmott/OpenXR-API-Layers-GUI/releases/latest in the future instead (as the text at the top says).
  18. actually_fred
    FWIW, the tool does not automatically suggest that ordering because while it may currently be necessary, it is not technically correct, and it can have visible problems. The most likely cause for "must be on top" requirements is bugs in the layer; if ordering is required for the game to work at all (to avoid crashes, "doesn't start in VR" etc) rather than just for 'correctness', this is especially likely to indicate a bug. For these kinds of API layers that change how your real-world movement affects in-game movement, the 'correct' ordering is: The game itself (not part of the list) Any other API layer API layers that *modify* what your hardware reports the state of your real-world input is, e.g. XRNS and XRMC API layers that are hardware drivers (e.g. the ultraleap driver) The runtime (not part of the list) Using XRNS make it 'as if' you moved your head more - so - again in theory - it should be as close to the driver that reports 'you moved your head this much as possible'. In a correctly functioning world, the only difference layer order would have (other than the 'driver' kind like ultraleap) is "what parts of the stack are affected?" - for example, combined with OpenKneeboard, OpenKneeboard would either be locked to the real world (i.e. your room), or to the game world (i.e. your in-game rendered cockpit) depending on how it was ordered. Generally you want it anchored to the game world, so 'after openkneeboard' is theoretically correct outside of niche cases.
  19. actually_fred
    To clarify this, while it would be great for ED to do this, it would be even better for the various other OpenXR runtimes (from Meta, Valve, Virtual Desktop etc) to implement the quad views/stereo-with-foveated-inset extensions. Despite that, IMO it would still be a good thing for ED to do until (if?) support becomes widespread as: - for users, it doesn't depend on their runtime vendor doing it, with no timeline for vendors - for ED, it means that the performance benefits are available to all of their users, rather than offering different combinations of features/performance depending on the headset vendor, or potentially offering different instructions for each runtime vendor. This potentially reduces support and testing costs and time.
  20. actually_fred
    DCS natively implements foveated rendering using the OpenXR quad views extension; however, something else must provide support for that extension/technology. The quad views API layer is one option, as is Varjo's own runtime, along with mbucchia's varjo-foveated runtime. There are a few caveats with DCS's use of the quad views extension: the original bug which mbucchia detailed above and over a year ago: the FOV submission is incorrect. This is worked-around (not fixed, just a band-aid) either by varjo-foveated or the quad-views-foveated API layer. It is a bug in DCS and should be fixed by ED. it depends on something else (the OpenXR runtime, or another API layer) supporting quad views (two per eye) and turning it into the usual 'two views' - one per eye. This is done by the varjo OpenXR runtime, or by the quad-views-foveated API layer. Other runtimes may end up supporting it without the layer in the future, especially it's no-longer considered a vendor extension in OpenXR 1.1 (renamed to 'STEREO_WITH_FOVEATED_INSET') - though it remains an optional part that vendors do not have to support. This is not a bug in DCS, but implementing quad views on runtimes that don't have their own support would be a nice feature for ED to implement, and would make the massive performance gains more accessible for non-expert users Varjo-specific: it only uses Quad Views for fixed foveated rendering; from a code perspective, it is trivial to turn this into dynamic foveated rendering via XR_VARJO_foveated_rendering - mbucchia's varjo-foveated and quad-views-foveated projects do this, and DCS (until this patch) work fine with it. This is - for now - specific to Varjo. If other vendors implement STEREO_WITH_FOVEATED_INSET, the standard does not require that it is or is not eye-tracked, but if the hardware supports it, it seems more likely than not that vendors would implement it as eye-tracked. Varjo chose to require a separate opt-in for eye-tracked quad views instead of FFR quad-views, however this has always been clearly documented along with quad views itself. Not technically a 'bug' in DCS: it is either an intentional choice, or an oversight - but IMO really should be changed by ED - it is extremely straightforward to do, and DFR is a huge improvement over FFR. The Varjo runtime is performing in the way that DCS asks it to, as documented. That said - as mbucchia pointed out - even a trivial code fix can still be a complicated change to make when considering non-code factors, such as testing, release management, etc.
  21. actually_fred
    On 6.4.6-2 (-1 is no longer available for download), it shows up if you selected it on an earlier version, but vanishes from the menu the moment you change it to something else:
  22. actually_fred
    Perhaps it keeps the setting if you turned it on in an earlier version of the driver? They have completely removed the option for 'application-defined' tablet versions in recent versions, and they've confirmed it was intentional. It can't be set in the app, which makes it impossible to add the bindings in OpenKneeboard. Pen buttons may still work. I'm fairly likely to remove wintab support in a future version and require OpenTabletDriver: currently *no* manufacturer has a 'good' driver, and one manufacturer has a driver that reliably crashes unless the app uses a specific version of .net (neither DCS nor OpenKneeboard use .net at all). If I do this, I'll probably make an OpenTabletDriver plugin to actively block wintab, so that both drivers can be installed at the same time for people who actually do drawing with their drawing tablet
  23. actually_fred
    Clarifying from discord: this is absolutely not a requirement of HTCC. XR_NeckSafer currently must be above HTCC for an unknown reason. The tool does not aim to put HTCC at/near the bottom, it just aims to put XRNS higher than it.
  24. actually_fred
    Virtual Desktop works; I've just updated https://htcc.fredemmott.com/hardware/oculus-hand-tracking/README.html#virtual-desktop
  25. actually_fred
    Usually QVFR will help (a lot!) if you have spare CPU but your GPU is maxed out, but it will hurt if you don't have spare CPU. VRS (like in OpenXR Toolkit) has smaller savings, but also smaller costs.
×
×
  • Create New...