Thread for discussion about Oculus Rift integration in jMonkeyEngine. Based on jOVR(jocular).
Current SDK version: 0.4.4 Now with Linux support.
Code is available here:
http://code.google.com/p/jmonkeyengine-oculus-rift/
Old intro:
Hey!
I ordered a Oculus VR devkit last week. With the delivery probably at least a month or two away, i’ll have some time to add support for it in jmonkeyengine.
I will share all info and progress here, and anyone wanting to help out, is welcome to do so.
Very cool.
Muhaha, nice 
Fascinating.
Anybody got an idea what to do instead of a HUD when using an Oculus?
@toolforger said: Fascinating.Anybody got an idea what to do instead of a HUD when using an Oculus?
Why no HUD? I think it makes sense.
Well a HUD makes sense. Clickable gui icons I’m not so sure…
How do you interact with it? Do you have a console style controller?
It’s going to be interesting what HUD parts should move with the viewing angle and what should remain “stationary”.
In a vehicle or plane simulation, a HUD is simply a stationary game element, i.e. it doesn’t follow head movements.
In a 1st person shooter, the HUD might have to move with the head. On the other hand, it might be disorienting.
It’s certainly going to require more thinking about the insides of a cockpit. An X-Wing pilot might see the graffity on the cabin wall, an Imperial pilot the clean soulless cabin walls of a supposedly-perfect war machine.
And I’m also wondering what players of the Oculus version of the next Lara Croft game will see when they look down. The vaguest promise in that direction is going to boost sales… and power players will want that configurable for less so they can see what’s happening below them.
@toolforger said: It's going to be interesting what HUD parts should move with the viewing angle and what should remain "stationary". In a vehicle or plane simulation, a HUD is simply a stationary game element, i.e. it doesn't follow head movements. In a 1st person shooter, the HUD might have to move with the head. On the other hand, it might be disorienting.It’s certainly going to require more thinking about the insides of a cockpit. An X-Wing pilot might see the graffity on the cabin wall, an Imperial pilot the clean soulless cabin walls of a supposedly-perfect war machine.
And I’m also wondering what players of the Oculus version of the next Lara Croft game will see when they look down. The vaguest promise in that direction is going to boost sales… and power players will want that configurable for less so they can see what’s happening below them.
oO I don’t get your issue somehow. Right now how FPS games work is this: Theres a flying HUD right in the FOV of the player and it moves with him. Its in a z position that is closer to the player than any object in the game, akin to google glasses or what apache pilots have for real in their helmets. Nothing would change for the oculus? Check out how the HUD in BF4 looks, imo it would work just like this on the Oculus:
The issue with a FPS is that you probably feel like you’re in a rocket wheelchair. You have to move a stick to turn but you can turn your head around. The oculus makes most sense in car/aviation games as there you have exactly that situation: You sit and can only turn your head around. To turn you have to turn the vehicle.
There is still plenty of FPS games using some static HUD elements. They will probably need to adapt.
Regarding turning around - I think, that in first demos of FPS games, they used to use head movement to override turns - so you were walking where you were looking. This obviously was leading to people sitting at strange angles and sometimes getting wrapped up in the cables.
Most geeky solution to movement in fps is
[video]http://youtu.be/AmukXVHW6F4[/video]
Movement, head and aiming all solved in ‘natural’ way.
Rocket Wheelchair!
How awesome would that be?!?
We should trademark that immediately and get it out for Android asap!
@normen said: 2) No, the oculus developers mostly used a separated view + movement scheme. The people sit in chairs, whats the point of a game where you can only go north and never go south? It will be a rocket wheelchair and it will be awesome :D
I was referring to
[video]http://youtu.be/KBylGcvRuek?t=5m[/video]
They have combined solution there - you walk where you aim your head and control stick works on top of that for bigger turns.
Yeah, I was thinking along the lines that abies was referring to.
Thanks for digging up the videos, they’re far better at explaining what I meant than I could with words.
I’d be happy to help, my rift arrives Wednesday.
Awesome. Let’s see what we can whip together before then.
Unfortunately, i’ve had to backtrack a bit since my initial approach was wrong (using two viewports that divided the screen between them, resulting half the resolution).
There.
Source for filter, shader, appstate and test (in topic)
Here’s what it looks like:
Next step would be controls.
The project on github contains an example of capturing the movement of the oculus through JNI, and i think it has a compatible license.
I think another appstate would be suitable for this, right? I don’t mind writing it, but i don’t have a c++ environment set up and need a 64 bit dll.
Wee… so cool.
I wonder if this is a problem with the test data or the morphing?
Netbeans has C++ support I believe.
Either way there are plenty of C++ compilers out there.
Someone needs to put the Occulus people in a room with these people: http://nlo-moto.ru/en
I will throw money at them.
I grabbed the code and tried to compile it to test/tweak with my rift but I’m getting the following:
It seems to be ignoring the viewport settings and rendering them both full screen size. Otherwise it works. Any ideas?