SteamVR supports the rift natively and due to some issues with the OculusSDK (and the fact I don’t need anything from it) I tried turning off the oculus plugin, which works to some extent except that it renders the cameras as if they were at IPD 0, IE the world looks big and almost in mono.
Start new VR template project, turn off oculus plugin. Restart project. Play “motioncontrollermap”. The tracking will work, and so does input, but the rendered images are wrong.
Thank you for the information provided. However the workflow you have described above is one that we do not encourage or actively support. This being the case I would suggest using the oculus plugin to avoid the issue that you are seeing. If the issue continues after doing so please feel free to create a new thread for further support. I hope that this information helps.
SteamVR is designed to work with any headset, and games that use SteamVR can natively work with the rift, so I’m confused as to why this would be considered a workflow that epic doesn’t support since so many developers are using this workflow on earlier engine versions without issues. I would appreciate if you talked to someone on your VR team because I think you’re wrong, and if you aren’t then I would like an explanation as to why this isn’t supported. I know many devs that’ll cry out loud when they update to 4.18 and discover this issue.
The overall issue is 4.18 doesn’t handle the case where the aspect ratio of GetRecommendedRenderTargetSize differs from the native screen resolution of the HMD.
Rift just legitimately gives a different aspect ratio, which should be handled (and is in master and 4.17).
WindowsMR doesn’t try to give a different aspect ratio, but the way UE4 is querying native screen res (VRExtDisplay->GetWindowBounds) breaks and returns the screen res of the Rift and (2160x1200) even on Windows MR, which differs from the actual aspect of most Windows MR devices (1440x1440 or 1440x1600) and the aspect of their recommended render targets.
4.17 didn’t care if the aspect ratios were different, but 4.18 does. 4.18 seems to have inadvertantly done this while adding adaptive pixel density, but adaptive pixel density doesn’t actually work for me on in 4.18 and the interface for adaptive pixel density changes anyway in 4.19. I think 4.18 should just be reverted to the 4.17 behavior in a hot fix.
The FFrameSettings structure in the plugin has a lot of infrastructure to get sent to the render thread with a locked stack and stuff, but then nothing from that stack ever actually gets consumed. Adaptive res on SteamVR looks like it was a feature that was in development and wasn’t fully working and then was accidentally merged.
I think the fix needs to be a bit more involved than in your pull request (or the MS one here https://github.com/EpicGames/UnrealEngine/pull/4294). I tried doing it but didn’t find out adaptive resolution was broken even on until mid way through. Making it all fit in with the FFrameSettings stuff just over complicated it when that stuff didn’t work anyway.
That stuff needs to be pulled out and all put back to how it was in 4.17, but keep the other stuff like support for rendermodels, etc.
I agree with what you have said. The little patch I put out only worked for packaged projects. VRExtDisplay->GetWindowBounds is not meant to be a way to get the native screen resolution as far as I can tell. OpenVR even includes a comment saying that IVRExtendedDisplay should not be used in production applications: openvr/openvr.h at master · ValveSoftware/openvr · GitHub . 4.18 butchered this functionality and a hotfix reverting to 4.17 does seem like the best option.
As an update there is currently a report for the distortion mentioned for mixed reality HMDs. This report includes the pull request mentioned above (jira UE-53580). This report will be sent to the developer for further consideration. I hope that this information helps.