Jump to content

actually_fred

Members
 View Profile  See their activity

  • Posts

    166

  • Joined

  • Last visited

 Content Type 

Posts posted by actually_fred

    Is OpenXR toolkit still necessary?

    in Virtual Reality

    Posted

    On 10/22/2024 at 3:14 PM, slughead said:

    the OpenXR Toolkit isn't necessary—was it ever?

     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.

    • Like 1

    *** PRICE DROP *** Slugmouse - a mouse button emulator for hand-tracked cockpit clicking.

    in Virtual Reality

    Posted

    On 8/23/2024 at 3:56 AM, slughead said:

    I'm sorry to hear about the Pimax HTM. You guys need to push Pimax hard on this to get a resolution. An offer to help them test changes may go a long way.

    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.

    recent meta link software update (NON PTC) and DCS is constantly crashing when startup

    in Virtual Reality

    Posted · Edited by actually_fred

    On 7/30/2024 at 9:55 AM, slughead said:

     HTCC, or any third-party OpenXR layer tool, disable them. They're not compatible with Meta Link v68 anymore due to Meta's changes

    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.

    XR Neck Safer not working?

    in Virtual Reality

    Posted

    20 hours ago, speed-of-heat said:

    a couple of things one , make sure the api order is correct XRNeck safer should be first (top) in this tool Release v2024.01.17 · fredemmott/OpenXR-API-Layers-GUI (github.com)

    second if you are some how using steam VR as an OPenXR provider then XRNecksafer will not work 

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

    • Like 1
    • Thanks 1

    XR Neck Safer not working?

    in Virtual Reality

    Posted · Edited by 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:

    1. The game itself (not part of the list)
    2. Any other API layer
    3. API layers that *modify* what your hardware reports the state of your real-world input is, e.g. XRNS and XRMC
    4. API layers that are hardware drivers (e.g. the ultraleap driver)
    5. 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.

    • Thanks 1

    2.9.6 quad views foveated Varjo Aero issue under 90fps

    in VR Bugs

    Posted · Edited by actually_fred
    Clarify who 'other OpenXR runtimes' means

    2 hours ago, actually_fred said:

    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

    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.

    • Like 2
    • Thanks 1

    2.9.6 quad views foveated Varjo Aero issue under 90fps

    in VR Bugs

    Posted · Edited by actually_fred

    3 hours ago, nilpointer said:

    Unless I'm missing something, which I'm confident I'm not an even bigger ticking time bomb is that foveated rendering and eye tracking are not natively implemented by DCS. Not only have the many users of supporting headsets become reliant on @mbucchia to provide the high level of goodwill he already has, but should there ever be some additional change that renders QVF unusable we're back at square one.

    I love DCS but have also grown weary of the dice roll of it working between patches on the thousands upon thousands of dollars of hardware.

    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.

    • Like 3
    • Thanks 1

    HTCC & Openkneeboard Conflicting

    in Virtual Reality

    Posted · Edited by 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 😛

    HTCC & Openkneeboard Conflicting

    in Virtual Reality

    Posted

    On 5/29/2024 at 4:13 AM, Maddaawg said:

    it flagged HTCC as needing to move to the bottom

    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.

    Is Motion Reprojection basically a reqmt these days?

    in Virtual Reality

    Posted

    On 4/26/2024 at 7:06 AM, average_pilot said:

    The OpenXR Toolkit gives you fixed foveated rendering that helps quite a lot with performance while keeping a rather high resolution, of course in exchange of visual quality. The other type, QVFR, doesn't give me any extra performance but rather a performance hit.

    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.

    Is it just me or is Quest 3 complete crap?

    in Virtual Reality

    Posted

    Yeah; their hardware is good, excellent value, and link/airlink are great - better than VD for me - when they work.

    On the other hand, Oculus frequently push out updates that break Link/AirLink features I depend on, or just break it entirely. I still use them when I can, but I also regularly use virtual desktop as a backup when link is broken yet again. 

    Mixed reality

    in Virtual Reality

    Posted

    On 2/14/2024 at 6:02 AM, zetikka said:

    Playing these days with MR on DCS, using Meta Quest 3 + Virtual Desktop + Openkneeboard on the DCS OpenBeta (OpenXR). Seems promising (very early stages of testing):
     

    Note that Openkneeboard was test to auto switch on/off depending on the area I looked at, it explains why the MR grid goes on and off.
     

    Main limitation at this point is that you can only open a single-plane chroma compositing window for passthrough video, while (in this case) Hornet's cockpit displays are at multiple focal planes, which results is paralaxing on the VR zones I left for MDF/UFC retention.  

     

    This is a hardware limitation; with the possible exception of the Varjo XR4 (the advertising material is... advertising material, not clear functional descriptions), no generally available headset is capable of rendering anything at multiple focal planes.

    XrResult failure [SOLVED]

    in Virtual Reality

    Posted

    2 hours ago, Gregkar said:

    Link is dead, do you know if i can find it anywhere else? did the mistake to uninstall my working version and update to the latest one and then i got the OpenXR issue described above

    They seem to be moving stuff around a lot; googling for "leap motion download old versions of gemini" gets you a few links to pages with it.

    Common OpenXR misconceptions

    in Virtual Reality

    Posted · Edited by actually_fred
    Added OpenXR Toolkit != OpenXR

    Most of the replies in help threads contain factually incorrect advice, which makes setting up VR more confusing for everyone. I'm going to address a few common ones:

    - SteamVR + OpenXR: SteamVR supports OpenXR (it's an "OpenXR runtime") - if you want to use SteamVR + DCS, you want to start by setting SteamVR as your OpenXR runtime. You do not want to 'disable OpenXR' to use SteamVR, unless for some very rare reason you specifically want to use OpenVR. If you do this, no games that require OpenXR will work unless you change your settings back.
    - "OpenXR Tools for Windows Mixed Reality" is specifically for Windows Mixed Reality headsets. If you have a quest, rift, pimax, varjo, beyond, or any other non-WMR headset, do not install this software, and especially do not click the button to set WMR as your OpenXR runtime. If the tutorial you're watching or the guide or reading says to do this and doesn't say "just for G2" or "just for WMR", find a better guide. If you just want to see information on openxr, https://github.com/maluoi/openxr-explorer/releases/latest is a better tool, in combination with https://github.com/fredemmott/OpenXR-API-Layers-GUI/releases/latest if you have several OpenXR API layers (roughly 'plugins') installed*. 
    - "OpenXR Toolkit" is not the same thing as "OpenXR Tools for Windows Mixed Reality"
    - "OpenXR Toolkit" is not the same thing as "OpenXR"
    - "OpenXR Toolkit" is never required. It's a great tool, install it if there's a specific reason you want it, but it's not necessary.
    - "Set WMR/your headset/SteamVR to OpenXR": this is the wrong way around and can confuse people: "Set OpenXR to SteamVR/WMR/your headset" is correct. It's a single OpenXR setting for all OpenXR hardware manufacturers and games - you are changing if OpenXR games use WMR, oculus, steamvr, or whatever, not a headset setting. Specifically these buttons in steamvr/wmr/manufacturer-specific stuff all change `HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenXR\1\ActiveRuntime`
      - SteamVR can simultaneously be your selected OpenVR and OpenXR runtime. Games will only use one at a time.
      - If WMR is set as your OpenXR runtime, your G2 can be used by openxr *or* steamvr-via-openvr *or* classic (deprecated) Windows Holographic *or* opencomposite-via-openvr* without any settings changes. Games will only use one at a time.
      - If Oculus is set as your OpenXR runtime, your quest/rift can be used by openxr, *or* steamvr-via-openvr *or* opencomposite-via-openvr *or* the classic (deprecated) libovr without any settings changes. Games will only use one at a time.
      - If you need to change your OpenXR runtime and the buttons in the various vendor-specific tools aren't doing what you want, https://github.com/rpavlik/xr-picker/releases/latest is a good tool

    * OpenXR-API-Layers-GUI can also be used to fix issues, but I'm recommending it here because layer (plugin) order matters, and the current version of OpenXR-Explorer sorts them alphabetically - this means that OpenXR-Explorer is not currently useful for troubleshooting API layer issues. This should be fixed in the next version of OpenXR-Explorer.

    • Like 4
    • Thanks 1

    Fingers - Leap hand tracking and physical switches for VR and others

    in PC Hardware and Related Software

    Posted · Edited by actually_fred

    2 hours ago, tomeye said:

    Did you modify the scale inside the files CoreMods\characters\models\glove_L.chanimgpu and glove_R.chanimgpu as per https://htcc.fredemmott.com/games/dcs-world/README.html ?

    > If using controller emulation

    That change is unneeded and has no effect when using touch screen/tablet emulation. If it has an effect with HTCC, you're using oculus touch controller emulation, which will not work correctly with this ring; it would need new firmware, and some changes to HTCC. I'm interested, but hoping to find a supplier for the batteries that can deliver to the US faster than March 😛

    Following Procedures While in VR

    in DCS: F-14A & B

    Posted

    The easiest way to deal with that would probably be to add them to an aircraft tab's folder in saved games - you can see the paths it looks for those in the tab settings. If there's an X by the one in saved games, that just means that it doesn't exist yet, and you can create it if you want to.

    I'm probably going to add some level of lua scriptability at some point; this would include fully-lua-defined tabs, but I probably will also add 'lua-assisted' tabs - e.g. a folder tab where you can write lua code that changes which folders it's looking for based on which aircraft you're flying.

    I could also add 'custom prefix' to aircraft/terrain, e.g. "My Documents\Controls\<aircraft>", though this might be a bit too niche to be worthwhile, especially once it's possible with lua scripting.

    Might also add JS scripting - it's my preference, but OpenKneeboard already deals with some lua, and it fits better with the current DCS modding community.

    • Like 1
×
×
  • Create New...