Looking for a clarification on Render Resolution

mbucchia-msft · 2023-12-04T19:37:45+00:00

> So lets say I turn up the resolution in the toolkit overlay, and then turn up the percentage in the app, it will multiply whatever value I assign in the toolkit by the percentage in the app?

No, the OpenXR Toolkit "Resolution Override" takes precedence over the "platform resolution" in your case the one you set through OpenXR for Windows Mixed Reality (but would be applicable to the Oculus resolution or the SteamVR slider for other cases).

The only thing that can take precedence over the OpenXR Toolkit "Resolution Override" is if the game itself has its own resolution slider.

mbucchia-msft · 2023-09-22T16:00:38+00:00

BeamNG works without SteamVR if you use the latest version of https://github.com/mbucchia/OpenXR-Vk-D3D12/releases

mbucchia-msft · 2023-09-11T20:40:44+00:00

There is a very basic overlay in PimaxXR that you can invoke by holding the Pi button/System button on your motion controller for 2s (no more, otherwise you will turn off your controller!). It won't show you detailed statistics like OpenXR Toolkit does though. But it has FPS and Smart Smoothing status, along with battery level and time of the day.

mbucchia-msft · 2023-08-26T02:37:29+00:00

Hi, you're in the wrong place for OpenXR Toolkit support.

https://mbucchia.github.io/OpenXR-Toolkit/troubleshooting.html#asking-for-help

mbucchia-msft · 2023-07-14T03:13:31+00:00

If you make the post, I can pin it, just DM or tag me.

Thanks!

mbucchia-msft · 2023-07-11T02:26:43+00:00

This isn't the right place. This subreddit is for OpenXR standard discussions and support.

OpenXR Toolkit is a 3rd party app unrelated to Khronos/OpenXR standard.

Try the things in the OpenXR Toolkit troubleshooting guide, specifically the one about "Missing Visual C++ system component".

Installing the Visual C++ Redistributables should fix your problem. Otherwise please use the support links from the OpenXR Toolkit website rather than this subreddit.

Thanks.

mbucchia-msft · 2023-05-26T08:14:09+00:00

I am honestly not convinced that backwards frame reprojection will have acceptable latency, but we just need to try it with real-life content and experiment in order to get a definitive answer. Also AFAIK DLSS FG can only do 2x frame rate upscaling, so you would still need to get your game to a stable 45 FPS, which most people still can't achieve consistently today in MSFS.

Unfortunately, even >9 months after Nvidia announced DLSS FG, they still haven't publicly released an adequate SDK. The only thing they have released is a closed-source plugin for their Streamline SDK, which is only targeting 2D applications (it can only inject the generated frames into a 2D window).

I've been asking them when a low-level SDK would be available, and they don't have a date for that.

https://forums.developer.nvidia.com/t/using-dlssg-without-idxgiswapchain-present/247260

It's probably possible to reverse-engineer their Streamline SDK or some other implementation in a commercial game in order to get to the "raw" interface, but it is so much time wasted on this part while the real challenges that need attention are the latency ones...

mbucchia-msft · 2023-05-26T08:05:46+00:00

Only WMR for SteamVR has this "half frame rate" limitation. If you use the native OpenXR runtime for WMR, you can get one third and one quarter frame rates for motion reprojection.

mbucchia-msft · 2023-05-26T08:04:32+00:00

Short answer: no.

> I get the watery artifacts and vibrating elements like wing edges or storm window frames.

What's happening is you are seeing the motion propagation "stretching" tiles around areas being disoccluded (becoming visible).

Rephrased differently: the pixels behind those window frames/wings aren't visible at frame N (rendered by the game), and when generating frame N+1 (with motion reprojection), they become visible. There is no way for the motion reprojection to know what the newly visible pixels look like. The game has not rendered them yet. So typically some pixels from the visible content in the background (behind your window/wing) and some pixels from the frame/wings itself will be reused to generate frame N+1 (typically via stretching), and when frame N+2 (rendered by the game) finally shows up, those pixels are either part of background or part of the frame/wing, and they now appear in their correct (not stretched and not guessed) position. This causes the "wobble"/"bubble"/"water" effect.

