Oculus Rift

Feedback on past, current, and future development.
User avatar
Br0ken
Posts: 199
Joined: 02 Apr 2012, 05:54
Location: Siberia

Re: Oculus Rift

Post by Br0ken » 09 May 2017, 23:34

An open-source library that support variuos VR devices. Based on Qt and requires no other libraries. Looks nice!
https://github.com/marlam/qvr

User avatar
AnyOldName3
Posts: 546
Joined: 26 Nov 2015, 03:25

Re: Oculus Rift

Post by AnyOldName3 » 10 May 2017, 01:46

That might be the exact thing that we need if we're to get VR support without violating the GPL. Then again, it might not be. I don't exactly know how it works.

User avatar
Br0ken
Posts: 199
Joined: 02 Apr 2012, 05:54
Location: Siberia

Re: Oculus Rift

Post by Br0ken » 10 May 2017, 10:12

I hate these licensing issues... :cry:
"The integration of OpenSceneGraph with our framework requires only few lines of code", so it would be great if QVR will be GPL-compatible.

mjmax
Posts: 6
Joined: 06 May 2012, 22:31

Re: Oculus Rift

Post by mjmax » 01 Aug 2017, 19:00

Hey everyone, I haven't seen anyone mention OpenXR:
https://en.wikipedia.org/wiki/OpenXR

It's being developed by Khronos with a tentative first release of mid-2018. It seems to be the leading candidate for an industry VR standard. From what I've heard the guys over at Dolphin are waiting for it to officially implement their VR support:
https://www.reddit.com/r/oculus/comment ... d/dhz78aw/

They also have a GPL license, so it seems like OpenXR would be a match once it finally releases.

User avatar
AnyOldName3
Posts: 546
Joined: 26 Nov 2015, 03:25

Re: Oculus Rift

Post by AnyOldName3 » 01 Aug 2017, 22:47

I'm surprised to learn about that here. I'm even more surprised to find out that the guy I know as Armada on Dolphin's forums is the same guy as the one behind Revive.

Either way, once there's a way to make OpenMW work on my Vive without breaking the GPL, I'll hopefully be able to do some of my own meddling and get something some kind of working.

lethality
Posts: 5
Joined: 14 Jul 2016, 12:46

Re: Oculus Rift

Post by lethality » 15 Oct 2017, 08:20

I haven't had much time to look at this in the last year but I did update to the latest version of OpenMW, performance has improved a lot and the frame rate in my little hacked VR version is starting to look kind of OK. One of the main performance issues is that osgopenvrviewer runs in single threaded mode, modifying OSG to include VR support seems like the right approach to me.

qvr looks interesting, it worked fine with the test cow model but I had trouble integrating it with OpenMW. I am not sure if there is a Qt version issue, qvr uses Qt 5 and OpenMW wants to stick with version 4 at the moment. Maybe I was just doing something else wrong though, if it works well with OpenMW that might be a way to get around licence issues and support multiple VR systems.

Most of the work required for VR support is the same regardless of API so it should be fairly easy to switch to OpenXR when it is released, it certainly sounds like the best option in the long term.

Of course, you can do as much meddling as you like with anything GPL, the only problem is redistribution. I think it is also generally understood that you can redistribute source code without these concerns about licence incompatibilities.

LoneWolf
Posts: 6
Joined: 26 Sep 2017, 19:13

Re: Oculus Rift

Post by LoneWolf » 15 Oct 2017, 12:07

lethality wrote:I am not sure if there is a Qt version issue, qvr uses Qt 5 and OpenMW wants to stick with version 4 at the moment.
arch linux builds openmw against QT 5 and everything runs fine.
try building with

Code: Select all

-DDESIRED_QT_VERSION=5

User avatar
scrawl
Posts: 2076
Joined: 18 Feb 2012, 11:51
Contact:

Re: Oculus Rift

Post by scrawl » 15 Oct 2017, 12:26

One of the main performance issues is that osgopenvrviewer runs in single threaded mode, modifying OSG to include VR support seems like the right approach to me.
I've only had a quick look at this osgopenvrviewer, but I'm sure it could be made to work with threading without having to modify OSG itself. What exactly breaks when using threading? Does it try to create OpenGL objects from the non-OpenGL thread? This code could probably be changed to use the osg constructs (e.g. osg::FrameBufferObject or osg::Camera) instead of calling OpenGL manually, and that way OpenGL calls will naturally move to the graphics thread.

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests