

mbucchia
Members-
Posts
537 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Events
Everything posted by mbucchia
-
Oh did I not mention that because it's the quad views method, it's completely agnostic of the GPU, and there's no reason it wouldn't work on AMD card too?
-
I'm still very much pissed at them for 2 things: - developer mode fiasco, hiding your features behind this very unreliable developer mode which is causing a lot of people coming to me with their issues (while it's a Meta issue) - most importantly they are the vendor in the best position to make a positive impact to the PCVR gaming industry, yet they seem to create more barriers instead of taking them down. The eye tracking data as a vendor-specific API is a great example of how you discourage developers from implementing these techs. What I'm doing with the upcoming "Meta-Foveated" project, I am not doing it for them. I am doing it to promote the streamlining of these technologies. I'm doing it because I want more developers to use these techs and implement foveated rendering in their games. I'm doing it because I think we deserve a good PCVR gaming Ecosystem. Because you deserve a delightful VR experience!! And in the process, I can say I wrote this project in 4 evenings, on a laptop, while watching garbage TV with my wife and my bunny. If I can do that, then Meta's large $$$ has no excuses to not be doing it themselves. Edit: don't get me wrong, I am not disparaging the skills and competence of Meta's engineers. I've met them and they are great. Their leadership is probably asking them to not spend resources on PCVR, which is the issue. FYI the first version will not be compatible with ASW. It looks like the Oculus runtime cannot do ASW when you submit multiple projections. I'm looking into an alternative. Edit: Taking this ASW thing back. Solved it, it will be supported Day 1.
- 750 replies
-
- 13
-
-
-
Well your disappointment would be short I hope. Due to the persistence of a certain user on my Discord (who should remain nameless ), I have implemented the quad views support extensions for Quest Pro. It is currently in final beta testing and should be released in the next few days. So far the feedback is pretty good so hopefully it will make it worth your while and also signal Meta to wake up when it comes to supporting feature on their PCVR runtime.
- 384 replies
-
- 12
-
-
-
I think we all agree the question is poorly asked. But that doesn't matter, the results speak for themselves and I think OpenVR support will be gone for good now (or rather will not be revived into MT).
-
I heard this statement too but unclear how reliable. This was posted on my Discord as a screenshot from some Pico forum I think? (Not my post) EDIT: Reverse-engineered from the screenshots: https://developer-global.pico-interactive.com/community/post/7238474317217398789 My guess is it will be based on Monado perhaps? (That's the runtime they use on Android). Monado support on Windows has not really been useful, but I keep hearing it's supposed to get massive upgrades soon. And I know of a couple of vendors currently porting their streaming solutions as Monado drivers.
-
No matter my settings, my fps and quality doesnt change
mbucchia replied to fastfed's topic in Virtual Reality
"OpenXR Tools for Windows Mixed Reality" won't do anything for an Oculus Quest. You need to uninstall that application and instead change the settings in the Oculus PC app, or use something like Oculus Tray Tools. -
See https://forum.dcs.world/topic/299598-trying-to-connect-the-individuals-that-made-the-performance-enhancement-in-vr-to-the-dcs-devs/ for getting MSFS-like DFR. That was ignored for over a year. Anyway even with that, you wouldn't be getting anywhere near the gains we are getting on Aero (where I used a completely different technique than the one I used for MSFS, which yields much much better gains). The set of features supported on Quest Pro is just very poor when it comes to implementing this stuff, and their prerequisites for enable eye tracking are super bogus. Quest Pro is obviously in my opinion not a platform that Meta wants to succeed for PCVR. Do yourself a favor and swap it for an Aero if you want to enjoy good DFR in DCS and great PCVR in all games!
-
Any reason for this unwarranted adjective? You're more than encouraged to participate to the development of the tool. It's open source. Be part of the solution, not the problem.
-
VR zoom makes CPU frame time (bad performance) better, why?
mbucchia replied to darkman222's topic in Virtual Reality
It varies from engine to engine but the most likely explanation is that there is more geometry being culled. Zooming reduces the field of view as mentioned in the post above yours, and before attempting to render anything, the engine will perform what is called a "culling pass", and it will completely remove from its list of things to draw anything that is not at all visible due to that lower field of view. Less geometry to draw will translate into less work to do on the CPU (because the CPU is responsible for enqueuing commands to the GPU for all the triangle lists to draw). It won't affect as much your GPU because in the end the same number of pixels end up being filled (can still vary due to poorly optimized z-ordering, but let's ignore that). It's all about how complex it was to assemble the geometry that produces these pixels. You can't really leverage that property to optimize things no, unless you are willing to significantly reduce your field of view (there are options to do that in SteamVR/OpenXR, though they probably produce much less gain since they won't reduce FOV as much as zooming does). -
Oculus mode (OVR) is now deprecated, and even Oculus themselves don't want developers to keep using it. I would not expect anyone in 2023 to keep writing/maintaining support for Oculus mode in their app. ED is doing the right thing here. If you have issues with OpenXR and the Oculus runtime (or perhaps Virtual Desktop), you need to report them to Oculus or to GGodin, this is the only way things can be improved. My 2c.
-
That's 100% correct yes.
-
The question in the thread is highly ambiguous because SteamVR can be used through either OpenVR or OpenXR... so anyone picking SteamVR as the answer could mean either OpenVR or OpenXR... Cc @BIGNEWY, because I feel the question is poorly asked.
-
Explanation of Pixel Density, OpenXR, super sampling and upscaling.
mbucchia replied to stottyboy's topic in Virtual Reality
"Automatic" was never what you think it is. It literally just meant "Always on" if the app was Flight Sim 2020, or Disabled otherwise. "Always on" means always on standby and ready to kick in if you drop below 90. The rate is then selected "best as possible" given the frame times. The new version 113 keeps the Disabled option, adds an Enabled (which replaces "Always on" and works exactly like it before), then adds a "Limit to X rate" if you want to force the frame rate to a given maximum. -
Explanation of Pixel Density, OpenXR, super sampling and upscaling.
mbucchia replied to stottyboy's topic in Virtual Reality
100% sure. Do you happen to perhaps have Motion Reprojection enabled through OpenXR Toolkit? That setting takes precedence over the OpenXR Tools one. That Automatic is getting removed in the newer release btw (which had been out for a few weeks already, so you shouldn't even be seeing Automatic anymore if you are on version 113). -
Explanation of Pixel Density, OpenXR, super sampling and upscaling.
mbucchia replied to stottyboy's topic in Virtual Reality
OP is on Pico 4, so these motion reprojection settings you are talking about are not applicable to them. WMR = Reverb G2 and other headsets of this family. Also, FYI the Automatic option in OpenXR Tools for WMR means "only in Flight Sim 2020". It has no effects in DCS. -
Varjo Aero: Общее руководство для новых владельцев
mbucchia replied to Supmua's topic in Virtual Reality
Can you try "plain quad views" (aka FFR) by uninstalling OpenXR-Varjo-Foveated? Alternatively you can also try modifying the OpenXR-Varjo-Foveated config file (see instructions on the website/wiki) to set no_eye_tracking=1. -
Varjo Aero: Общее руководство для новых владельцев
mbucchia replied to Supmua's topic in Virtual Reality
Like Don said this is (partially) about the "quad views" support (being able to render in 2 passes with 2 different resolutions and a moving viewport) being a Varjo feature (the "official" name of it is "XR_VARJO_quad_views"). This is a completely different technique than the one used in OpenXR Toolkit or VR perfkit, and it cannot just be "forced in" like OpenXR Toolkit FFR/DFR, it requires some fundations in the game engine which ED built. However they seem to not have finished it: a) there is a major bug in their frame management with MT (reported to them) b) they never actually enabled the DFR capability aka "XR_VARJO_foveated_rendering". This is why you need a separate tool, my "OpenXR-Varjo-Foveated" to fix a) and add the missing bits for b). Regarding other headsets support, this is in theory achievable: the OpenXR extensions mentioned above, while published by Varjo, are free of any intellectual property and can be implemented on any OpenXR platform. For example, I've added support for them into my Pimax OpenXR runtime, and they work today on older Pimax products with the add-on eye tracking module, and they _should_ work on Pimax Crystal once they release firmware with the eye tracker support. For other headsets like Quest Pro, they are some significant barriers that Meta is putting in the way (of _any developer really_): - Their eye tracking support is targeted for Avatars only (that thing that none of us gamers care about). Remember, it's the Quest "Pro" as in "Enterprise". It requires additional support efforts to be usable for something like foveated rendering. - Their eye tracker functionality is currently gated by "developer mode", a mode of the device that is unfriendly to end-users, and activating such mode has many bugs (this is why even today with OpenXR Toolkit support for DFR in some games, many users still cannot use it due to these developer mode issues). - Their compositor doesn't support a feature called "FOV mutable", which is critical in writing quad views emulation code, specifically to implement a smaller moving view port for the foveated region. Writing code to simulate that feature is complex. - The Quest Pro isn't that high-end and high resolution. In the end, because the resolution is only a fraction of what it is on Varjo, then it means the gains will also only be a fraction of the gains on Varjo. In the end the decision is a no brainer: unfriendly usage, need of significant code to fill the gaps left by Meta, and estimated too small gains make it not worth my time, for a device that is clearly not intended for gaming usage in the first place. For comparison: I considered adding support for G2 Omnicept, because at least the eye tracker works out of the box and WMR supports FOV mutable. However the lower pixel count and low adoption of this device also make it not worth my time. A comparison worth it: the initial implementation of quad views support in PimaxXR took only 2 days, and it's already showing gains comparable to what we see on Aero (and I dont even have a Pimax device with eye tracker)... my support had built-in equivalent of what my OpenXR-Varjo-Foveated mod does (the thing we asked Varjo on their Discord to offer - aka a checkbox to force use of the eye tracker with quad views even if the app isn't asking for it), so the separate program isn't even needed with Pimax. I think the Varjo implementation in their runtime will still be more polished than mine in Pimax, simply because it look like they have done some work to optimize it for their optics (something I don't really have the time/skills to do myself). Don't use force_varjo_VR and just let the game use OpenXR instead. -
With OpenXR Toolkit, do I have to disable the DCS View keys?
mbucchia replied to Snacko's topic in Virtual Reality
Because there's no Win32 API to do that universally... if you know better, please share. -
It shouldn't break other apps. There was an update "Varjo-Foveate 0.2.0" that fixes some issues with Unreal apps, but no known issue since. For OpenXR Toolkit, you can use the per-app activation/deactivation in the desktop app to disable it for a specific game. You can leave Varjo-Foveated installed while having InstanceExtensionsWrapper, the latter will disable the former. The only thing you need to truly uninstall is InstanceExtensionsWrapper. Because the way this works, it has to be inserted in a very special way (unlike the other 2). This is why it's so important that ED provides an option to disable quad views rather than this horrible hack. Or at least they need to follow OpenXR standard and query the output of `xrEnumerateViewConfigurations()`, which they seem to ignore today.
-
On Varjo, DCS forces the use of Quad Views rendering, which is incompatible with OpenXR Toolkit. You need to use Release Initial release 0.0.1 · mbucchia/OpenXR-InstanceExtensionsWrapper (github.com) if you want to force disabling Quad Views and use OpenXR Toolkit. @BIGNEWY please please please can disabling Varjo quad views just be an option of the game already? It was before OpenXR (via command line). This should be a trivial change to make. Alternatively, if you are looking for high-performance, you can ditch OpenXR Toolkit and use Home · mbucchia/Varjo-Foveated Wiki (github.com) instead to get eye-tracked foveated rendering. This is not compatible with OpenXR Toolkit, you have to choose between the two.
-
This likely means you are using SteamVR.
-
It was worth the try between the 2 modes. TBH what I have learned early on with Motion reprojection is that people will either love it or hate it. There is no seeking 100% satisfaction with it. If it doesn't work we'll for you, don't use it. I'm told that using OpenXR Toolkit or Nvidia options to limit frame rate to 1/2 (eg 45 FPS) without motion reprojection works well. Using a fractional rate like this produces more consistent frame latency and helps with smoothness. Perhaps this is something that can work better than Motion reprojection for you?
-
I suggest you try comparing with and without Nvidia Optical Flow enabled. One might be more adapted to your content than the other. You'll need to restart the game when changing that setting.
-
That's probably what's called a "deocclusion" artifacts. We can't predict what's behind your wing, so unless it's a fairly simple/repeatable pattern, you will still see a trail of bubbliness. Hopefully you are not running at 1/4 rate because that's too low of a rate to get a decent experience IMO.
-
It's not gone. You need to enable custom render scale checkbox first (same as before). We had to replace the slider with an input box due to accessibility issues. But it still works exactly the same. The Optical Flow motion reprojection is a new mode. It may or may not produce a better effect (it depends on people and games). I wrote some slightly more complete release notes on the other sim's forum: https://forums.flightsimulator.com/t/openxr-tools-for-windows-mixed-reality-update-in-the-store-4-14/586988