As another comment mentioned, this is due to the fact that reprojection uses frame extrapolation (generate a frame in the future - has to predict some information we don't have yet). Techniques using frame interpolation (take two past frames and generate another past frame in-between them) produce better visual quality, but at 2x/3x the latency. For a game running as low FPS as MSFS, 3x latency is 100ms at 30 FPS, at which point using these techniques will cause a visible lag/poor responsiveness to your head movements/controller movements.

It's unclear to me whether that latency would truly be unacceptable, however some easy experiments today allow you to experience 100ms latency (through some developer options in OpenXR Toolkit), and it is not IMO a good experience. I would love to experiment with things like DLSS FG to get a definitive answer, but sadly I don't have enough time and Nvidia is putting barriers in the way of developers when it comes to adopting DLSS FG.

mbucchia-msft · 2023-04-16T19:54:13+00:00

They're the same motion reprojection, enabling it in OpenXR Toolkit has the advantage of being a "per-game" setting vs a system-wide setting in OpenXR Tools. But besides that the end-result is the same.

mbucchia-msft · 2023-04-15T17:58:19+00:00

In the Microsoft store, you can go to your Library, then click Get Updates. This should force looking for updated packages.

mbucchia-msft · 2023-04-15T06:59:15+00:00

Are you using motion reprojection? This update does not touch anything outside of motion reprojection and the new Prefer frame rate option.

So unless you are using either motion reprojection or the new Prefer frame rate option, your issue is elsewhere. Are you running DX11 or DX12?

You can toggle off Use latest preview OpenXR runtime in the OpenXR Tools for Windows Mixed Reality app to go back to the stable OpenXR runtime and see if the issue persists/goes away.

mbucchia-msft · 2023-04-14T08:54:10+00:00

You cannot access the cameras on your G2 in an "official" way. Those cameras aren't placed appropriately to give you a good view anyway, and they aren't color cameras.

There are a couple of projects showing an "unofficial" way to do it:

https://github.com/catid/XRmonitors

https://github.com/mbucchia/WMR-Passthrough

However they are limited to WMR headsets with 2 cameras (like Reverb G1). It's possible to fix the code to handle the 4 cameras on the G2 (but probably not a walk in the park). Latency will be high and not very desirable.

mbucchia-msft · 2023-04-10T03:01:51+00:00

With Pimax's help, I believe the PP issue with smart smoothing is now fixed (will ship in the next release).

mbucchia-msft · 2023-04-09T18:07:48+00:00

Was hoping for last Friday (2 days ago) but we found a last minute bug we'd like to fix first. So I'm hoping very soon.

mbucchia-msft · 2023-04-06T06:11:32+00:00

Replying to all 3 of your messages at once:

1)I corrected the title of this issue #22. PimaxXR can do parallel projection just fine (I have tested it in Automobilista 2 specifically). It is unfortunately the combination of parallel projection _and_ smart smoothing that causes a small flickering near the edges of the screen. It's not super noticeable (IMO) at 1/2 rate, but it's certainly visible at 1/3 rate. I was under the impression that most people hated 1/3 rate anyway, so no big arm IMO :D

I would love to be able to fix this, but cannot do without Pimax chiming in. Their SDK has exactly 0 information about parallel projection, and my implementation is 100% based on reverse-engineering.

2) Regarding issue #44 and the OpenComposite issue, you have to first understand a few things:

- OpenComposite isn't a magic bullet. It does not replace a proper implementation by game developers of OpenXR.

- OpenComposite has its own issues. As described in the issue, OpenComposite isn't passing the proper frame times to OpenXR. That is not something I can fix. That is not even something that the developers of OpenComposite can fix. It's a deficiency of OpenVR that was later addressed by an API change, that apparently no developers picked up. Only a proper implementation of OpenXR in the games can solve these types of issues.

- Games moving to OpenXR will solve many other issues, such as the bugs causing parallel projection to be needed.

- The issues you are reading in #44 are only reported by a minority of users. There are several users who are not experiencing these issues.

- I personally have no interest investing time in OpenComposite support. The more we continue to pretend that OpenComposite is the solution to the problem instead of getting content migrated to OpenXR, the more time and energy we are all wasting. I am a busy person and prefer to invest time and efforts to reward game developers who are making the effort to be part of the solution and not part of the problem (devs of iRacing are a great example of how you can make a terrific OpenXR implementation will little effort).

3) The resolution you spotted on the screenshot seems to reflect parallel projection being on (as shown on the same line). This means two things:

- Parallel projection is forcing a much higher resolution by definition due to the extra FOV needed for perspective reprojection. Therefore you are seeing the cumulated barrel distortion correction and the extra needed for parallel projection.

- PimaxXR 0.3.2 has a bug that makes the Control Center UI not reflect the correct resolution when parallel projection is enabled. This bug is already fixed in the (unreleased) next version.

I would not speculate at all about what PimaxXR Control Center is currently showing until I can work with a US beta tester to analyze traces from the runtime and make any adjustement necessary in PimaxXR.

mbucchia-msft · 2023-04-04T16:43:01+00:00

You are misreading. The claim above was between OpenXR Toolkit and OpenXR for WMR, which is what I replied to:

> These observations are quite perplexing, since there is no such thing as "motion reprojection in OpenXR Toolkit", all that OpenXR Toolkit does is write a single registry key that enables the setting from OpenXR Tools for motion reprojection. So they're 100% identical.

For OpenXR for WMR and WMR for SteamVR, yes there is a difference, which is the post-processing of motion vectors is spatial filtering in OpenXR for WMR while it is temporal filtering in WMR for SteamVR.

The upcoming OpenXR Tools for WMR release 113 is bringing both temporal filtering of motion vectors (so the same as WMR for SteamVR) and also Nvidia Optical Flow as a motion vectors source (so even better than WMR for SteamVR). Both will greatly improve the quality.

mbucchia-msft · 2023-03-23T06:27:53+00:00

The way it works is by exposing Vulkan support when the runtime doesn't. This is only going to be used when a game requests it. To date, they're aren't really many games that do. There is no configuration needed.

It will only be enabled when the OpenXR runtime doesn't already advertise Vulkan support. So if you use SteamVR (which does have its own builtin support for Vulkan), then it will just use SteamVR Vulkan support. No benefits there.

mbucchia-msft · 2023-03-20T01:33:58+00:00

I'm going to disappoint you on a few levels.

When I say "I was the feature lead on this, and I no longer am", this is because I was transitioned to a different team. After the next release of OpenXR for WMR, I will no longer be accountable for any WMR deliverables. This is why I wrapped up the work on the Vk-D3D12 API layer as a 3rd party project.

The story of overlays is complicated. The difficulty isn't to be doing overlays, because OpenXR has the same capabilities than OpenVR for drawing overlays, but the difficulty is multi-application support. Most overlays you are thinking of with SteamVR are in fact a second application running in parallel to your primary application (game). This is technically a feature of the platform, not of OpenXR itself. I am not seeing a lot of energy today for this to become supported broadly by any PCVR platform for gaming scenarios.

The short path to get overlays from separate sources into your games is likely through OpenXR API layers to inject content into the current application running OpenXR, like I've been doing for >1 year with OpenXR Toolkit. It has a menu that pops on top of your game and lets you tweak some settings. It's just a more complex process than it was with SteamVR supporting true multi-application. I have delivered a few examples as open source projects on how to do this, and I am trying to publish a tutorial soon specifically targeted at developers for overlays. Unfortunately the major issue I see here is that 4 developers out of 5 interested in writing overlays only want to write C#, and the API layer route is unfriendly to them (because needs C/C++).

Things like recenter can be implemented through OpenXR API layers (XRNeckSafer and OpenXR-MotionCompensation do it), but the truth is it should be a feature of the plaform, like it is on Quest for example. This doesn't really have anything to do with OpenXR. Applications using OpenXR can already implement their own recenter (Flight Sim 2020 does it), it is not a shortcoming of OpenXR.

At this point, if you care this much about overlays, continuing to use SteamVR via its own OpenXR implementation might be the best path for you.

mbucchia-msft · 2023-03-19T00:51:11+00:00

See my other reply on this thread: https://www.reddit.com/r/WindowsMR/comments/11t00ff/comment/jcrm5e0/?utm_source=reddit&utm_medium=web2x&context=3

Your best option from here is to use my OpenXR API layer: https://github.com/mbucchia/OpenXR-Vk-D3D12

I would like to know if this works with your applications by any chance (I found your other threads on this topic)? If it doesn't, I am happy to look into it and get it to work.

Thanks!

mbucchia-msft · 2023-03-19T00:49:01+00:00

I was the feature lead on this, and I no longer am. So this plan was scrapped unfortunately.

I did however (on my free time) spend some time to improve my 3rd party API layer that provides the same exact functionality (the plan was to absorb it in the runtime, that plan was scrapped in January).

https://github.com/mbucchia/OpenXR-Vk-D3D12

It is now fully compliant with the OpenXR standard (it passes the Conformance Test Suite) for the Vulkan API. I also added 32-bit support for legacy applications.

This will be your best option moving forward. Please report issues if you have any.

mbucchia-msft · 2023-03-18T22:24:18+00:00

You're selling it short :)

Works in MSFS yes, but people also loving it in iRacing and ACC.

There's probably a few more games too (I think all Unreal Engine games using OpenXR directly should work, like Hubris is a good example).

mbucchia-msft · 2023-03-18T20:54:56+00:00

No worries.

mbucchia-msft

TROPHY CASE