Jump to content

mbucchia

Members
  • Posts

    535
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by mbucchia

  1. One could try today and look at the log file to confirm. The Quest user presence bug is some more Meta incompetence. I reported this specific problem to them. Again, they have no interest in PCVR.
  2. I replied in the other thread.
  3. Maybe they changed something after 2.9? It definitely did not work in 2023 and beginning of 2024. DCS uses (used?) the assumption that if the XR_VARJO_quad_views extension was present, it would use quad views, while the proper check is to use xrEnumerateViewConfiguration(). It is impossible for an API layer to mask an extension. Here was my original report of the issue to ED: https://forum.dcs.world/topic/317990-openxr-toolkit-with-new-dcs-release-not-working/#findComment-5138959 This used to cause a significant headache for Varjo users (even before QVFR for other headsets was a thing) and a special software had to be developed to mask the OpenXR extension in order to use OpenXR Toolkit.
  4. None of my tools are supported. Supported means = I monitor the community for bugs and requests and take actions for them. Many new apps do not work with OpenXR Toolkit and I have no plans to fix it. But AFAICT there are no known issues with DCS at this time for either OpenXR Toolkit and QVFR. To be clear, Turbo Mode is a feature that bypasses poor frame management that nearly all vendors are victim of (except PimaxXR/VDXR for obvious reasons). Things like Meta not delivering proper PCVR support for several years now as they are focused exclusively on standalone, MR and do not care the least for PCVR. I believe the Turbo Mode feature _should_ work through QVFR even if Quad Views is disabled via the DCS settings. As for the "unadvertise" it never worked with DCS because DCS never actually followed the proper OpenXR usage for detecting quad views platform support.
  5. I'm not working on any code anymore. That project was nearly completed but will never be released.
  6. I've always been posting here and there. I'll update the documentation, but won't be working on any code.
  7. Thanks. What does the eye tracking option does?
  8. The guide is now a little out of date. Could someone do me a favor and send me a screenshot of the setting in DCS to enable QV? I will amend the wiki guide with it. Thanks!
  9. ......... No, you were not [using DCS with FR for months with your AMD 6900XT]. AMD doesn't support VRS (OpenXR Toolkit foveated rendering) with D3D11, which is what DCS uses. It never has and never will, this is a limitation of AMD drivers. You must be confused out of your mind if you think it ever worked. Maybe you switched from Nvidia to AMD at some point? You are seeing foveated rendering option in MSFS because you are using D3D12 in MSFS. https://mbucchia.github.io/OpenXR-Toolkit/#supported-graphics-cards
  10. There are 2 conditional steps to OpenXR Toolkit showing the FR option: - absence of the "foveated rendering killswitch setting" which would have been reset by clearing the registry - failure to initialize NvAPI (part of Nvidia driver) or NvAPI returning that VRS isn't supported on your card. For the latter, I don't really know what can cause that. You said it still works in another game which is ever more confusing. The only other time someone had this problem, this was caused by their Nvidia driver. I think they did DDU etc to cleanly reinstall it. But I think they were seeing this problem with all games, not just one. Perhaps you replaced some DLLS in the sim and that interferes with NvAPI, so maybe a clean reinstall of the sim (making sure to delete the game folder!).
  11. Many people don't do this step correctly, like forget to confirm the restore to defaults, or forget to leave safe mode. So I'd recommend to try that again. Alternative is to delete registry entries by hand, both HKEY_LOCAL_MACHINE\Software\OpenXR_Toolkit and HKEY_CURRENT_USER\Software\OpenXR_Toolkit.
  12. This is the correct answer. The hold up for better integration and streamlining of this tech is Meta and their OpenXR runtime that doesn't support some of the most basic features on PC, like fovMutable or XR_EXT_eye_gaze_interaction. Meta has been slowly killing PCVR, and in 2024, they finally managed to destroy the OpenXR ecosystem and make sure that developers have no easy to craft efficient and portable PCVR applications. Thanks Meta!
  13. BTW I was _not_ referring to your post as misinformation, but rather other posts I read elsewhere!
  14. I'm pretty sure that already exists. There is an IPD slider in Pimax Play, that should basically do the same thing as world scale. Give it a try.
  15. No display in the HMD when quad views is enabled in the runtime is almost always the sign of an incompatible API layer. If not OpenXR Toolkit, then it's another one, I think OXRMC, OBSMirror also will cause this. Double check using the API layer tool from Fred Emmott.
  16. Yes. QVFR included built-in CAS, so there was no need for OXRTK. I believe the Pimax implementation is the same (looking last night, they are simply using my code). Might need to confirm with them.
  17. Here is a series of diagrams explaining things: null
  18. See my explanation there as to why you are seeing the black screen: Please, don't listen to this. He doesn't understand the technical aspect of it. See my explanation above.
  19. OpenXR Toolkit was never compatible with quad views in general. It "worked" when using quad views implemented as an API layer, because that allowed OpenXR Toolkit to see stereo instead of quad views. Doing that is impossible when using quad views implemented inside the OpenXR runtime directly. The only way to have quad views and OpenXR Toolkit at the same time is to use the quad views API layer instead of the implementation inside the OpenXR runtime. I also highly recommend to stop using OpenXR Toolkit in general.
  20. My best bet is you have OpenXR Toolkit installed, and Pimax enabled quad views by default. OpenXR Toolkit + quad views at runtime level => black screen, not supported.
  21. I doubt it will make a difference performance-wise. There's very little overhead in PimaxXR and QVFR.
  22. Hey, just to be clear, I am not involved in this development. This is all Pimax. I have retired from VR development entirely.
  23. Try inspecting your log file: https://github.com/mbucchia/Quad-Views-Foveated/wiki/Troubleshooting The whole idea of foveated rendering with eye tracking is that you shouldn't notice it. So maybe you're not having any issues and everything is actually working as expected. You can also use some of the advanced debugging options to really confirm: https://github.com/mbucchia/Quad-Views-Foveated/wiki/Advanced-Configuration#options-for-advanced-debugging
  24. 90% of VR content is still OpenVR. If they had not implemented a SteamVR driver, you would not be able to run this 90% of games. By implementing a SteamVR driver, you automatically get support for both OpenVR and OpenXR applications. It's the most economical way of developing a headset. Most vendors only care to develop their own OpenXR runtime when they have unique features that SteamVR won't support, like hand, eye, face tracking. They don't look at the "SteamVR performance" picture.
  25. That's a question I've looked into. It's a similar question that I look into a while ago w.r.t other headsets with only SteamVR drivers. Possible: Yes Difficult: Yes Hopeful: No Sony isn't releasing any proper developer SDK. The only driver that exists is the one in SteamVR. To make this driver work _without_ SteamVR, one would need to write a SteamVR Driver adapter, which would need to implement parts of the SteamVR Driver API to talk to the driver and pretend to be SteamVR. The adapter could then expose itself as an Oculus Quest for example, and plug into VDXR that way. Looking into the guts of the driver, you can see that the following SteamVR Driver API interfaces are used: IVRSettings_003, ITrackedDeviceServerDriver_005, IVRDisplayComponent_003, IVRDriverDirectModeComponent_008, IVRCameraComponent_003, IServerTrackedDeviceProvider_004, IVRWatchdogProvider_001, IVRCompositorPluginProvider_001, IVRDriverLog_001, IVRServerDriverHost_006,IVRCompositorDriverHost_001, IVRWatchdogHost_002, IVRVirtualDisplay_002, IVRResources_001, IVRDriverManager_001, IVRProperties_001, IVRDriverInput_003 Not all of these need to be fully implemented, but at least partially mocked (think like what OpenComposite does for the OpenVR API) to fool Sony's driver sufficiently. On top of that, there's a few compositor features that would need to replicate the behavior or SteamVR's compositor and which don't exist today outside of it or inside Sony's driver (eg: quad layer (not views!) rendering). There's probably over 100-200 hours of work (for a dev knowing that they are doing) to make this happen reliably. All of that for a headset that doesn't even support eye tracking which personally doesn't motivate me to go and do all this work.
×
×
  • Create New...