Could you explain a little how you got it to work? I've downloaded it and tried running Odyssey VR mode from Steam, and it crashes and OpenComposite gives me the error Unknown Int32 Property Dev 0 Prop 2011. This is with and without the admitUnknownProps=enabled. I'm using a HP Reverb G2, so WMR is running in the background. Would love to try this out.
Any luck running OpenCompositeACC + OpenXR toolkit?
- Thread starter jafergon
- Start date
Figured it out, there was an update available, everything works after the update. Initially I'm really impressed, I'm getting between 70-90 FPS games with in-game settings mostly maxed out, using SS 1.0 in game and using FSR 100% with the openxr overlay. This was on a planetary surface in Odyssey, but I'll have to try ports and stations next.
5900X, 3070, Reverb G2.
5900X, 3070, Reverb G2.
Which OpenComposite are you using, I see 3x, OpenComposite_TimeInvalid, OpenCompositeACC, OpenComposite
I used the openvr_api.dll from
Files · openxr · Campbell Suter (ZNix) / OpenComposite · GitLab
Reimplementation of OpenVR, translating calls to OpenXR.
gitlab.com
I replaced my openvr_api.dll in the OpenVR\Win64 folder of the game but it just crashes out with 'Failed to initialise libOVR .: -3001'.
It didn't create an opencomposite.ini file anywhere for me to edit.
I'm wondering if I should have put it with the ED64 exe. I don't want to use the systemwide tool lest it mess up something else.
Last edited:
I used OpenComposite, making sure it's not the Oculus version, which switches the whole system to OpenVR, super easy to turn it off, just open the program and switch it back to SteamVR.Which OpenComposite are you using, I see 3x, OpenComposite_TimeInvalid, OpenCompositeACC, OpenComposite
I used the openvr_api.dll from
Files · openxr · Campbell Suter (ZNix) / OpenComposite · GitLab
Reimplementation of OpenVR, translating calls to OpenXR.
I replaced my openvr_api.dll in the OpenVR\Win64 folder of the game but it just crashes out with 'Failed to initialise libOVR .: -3001'.
It didn't create an opencomposite.ini file anywhere for me to edit.
I'm wondering if I should have put it with the ED64 exe. I don't want to use the systemwide tool lest it mess up something else.
I created the .ini file as it wasn't there before, using notepad to add the line of code, saving, then changing .txt to .ini.
Hope that helps.
Got it thanks. Switched to that and it's working now. Checked by switching on the OpenXR frametimer.
BTW what line of code did you add to opencomposite.ini and where did you save the file? Was it just 'admitUnknownProps=enabled' and nothing else?
Also, have you enabled foveated rendering? I couldn't see it explained in the git repo.
Yeah just that one. Not even sure if it was needed. I have foveated turn on but not sure how to confirm if it's working as the perifery of my HMD is really blurry.
Edit: and I put the ini file in the same directory as the OpenComposite.exe
Ok, exactly what did you do to turn foveated on? Was it code somewhere or did you push buttons in another app?
I have OpenXR Dev Tools installed for MSFS and EDO has 'magically' just appeared in it's list of supported apps. The menu hotkeys don't work correctly e.g. CTRL-F1 is actually CTRL-F2 and SHIFT-F2 is actually F2+SHIFT-F2 in sequence, however despite that I think I got foveated set to performance however it is definitely NOT working. In MSFS it's obvious when it's on but the same values in EDO did nothing. Maybe it's just because I was on foot in my carrier or I need to turn upscaling on first before foveation kicks in ( which is exactly what happens with vrperfkit ).
Last edited:
I have messed around a bit with this - some rambling ahead, forgive me. For reference, I'm using a Reverb G2. I got it working with the latest OpenXR-branch of OpenComposite and the latest OpenXR Toolkit. Pretty cool. I always felt that the WMR-SteamVR bridge was a severe bottleneck for my headset.
First major drawback for me, and maybe important if you want to try this out: EDHM (more precisely: The 3DMigoto wrapper dll) makes OpenComposite crash. So, back to orange for my testing...
First tests were promising. I did not do an extended playtest, but things seem smoother, less "jerking" and microstutters in the headset. But for a proper comparision setup to SteamVR, I'm a little confused. I'm not sure if I am comparing apples to apples or oranges.
First issue: Render resolution. There is a render scale slider in the OpenXR-Tools settings panel, and there is the render scale setting in opencomposite.ini. I'm guessing leaving the render scale option in OpenXR-Tools disabled enables some kind of auto-scale. I also figured out that that slider setting and the opencomposite.ini-setting multiply. I am guessing it's similar to the global and per-app percentage setting in SteamVR?
If that's all correct, I left the render scale slider at 100% and supersampleRatio at 1.0, which would be equivalent to a resulting 100% scale in SteamVR. Inside a coriolis (that's where I'm sitting right now) I get comparable performance to my SteamVR setup (where 70% is usually the max I can run without having a stutter orgy). So that's a win, I guess.
I'm not really sure, but things seem less... crisp? But that could be an effect of having to play with default color setup (no EDHM). With the EDHM I usually run a dark blue HUD setup with white text and little to no cockpit lights, the default orange always seems overblown in contrast. I don't know, guess I need to do a few proper comparison sessions.
Second thing that doesn't seem to work is the automatic motion reprojection. With SteamVR, not using MR wasn't an option, because all framerates that weren't 90 or 45 lead to major stuttering when I turned my head. So Inside a station I usually get 45 fps with MR.
With OpenComposite I either have to force it on in OpenXR-Tools and have it on all the time or have no MR at all. Two things I noticed: One, head motion without MR was still very smooth even at 55 to 60 fps (which is what I got in the station without upscaling), but the fps overlay of OpenXR Toolkit stuttered like hell. And two, with MR enabled I got locked 45 fps, but the framerate display sometimes dropped to 30 fps for a few seconds, although visually everything was fine. Don't know what to make of it.
My plan to compare OpenComposite with SteamVR on a fair basis: Set supersampleRatio to 0.7 (70%), lock MR for both and do a bounty hunting session. My expectation is that the experience in OpenComposite will be much smoother. If that's the case, I guess the next thing will be upping the resolution and play with upscaling.
In terms of upscaling: Does anyone have an opinion on NIS vs. FSR?
First major drawback for me, and maybe important if you want to try this out: EDHM (more precisely: The 3DMigoto wrapper dll) makes OpenComposite crash. So, back to orange for my testing...
First tests were promising. I did not do an extended playtest, but things seem smoother, less "jerking" and microstutters in the headset. But for a proper comparision setup to SteamVR, I'm a little confused. I'm not sure if I am comparing apples to apples or oranges.
First issue: Render resolution. There is a render scale slider in the OpenXR-Tools settings panel, and there is the render scale setting in opencomposite.ini. I'm guessing leaving the render scale option in OpenXR-Tools disabled enables some kind of auto-scale. I also figured out that that slider setting and the opencomposite.ini-setting multiply. I am guessing it's similar to the global and per-app percentage setting in SteamVR?
If that's all correct, I left the render scale slider at 100% and supersampleRatio at 1.0, which would be equivalent to a resulting 100% scale in SteamVR. Inside a coriolis (that's where I'm sitting right now) I get comparable performance to my SteamVR setup (where 70% is usually the max I can run without having a stutter orgy). So that's a win, I guess.
I'm not really sure, but things seem less... crisp? But that could be an effect of having to play with default color setup (no EDHM). With the EDHM I usually run a dark blue HUD setup with white text and little to no cockpit lights, the default orange always seems overblown in contrast. I don't know, guess I need to do a few proper comparison sessions.
Second thing that doesn't seem to work is the automatic motion reprojection. With SteamVR, not using MR wasn't an option, because all framerates that weren't 90 or 45 lead to major stuttering when I turned my head. So Inside a station I usually get 45 fps with MR.
With OpenComposite I either have to force it on in OpenXR-Tools and have it on all the time or have no MR at all. Two things I noticed: One, head motion without MR was still very smooth even at 55 to 60 fps (which is what I got in the station without upscaling), but the fps overlay of OpenXR Toolkit stuttered like hell. And two, with MR enabled I got locked 45 fps, but the framerate display sometimes dropped to 30 fps for a few seconds, although visually everything was fine. Don't know what to make of it.
My plan to compare OpenComposite with SteamVR on a fair basis: Set supersampleRatio to 0.7 (70%), lock MR for both and do a bounty hunting session. My expectation is that the experience in OpenComposite will be much smoother. If that's the case, I guess the next thing will be upping the resolution and play with upscaling.
In terms of upscaling: Does anyone have an opinion on NIS vs. FSR?
okay, first thing I was wrong on: Automatic reprojection works, framerate jumped to 90 from 45 when I left the station. Confusingly, I have to set it to always on in the OpenXR settings panel, but it's still automatically enabled in OpenComposite.
The combination 100% slider and 0.7 supersampleRatio is indeed visually equal to 70% SteamVR. The default orange color scheme is actually making text more blurry than what I get with EDHM. I'm conflicted... I don't think I can go back to all orange...
The combination 100% slider and 0.7 supersampleRatio is indeed visually equal to 70% SteamVR. The default orange color scheme is actually making text more blurry than what I get with EDHM. I'm conflicted... I don't think I can go back to all orange...
How did you get your opencomposite.ini? Neither quackinthebush nor I had ours created automatically so we made them up, I have no idea what is meant to be in it or where it's supposed to sit. Mine hasn't been auto populated by Opencomposite either.okay, first thing I was wrong on: Automatic reprojection works, framerate jumped to 90 from 45 when I left the station. Confusingly, I have to set it to always on in the OpenXR settings panel, but it's still automatically enabled in OpenComposite.
The combination 100% slider and 0.7 supersampleRatio is indeed visually equal to 70% SteamVR. The default orange color scheme is actually making text more blurry than what I get with EDHM. I'm conflicted... I don't think I can go back to all orange...
On my G1, MR is off and WMR is set to best quality. If either of those are changed I get the old 'wobbly display' problem where objects seem to shimmer almost as if I'm looking through water. ATM I do think OpenC is doing a better job than SteamVR.
In MSFS NIS was better than FSR for me, less smudging on distant objects, If I can figure out the hot key combinations I'll test for ED tonight ( I should have written down the actual bindings I figured whilst testing it MSFS, since they weren't what the toolkit said they were ).
- enableAudio - boolean, default enabled. Should OpenComposite redirect the game's audio to the Rift builtin audio. This means you don't have to set the Windows default audio device. This doesn't always work and can sometimes cause crashes, see below for more information about it.
- renderCustomHands - boolean, default enabled. Should OpenComposite render custom hands. Disable this if you really dislike the hand models, and some games (like Skyrim) come with backup models that will be used instead.
- handColour - colour, default #4c4c4c. The colour of the hands OpenComposite draws, as they currently lack proper textures.
- supersampleRatio - float, default 1.0. The supersample ratio in use - this is similar to what you would enter into SteamVR, a value of 145% in SteamVR is a value of 1.45 here. A value of 80% in SteamVR is 0.8 here, and so on. Higher numbers improve graphics, at a major performance cost.
- haptics - boolean, default enabled. Should haptic feedback to the Touch controllers be enabled.
- admitUnknownProps - boolean, default disabled. If asked for a tracked device property it does not understand, should OpenComposite set that as an error and let the game continue. Enabling this may cause severe and hard-to-detect side-effects, and as such if a property is missing, please report it and let it get fixed like that. However, some (very few) games (namely Vivecraft) will query every property they know about, even if never using all but a few of them. In these cases, you should enable it.
- forceConnectedTouch - boolean, default enabled. If this is enabled, games are always told that the Touch controllers are connected, even if they are not. This ensures controllers will work if they were asleep when the game was started. If you use a gamepad and don't want the game to think controllers are connected, disable this option. See issue #25.
- logGetTrackedProperty - boolean, default disabled. Print logging information when the app requests information about tracked devices, such as the HMD or the Touch controllers. On some games, this causes a log entry to be generated every frame, which isn't great for performance and clutters up the log. This is potentially useful for troubleshooting, and was enabled by default before the config option existed. In general, unless you've been told to enable this (or you know what you're doing while troubleshooting) you don't need to enable this.
The possible types are as follows:
- boolean - one of on, true, enabled to enable the setting, or off, false or disabled to do the opposite. These are not case-sensitive, so Enabled or tRUe work fine.
- colour - same as the format used in HTML/CSS, it's a # followed by six hex characters. Mozilla has a tool to help with this. Again, it's case-insensitive.
- float - a floating point (decimal) number, eg 123.456.
Example files:
- Running a simulator on a powerful computer, and wearing external headphones so you don't want the audio redirected:
enableAudio=off
supersampleRatio=1.4
- Running SkyrimVR with yellow hands, and haptic feedback disabled:
handColour=#ffff00
haptics = off
taken from here, it goes in the game folder - https://gitlab.com/znixian/OpenOVR/-/blob/master/README.md#configuration-file
I know you say that performance mode dosnt work for you but for other people that may not know or havnt tried, there was a bug in performance v best visual quality in the MR settings where best performance had a sharper image quality than best visual quality, this has been known for years and not fixed as far as I can tell, it may be worth trying best performance to see if it helps in Oddy.
Last edited:
Mine is grey, white and green predominantly, no way i could go back to the orange, it looks aweful in comparison.I don't think I can go back to all orange...
you have to create the ini file manually on a per-game basis. The only thing I put into the file was the supersampleRatio setting for setting the resolution. The game runs without an ini file as well, and OpenComposite runs with its default settings.
The shimmering is an artefact of MR, no way around that. But I'd rather have that when I sit in a station than having my GPU running at 95% and sounding like a jet engine.
Yeah that's a tough one. It's a nice crisp cockpit vs. better performance... hard choice. I went to a HazRes last night and had a way smoother experience than I had with SteamVR; especially with alot of NPC ships (when I dropped in I met around 20 ships busy with infighting) the HazRes is a real stutterfest. It was smooth as butter last night. I will have to do the comparison in SteamVR though, might as well have been the absence of EDHM/3DMigoto.
Thank you, I think I was overthinking this and assuming additional syntax and formatting beyond just lines of ThisSetting=On.
Where do you save the file for EDO, in the OpenComposite program folder or somewhere else like the folder with Elitedangerous64.exe?
In the game folder with Elitedangerous64.exe.
Using the OpenXR Toolkit and comparing settings with MSFS, I can't make upscaling or fovation activate in EDO. I did set the render scale to 200% in OpenXR Tools but that just gave a zoomed fishbowl look in ED. Not sure what to try next. This is getting daft, vrperfkit does all the settings and they work but just don't look good on my rig, and OpenXR Toolkit has settings that look great in MSFS but don't work in EDO. Wondering if there are any other toolkits out there to try.
I can't set foveation in opencomposite.ini so, after trawling all the values, it's no use to me.
I can't set foveation in opencomposite.ini so, after trawling all the values, it's no use to me.
I have seen this and pretty sure the fix or workaround, dont ask me what or where it was but pretty sure it was in the DCS forum main vrperf thread, i`ll have a look later and see if I can find it.
Regardless of tweaks and wanting 'good' foveation - really enjoying OpenComposite and OpenXR. SteamVR isn't quite dead to me but it's certainly on the shelf next to 2D gaming.
BTW has anyone got any of the upscaling methods and/or foveation working for EDO, specifically, with OpenComposite+OpenXR? Just wondering if its only broken for me.
BTW has anyone got any of the upscaling methods and/or foveation working for EDO, specifically, with OpenComposite+OpenXR? Just wondering if its only broken for me.
I haven't really tested OpenComposite on the heavy hitters - the AX CZs in HIP 22460 were a real slideshow for me - but so far I'm impressed with the performance gains on my G2. I can confirm that upscaling and foveation of the OpenXR Toolkit do work. Again, I haven't done intense testing (it's way to warm here for longer VR sessions), but I've been playing with a custom render resolution of 100% and NIS upscaling set to 80%. I get a very crisp image with good performance (still MR in stations and with alot of NPCs around, but that's to be expected).
Not sure about the performance impact of foveated rendering, but if you switch the pattern from wide to narrow you can clearly see it having an effect. The narrow pattern reaches up to your own ship holo, there you can see that the rendering changes with changing the pattern. So yes, upscaling and foveated rendering works. Performance impact? Not sure.
Not sure about the performance impact of foveated rendering, but if you switch the pattern from wide to narrow you can clearly see it having an effect. The narrow pattern reaches up to your own ship holo, there you can see that the rendering changes with changing the pattern. So yes, upscaling and foveated rendering works. Performance impact? Not sure.
I know a lot of people were struggling with VR performance in Odyssey, I was and I have new hardware, this has helped immensely, I hope others find this thread. Might be worth posting a quick how-to thread and get the word out about this.