https://code.google.com/p/jmonkeyengine-oculus-rift/ will have to be moved to github. Hopefully there is an easy way to automate this somehow… quick guides I found:
I exported the jmonkeyengine-oculus-rift project here:
@rickard & @jherico, I can add you guys as contributors somehow if you provide your github username.
1 Like
jherico is my Github ID.
Funny. I thought about whether we should move the repo yesterday (before getting google’s mail). My id is neph1
One day Google will shut down Google…
5 Likes
OK, I’ve added @rickard & @jherico to the git repository. I’ve also renamed it to “jmonkeyengine-virtual-reality”, since I don’t plan on being specific to the Rift:
I’d like to create an interface for HMDs, and let the Rift be one of the implementations. Just to prepare…
Would you be open to moving the repository to https://github.com/jmonkeyengine/virtual-reality to make it more official?
Like i mentioned in the other thread, I don’t agree with this approach.
For one, unless they use the oculus sdk, their implementation might be vastly different. I initially wanted the to do the same thing but doing the Google Cardboard integration made me realize that. (Although I’d be happy to be proven wrong)
Secondly I think the project will become less and less manageable with each integration.
Eeeeeeeehhhhhhhhhhhhh well I do maintain my own jME3 repository @ GitHub - phr00t/jmonkeyengine: jMonkeyEngine is a 3D game engine for adventurous Java developers. It’s open source, cross platform and cutting edge. And it is all beautifully documented. This is Phr00t's version of that library; better performance, bleeding-edge commits, support for Virtual Reality & multithreading., and I’ll likely be developing the virtual reality library against my own repository. I’m not sure anyone on the “official” jME3 team has any virtual reality hardware to test against, while I plan on buying a Vive (and I already have a DK2). For those reasons, I think it is better kept on my own repository. Feel free to fork, though.
What I mean to say is that I think it’s too early to make any decision on a general strategy for VR in jme
Personally, I don’t think we can ask developers to do it any other way. It is up to us to abstract the two headsets & not ask game developers to do it themselves. Nobody will want to have to pick which headset to support or try and incorporate two different libraries that have tons of overlap. The Vive & Rift ultimately do the same thing – track orientation, position, render the scene for each eye… there is no reason we can’t combine that into one library. Yes, I’m sure the Vive will do some things differently, but that is our job to hide it from the game developers. Also, I don’t feel like maintaining a completely separate Oculus Rift & Vive library.
There are definitely some knowns already, like the Vive will report orientation, position etc. just like the Rift. We can abstract out those methods & plug in additional ones as needed when the SDK comes out. I’m sure the rendering pipeline will need changes when the Vive SDK comes out too, but we can plug those in just as we did with the Rift. When the jME3 app starts, it can detect which hardware is connected and pick the “VRHMD” & rendering pipeline to use.
I do actually, but i’m fine, with your repo being stand alone for now.
I may have a Vive also at work, but I’m glad to follow your lead (both @rickard and @phr00t) for that particular aspect.
I started thid abstraction process in the jme-android project (github). This was made with the assumption that it would be similar to OVR. Feel free to have a look there to get a heads start.
I still think an approach with vr-delegates will achieve the same level of abstraction to the end developer, but with less headache and frustration over trying to fit everything in the same mold. Especially of it comes to the point of compromising on performance.
Jme detecting the hardware is basically what i’m talking about. It’s just that it does’t require the plugins to be based on the same architecture. Refer to how JmeSystem detects the platfotm by trying to instatiate a class.
The more we can keep the HMDs inside the same architecture, the easier it will be to add new HMDs & develop for all at the same time. I think the only big difference will be in the rendering pipeline (e.g. how Oculus handles distortion, timewarp etc. vs. Vive). The rest, like setting up two cameras, initializing the hardware, getting orientation, position etc. should all work within the same architecture. No need to re-invent the framework for each device there.
Yeah, I see your point, and had a quick chat with Rémy about it too. It’s fine as-is. We can easily come back to this at a much later point. Carry on!
There are many parts of jME3 which are still partially working, such as iOS support or FBX loading. So I don’t see any issue with including VR under the “jMonkeyEngine” GitHub organization just because it is not finished.
My concern is when using VR requires people to modify the engine itself. Instead, we should modify the engine to make it modular enough so that things such as VR can be implemented with ease. For example, this was why I added the capability to disable “SwapBuffers” in the AppSettings class.
You are free to fork my jmonkeyengine-virtual-reality under the jMonkeyEngine GitHub organization. I’m going to work on my repository, just as I do with jME3, though. Personally, I don’t like being bound by “official” jME3 authorization for changes to libraries – I’ve got real money riding on this software, so I want to be in control of my code on my own time, which GitHub allows us all to do. I plan on making the virtual reality library easy for anyone to use & integrate easily with my jME3 branch. I don’t plan on making it not compatible with the main jME3 branch, though, I just won’t guarantee it.
I really appreciate the SwapBuffers change you made & I did move that into my jME3 branch.