Hmm, i have no idea actually. I’ll have to look into it over the weekend.
In other news; i’ve created an engine-agnostic JNI that seems to be working. I’ll post the results in a bit, and then implement it with the rest.
I wonder if this is a problem with the test data or the morphing?
No, i think that is just two badly uv-mapped tri’s.
I don’t know what it could be, but just to make sure it’s not due to something not being initialized properly yet, could you try to attach it in a callable?
Like so:
[java]enqueue(new Callable(){
public Object call() throws Exception {
stateManager.attach(oas);
return null;
}
});[/java]
That should make sure it’s attached after the system is initialized.
I’m grasping at straws here…
<cite>@rickard said:</cite> I don't know what it could be, but just to make sure it's not due to something not being initialized properly yet, could you try to attach it in a callable?Like so:
[java]enqueue(new Callable(){public Object call() throws Exception { stateManager.attach(oas); return null; } });[/java]That should make sure it’s attached after the system is initialized.
I’m grasping at straws here…
The only case you would have to do this is if you are overriding the never-to-be-used stateAttached() method. Otherwise, AppStateManager is thread safe and won’t do the initialize() until the next update pass… which is exactly what it would do if you enqueue.
Hey.
I’ve pressed on a bit and blindly integrated the wrapper, and a better testbed for the oculus. It also meant i had to make a new camera control and modify the one in the engine (a few private to protected variables). Again, i’ll post the code once i’ve cleaned it up, right now it’s just functional.
I used TestBetterCharacter as a start, since i wanted a moving character, added anims and some more stuff for better immersion. Still, you have to live with being a monkey, for now. I also detached the view direction from the walking direction so that you can look freely. Note: You can sometimes see parts of the head as you look around.
If anyone wants to test it (it works without the Oculus), it’s here: http://www.mindemia.com/temp/OculusRiftTest.zip
Instructions:
If you run it from the command prompt, you should see “Initializing rift…” if it tries to connect to the hardware.
If it fails you should see an exception, but it will still carry on and apply some fake values to the distortion filters.
I’m interested in seeing if others have the same problem with the viewports as magneon.
/Rickard
1 Like
I have a rift and getting the following exception, running your jar. I did nothing but extract it to a directory and start it using java -jar. I’m running Win 7 Pro 64bit.
java.lang.UnsatisfiedLinkError: C:\Users\ilo\Downloads\jmonkey\lib\OculusLib64.dll: Can't find dependent libraries
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(Unknown Source)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at oculusvr.input.OculusRiftReader.<clinit>(OculusRiftReader.java:129)
at oculusvr.StereoCamAppState.initialize(StereoCamAppState.java:68)
at com.jme3.app.state.AppStateManager.initializePending(AppStateManager.java:251)
at com.jme3.app.state.AppStateManager.update(AppStateManager.java:281)
at com.jme3.app.SimpleApplication.update(SimpleApplication.java:238)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:151)
at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:185)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:228)
at java.lang.Thread.run(Unknown Source)I did some manual mending on the lib path, that might be it. I’ll look into it tonight. Also got a report i got the rotation directions wrong.
I also forgot to mention it’s possible to change the cam distance with the + and - buttons.
Edit: uploaded a new build. Hopefully fixed the rotation issue, and possibly the .dll business. If someone can say the correct way to link .dll’s to a project, please step in!
/Rickard
You can mimick JME’s natives handling.
Basically, it keeps the .dll as a Java resource inside the jar, unpacks it to some local directory (which needs to be writable), then tells the JVM to load it.
I don’t know the class names involved off the top of my head, but I remember there was an unpackNatives function near the core of it all.
You might want to hijack JME’s definition of the native directory to use.
JME also shows how to deal with the multi-platform situation, so the path on that route should be clear.
1 Like
Ok, thanks, i’ll look into it.
In the meantime; I’ve published the JNI code on my dormant blog, as i felt it was appropriate to the theme. http://www.softwarepioneering.com
I’ll start formalizing the jme code now as well.
Now that I’m at my JME workplace, I can give more details.
The JME class doing it all is com.jme3.system.Natives.
You could call Natives.getExtractionDir() to determine where to put the Rift libs.
Natives.extractNativeLibs(Platform platform, AppSettings settings) is the entry point, which dispatches to extractNativeLib(String sysName, String name, boolean load, boolean warning) depending on the Platform setting.
The platform can be obtained from com.jme3.system.JmeSystem.getPlatform().
Hope this gets you going.
1 Like
Worked beautifully, thanks!
Uploaded new version.
So what happened?
Delayed shipment happened. 1-2 months turned to 4 months, and i got my rift yesterday.
Noted i had flipped the projection offset, so the images didn’t converge. Still have some smaller issues to take care of. Hopefully i’ll have a new release this weekend.
Coincidentally, today is the last day to register for the oculus rift vr jam.
I won’ t have the time, i think, but if you’re lucky, there might be some jme tools done in time for it 
Sidenote:
I guess a niche feature like this won’t make it into core. What’s the best option if you want it easily available. A plugin?
1 Like
Cool Rickard!
Yeah a plugin would be the best way IMO.
I have a feeling that in year or two we can have a good laugh at ‘niche feature’ statement 
Yeah a LOT of people are excited about the rift.
Well, it’s an extra piece of hardware to buy, and it’s costing real money.
So this is more for hardcore gamers, I don’t see it becoming relevant for casual gaming unless the hardware goes down to, say, 20 dollars, max (10 dollars would be better).
The other thing that makes it non-casual is its sheer bulkiness. It’s too large for carrying it around in a suitcase, and it takes up real space in storage. This will improve over time, but I’m not holding my breath.
The other thing is that Nvidia has started work on its own idea of an immersive headset. It sounds whacky since it’s doing lightfields (i.e. transmit not just pixels but directional information), they’d have to get a huge data transfer rate working - unless they get something ridiculously ingenious to work, they’ll need fiber optics for that.
Still, Nvidia could build a competitor to the Oculus. If the worst happens, investors will withhold funding for Oculus in the expectation that Nvidia will soak up that particular market, but then Nvidia fails to complete the thing - that could easily delay general adoption of the technology by as many years as a competitor would need to prototype, test, and mass-marketize such a thing from scratch.
Neither issue will kill the Rift, and it’s still fascinating technology, the first prototype of how this can be made to work.
It’s still a couple of years away from being standard equipment such as, say, speakers. Which limits the market for selling software that makes use of the technology.
Now if using the Rift is easy as pie, developers will support it anyway. It would be nice to see that happen.
A plugin would be nice because it could evolve separately… ie: it doesn’t have to wait for JME’s (these days glacial) update schedule just to get a new version out.
I can remember paying more than $1000 for my last VR helmet… and the resolution was horrible. Lots of fun, though. I look forward to getting a Rift someday.
I believe OVR’s success is far from certain. With some 30k devkits in existance and no consumer kit announced yet, they have a long road ahead of them. Any support in bigger titles in the next year or so will not come commercial interests, but because the dev’s want to see their own game in 3d. It will remain a “niche feature” for quite some time i think 
Whether the casual market will ever adopt it depends on a number of things…
For a price point, i think the Kinect has proven casual players are willing to pay >$100 for a peripheral controller. The OR has the same problem 3d screens has though, each player needs to have a HMD to play. So it will probably not be a “living room” piece of equipment.
For immersion, sound also plays a huge role, so you would probably need to pay a few bucks for a decent surround headset as well.
There’s also the problem with motion sickness to overcome for it to appeal to a broader audience.
In the short term, my hope is that this will open up the market for cheaper visualization technology.
Hi, just got my rift yesterday as well. I managed to enter into the contest. Not sure if I have enough time either, but I’m going to be trying out jMonkey for it. At first the rules were hazy about what engine you could use but they’ve now clarified that anything goes. I’m interested in using your release for my project, if you don’t mind me doing so (I’ll add you in the credits!). Right now dealing with nausea is the biggest part with the screen-door effect the 2nd. I’m getting better about it with every hour I spend though, so it’s all good. TF2 so far is the most comfortable experience for me.
Certainly.
It proved to be more difficult than i thought to fix my “minor issues”. But i have some new leads now that i’m going to try.
Unfortunately, the initial head tracking tests showed quite a big latency, which probably won’t improve the nausea effects. Perhaps there are optimizations to do.