Jump to content

mbucchia

Members
  • Posts

    414
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by mbucchia

  1. My best guess is you have something else interfering, we know things like Ultraleap cause issues with DCS/OpenXR, there's probably more. I'd recommend you install OpenXR Explorer and inspect the list of API layers (center column, bottom part).
  2. You're going to have to elaborate. With my thing, you should never see "Oculus" anywhere, so you probably re-enabled Oculus OpenXR after install. You can take a look at the log file under `%LocalAppData%\virtualdesktop-openxr` for clues. Given that this method has been working for others, it's likely that your issue wasn't OpenXR in the first place, but perhaps something completely different.
  3. I haven't looked at why the Oculus software doesn't work. My recommendation goes to using Virtual Desktop, which is significantly more powerful than Oculus Link (and yes, you can get awesome results without a cable).
  4. You want to run the game in OpenXR mode, so that is either ST with `--force_OpenXR` or MT without modifiers. Note that when using the Steam edition, running MT has to be done from Steam itself, and running the exe from bin-mt directly doesn't actually pickup the MT version. If you were using other OpenXR mods such as OpenXR Toolkit, you might want to clear their settings or disable them temporarily until you get a baseline going.
  5. I wasn't going to release this, but given that this crap show has been going on for too long now (and the cat has been out of the bag on reddit), here is an alternative OpenXR implementation for Oculus Link (air or cable) that currently works without issues with DCS: https://github.com/mbucchia/VirtualDesktop-OpenXR/releases/tag/1.0.3 This is the same implementation users of Virtual Desktop have been able to enjoy for a while now, except you can use it without Virtual Desktop. It comes as-is with no extended support. All you need to do is run the installer and you will be all set. Check out the instructions in the link to also switch back and forth between this and other OpenXR runtimes if needed. I will still recommend to you all to consider Virtual Desktop, which is a much better experience that Oculus Link. But if you resist, well you can try the workaround above with Oculus Link. Hope it will help a few. PS: Cheers to @MoleUK who's been testing it with DCS and reporting success.
  6. Oculus (OVR) isn't OpenXR, so none of your OpenXR mods will work in this configuration.
  7. It's a trade-off really. Quad views can immensely help with GPU performance, but at high cost on the CPU. This cost is due to DCS engine rendering technique being heavy on the CPU. VRS-based solutions (OpenXR Toolkit/vrperfkit/Pimax Foveated rendering) only have the potential to moderately help on the GPU, and at no cost on the CPU. So bottom line is if you have a lot of CPU headroom, Quad views will likely be a better solution for you, especially at high resolution.
  8. AFAIK it works just fine with Oculus as long as you meet the following requirements: - Use OpenXR in DCS, with the Oculus OpenXR runtime (not SteamVR) - Enable Meta developer mode. You will need to create a Meta developer account and enable developer mode through all 3 of the following: headset setting, phone app setting and PC app setting - Select Hand controller in the VR settings of DCS It's a bit of a pain in the a... in particular the steps to enable developer mode.
  9. Thanks! I haven't worked on WMR for months now, I've been moved to a completely different team a while ago. So this has no impact on me. AFAIK no one is impacted employment-wise.
  10. You can try VRS today with DX11 and OpenXR Toolkit (disable quad views first). You will see that it doesn't help that much in DCS (maybe 1ms or 2ms gain). This is without eye tracking, but that part doesn't matter. I wouldn't expect it to do any better with Vulkan. The ways quad views saves on rendering is unbeatable by VRS. It saves at all stages of rasterization, especially saving a lot of memory bandwidth. VRS doesn't save you anything there. But the overhead of quad views is added CPU usage, which can be solved in the game engine by doing the proper optimizations (stereo instanced rendering), which AFAIK DCS doesn't do.
  11. I might do that yes. For the sake of showing that this is how it needs to be done. Will depend on how much time I find.
  12. Since 2.9, DCS uses hand tracking via the OpenXR XR_EXT_hand_tracking cross-vendor API, so it looks to me like the request has been fulfilled. You have to enable it through the VR settings menu.
  13. There's a big misunderstanding regarding what is done/what needs to be done. Please see my detailed explanation in the other thread. For short: the ball isn't really in ED'S court for the biggest blocking things (point 3 in my comment). Those graphic issues aren't related to my implementation, they are bugs in the (existing) quad views support in DCS. They've been reported to ED many times now. I believe the NVG issue was finally fixed in 2.9, but other issues are still present. Unless you are a Varjo owner (and use Quad-Views-Foveated's older sibling Varjo-Foveated), it will not work with Vulkan, at all. This isn't really something that would be on ED to fix (see my first point). The easiest solution for ED to make it work would be to do their drawing in Vulkan and then to submit with DX11, this is what X-Plane 12 does (they don't have QV support, but they have Vulkan support). This won't cost any perfomance, and it will resolve compatibility issues such as working with WMR OpenXR runtime and QVFR for example. Game developers shouldn't have to do this, this is again all a result of platform vendors shortcomings (see first point about 3) in other comment).
  14. Let me clarify a few things, because right now you are asking the wrong things, to the wrong people, in the wrong order. Let's start with the basics: DCS does implement quad views rendering in their engine. So the title of this thread isn't going to make sense to any one looking at it. My guess is that Eagle Dynamics added support for it in order to enable Bionic Display on Varjo's VR-3 and XR-3 high-end professional headsets. Quad views rendering is the only option today that Varjo offers to enable Bionic Display. Now here are the 3 issues that need to be addressed 1) DCS only implements the Bionic Display flavor of quad views, which is by nature fixed foveated rendering, because the extra video panel in the Bionic Display is fixed (it does not move with your eyes, that would require absolutely crazy mechanical tech). Now this fixed foveated rendering does not help too much with performance, because it is set up specifically for the Bionic Display usage, where the high density panel is fairly large. So in order to make a performance boost in DCS, we want to use dynamic foveated rendering with quad views. However Eagle Dynamics did not implement that. This is what my original Varjo-Foveated mod did: it forces the eye tracking capability into DCS' implementation of quad views in order to achieve dynamic foveated rendering. So ask number 1 to Eagle Dynamics is: can you implement the dynamic foveated rendering flavor of quad views in DCS? This is a very simple change to make. Stated in technical terms: Can you add support for XR_VARJO_foveated_rendering? It's really simple, all you need to do is add a couple of extra flags when initializing the OpenXR instance, the querying the resolution for your swapchains, and querying the view pose/FOV for rendering at each frame. 2) DCS implementation of quad views has bugs. In particular, related to the addition of dynamic foveated rendering above, there is a bug in DCS MT version where data from the next/previous frame is being incorrectly used for the current frame. Because of this bug, the foveated region cannot work properly when eye tracking is used, because the region ends up being warped out of place when you move your eyes. I implemented a workaround to this issue in both Varjo-Foveated and Quad-Views-Foveated. This bug was reported to @BIGNEWY on March 18th in the post linked below, with a very detailed explanation including a detailed trace log. Actually both 1) and 2) were logged in that post back in March. So ask number 2 to Eagle Dynamics is to fix this bug with XrFovf submission in order to make their implementation of quad views compatible with XR_VARJO_foveated_rendering. 3) Quad views support is currently only implemented by Varjo in their OpenXR runtime. The quad views technique and OpenXR extensions were coined by Varjo and as a result, only they had stakes to implement it in their platforms. This means that Valve, Meta, etc do not bother implementing support for quad views applications. So even when an application like DCS implements quad views, these vendors will not be able to run the application in quad views mode. This limitation is not on Eagle Dynamics, and there is nothing they can do about it. This is why I developed my second mod, Quad-Views-Foveated, and if you read closely the description of it, it doesn't talk at all about adding anything into the application: What does that mean? It means that Quad-Views-Foveated does not fill a gap in the application (DCS), but instead it fills a gap in the platform (Oculus, Pimax, etc...). Yes, Eagle Dynamics could pull in the entire quad views on top of stereo emulation framework that I created, but it's way outside of the scope of what any normal game engine should do and I would not expect (or even encourage) any game developer to do that. In addition, there are many challenges linked to eye tracking, because just like Meta, Valve, etc did not implement quad views support in their OpenXR runtimes, they also did not implement eye tracking support in them. Only Varjo implements the proper OpenXR interface for eye tracking (XR_EXT_eye_gaze_interaction). Meta chose to only expose social eye tracking data through a proprietary extension in Developer Mode only and recently Steam Link also only forwards eye tracking via a non-standard OSC interface. This is what a 3rd project of mine, OpenXR-Eye-Trackers, aimed at fixing. This is a complete nightmare for any game developer to have to deal with this mess and they really don't have to put up with it. It's not Eagle Dyamics you need to ask the feature to: it's Meta, Valve, Pimax, etc. instead. They are the ones who need to build support for XR_VARJO_quad_views and XR_VARJO_foveated_rendering into their platforms. Summary - Eagle Dynamics, please resolve issue 1) and 2) described above in order to offer an implementation of dynamic foveated rendering that can work out-of-the-box on platforms like Varjo and Somnium. Resolving these two issues is a very small matter than could be achieved with little effort. - Meta, Valve and other major platform vendors, please provide support for quad views configuration type out-of-the-box in your PC runtimes. Only by having major vendors with mass volume of users supporting the technology out-of-the-box we will encourage developers like Eagle Dynamics and others to provide support for this great technology that really benefits the end users. Until all vendors align with providing quad views support in their OpenXR runtimes, I am afraid my Quad-Views-Foveated mod is going to remain the only way to do dynamic foveated rendering in DCS for Quest Pro, Reverb G2 Omnicept and Pimax Crystal users, and this is not a problem Eagle Dynamics can fix.
  15. Who said SteamVR could not support any form of dynamic foveated rendering though? Just like every platform, SteamVR doesn't support it out of the box, but it's achievable with my tools. The problem is just the many combinations possible. DCS MT + SteamVR OpenXR + OpenXR-Eye-Trackers + Quad-Views-Foveated will give you DFR in DCS with Steam Link. Many other combinations work, see the QVFR wiki for the details: Home · mbucchia/Quad-Views-Foveated Wiki (github.com) I've highlighted below 7 combinations where you can do DFR with SteamVR OpenXR. How do we fix this? Because it's way too freaking complicated for users to know what combination of 3rd party tools they need. We need all vendors to provide these as base features that do not require 3rd party tools. We need Meta and Valve to support the cross-vendor eye tracking APIs and quad views configuration type out of the box. So far, in this whole industry, only Varjo implements what is needed out of the box. Soon Somnium will do too (allegedly).
  16. No, this isn't foveated rendering. Steam Link is doing foveated encoding (also known as foveated compression or foveated transport). Foveated encoding only affects the image compression before sending it to the headset. It does not have any impact at all on performance (which is the whole point of foveated rendering). PS: Note that by default, SteamVR does not pass the eye tracking data to the application in a way that it can be used. So QVFR will not be able to use the eye tracking from Steam Link. In order to fix that, you must download the latest version of OpenXR-Eye-Trackers (which is something you install along with QVFR, not a replacement) and follow the instructions to enable Steam Link eye tracking forwarding.
  17. The way settings are done between Varjo-Foveated and Quad-Views-Foveated is much different (this is because of Varjo's odd way to manage resolutions via their PPD settings, which have different meaning in stereo mode than in Quad views mode). So you likely ran Quad-Views-Foveated with lower settings than Varjo-Foveated. If you want to keep things simpler, Varjo-Foveated is definitely the way to go on a Varjo headset.
  18. It definitely works as explained (ie QVFR needed for OpenXR Toolkit). Sadly, there is a bug in the Varjo software that makes eye tracking not always working with QVFR. Not something I can fix. You can try and see if you are subject to this bug (it seems to randomly affect certain users).
  19. Report this bug to ED. This isn't something I can fix/comment on.
  20. These are the same path. %LocalAppData% is an alias to your user folders AppData\Local. When you type %LocalAppData% in your file explorer, it will take you to that exact same location.
  21. Virtual Desktop with VDXR support is now out of beta and live for everyone, without additional steps to install. Version is 1.29.7.
×
×
  • Create New...