@yombo said: SDK distortion and rendering works without a Rift, it is also my case :)
Good. In that case, any idea on what I’m doing wrong? 
Do you have any code we could look at to see how you initialize things, @yombo? Have you seen that error before? Any help is greatly appreciated!
@phr00t said: Good. In that case, what am I doing wrong? :( Do you have any code we could look at to see how you initialize things, @yombo? Have you seen that error before? Any help is greatly appreciated!
Sure! The latest code of my engine is available in Antares / Code / [r260]
That project has old releases but if you check out the svn code you’ll have it all.
Though the code and comments are in Spanish :facepalm:
My Oculus native library is called JYOculusLibrary and I did it in English. You’ll find the native code under /bridj directory.
I use Eclipse so if you can install it it will be easy to load the project and find where are the calls to JYOculusLibrary.java
Enjoy the reading 
Edit: About the error, sorry I don’t recognize anything
@yombo said: Sure! The latest code of my engine is available in http://sourceforge.net/p/antaresgame/code/HEAD/tree/That project has old releases but if you check out the svn code you’ll have it all.
Though the code and comments are in Spanish :facepalm:
My Oculus native library is called JYOculusLibrary and I did it in English. You’ll find the native code under /bridj directory.
I use Eclipse so if you can install it it will be easy to load the project and find where are the calls to JYOculusLibrary.javaEnjoy the reading
Thanks! Looks like the meat of your code is done in C++. I’m looking over things here:
http://sourceforge.net/p/antaresgame/code/HEAD/tree/bridj/JYOculus/Linux/JYOculus.cpp
@phr00t said: Thanks! Looks like the meat of your code is done in C++. I'm looking over things here:
Yes that’s the implementation. Can you see the pattern of calls? Some methods must be called before calling some data retrieving functions.
@yombo said: Yes that's the implementation. Can you see the pattern of calls? Some methods must be called before calling some data retrieving functions.
Where is the code that calls these implementations…? A little lost, sorry 
@phr00t said: Where is the code that calls these implementations..? A little lost, sorry :|
This class is the binding to java to JYOculus:
/src/org/yombo/humanInput/oculusRift/JYOculusLibrary.java
These classes use the previous one:
/src/org/yombo/motor3d/oculus/GestorOculus2.java
/src/org/yombo/motor3d/oculus/DestinoRenderCamaraOculus.java
/src/org/yombo/motor3d/PuertoVisual.java
GestorOculus2 does the initialization.
I think your Filters in jmonkey are similar to my DestinoRender, they have two functions called prior and after the rendering.
Also in PuertoVisual there’s the main Begin… and End… Oculus frame function calls.
I GOT IT WORKING! (thank you yombo for your help!)
I needed to call configureRendering in the rendering thread, not the Rift’s initialization before the jMonkeyEngine app gets started.
I checked in all my changes and got rid of StereoCamAppState, now it just has OVRAppState.
HOWEVER, no GUI elements work. They all disappeared 
Maybe the filter is being applied before the GUI elements get rendered…? Something else might be going on…? Have to go to sleep now, but great progress…
@phr00t said: I GOT IT WORKING!I needed to call configureRendering in the rendering thread, not the Rift’s initialization before the jMonkeyEngine app gets started.
I checked in all my changes and got rid of StereoCamAppState, now it just has OVRAppState.
HOWEVER, no GUI elements work. They all disappeared
You’re welcome Yeah we mentioned it earlier with Rickard, that the configureRendering makes OpenGL things and need to be in the render thread. Perhaps you refactored without knowing that.
Sorry about the GUI, I can’t help on that.
Hmm, TestSkybox and TestStereoCam’s should have the correct initialization. It’s been separated into two methods. initialize should be called from within the application. initSensors from outside.
I don’t know why it has to be like that and i hope it’s possible to fix.
Sorry if your fixes didn’t make it in, it seems like i was using the StereoCamAppState from the old package when i started the OVRAppState (don’t ask me why).
I noticed the gui too, but forgot to mention it. I’ll put it on priority to fix it so we’re back to the old functionality.
I was able to fix everything, except the GUI not showing (haven’t looked into it though, just noticed it before bed), so make sure you “svn update” before making more changes.
I moved the configureRendering call inside the OVRAppState initialization, so end-users will only need to perform the first static initialization & the OVRAppState will take care of the rest – I updated the Wiki to explain:
https://code.google.com/p/jmonkeyengine-oculus-rift/wiki/HowTo
GUI is working and commited.
Added support for other than the native rift resolution.
This is probably as much as I have time for the next week.
There’s one issue nagging still, related to the projection, I believe: Objects near the edge of the fov disappear. I think it has to do with this:
[java]Matrix4f projMat = OculusRiftUtil.toMatrix4f(Hmd.getPerspectiveProjection( eyeRenderDesc.Fov, 0.1f, 1000000f, true));
vp.getCamera().setProjectionMatrix(projMat);[/java]
Everything looks right, though.
About the GUI… I do see the GUI elements now, but they are not distorted. Looks like you made the GUI elements visible by making them render after the distortion filter is applied… but they should be distorted, correct? Might be how the GUI elements are being projected, perhaps, that makes them not show up in the distorted camera & filter.
I’m also noticing culling happening around the edges of the view, and unfortunately, 3D objects go completely missing in 4089 on the left camera:
Stuff on my main menu does show, though. I also do see 3D geometry in the TestStereoCams in both cameras. Not sure why things just go blank when entering the game on the left camera…
Yeah.
Seems there are still some issues with the frustrum (i initially tested only with the skybox).
Some progress, but it’s not quite right yet.
And btw. The GUI didn’t have distortion previously either (did it??). Anyways, it should be possible to add with additional filters.
I think the reason the scene only shows up in one eye is one of the post filters. I noticed the same when using post water.
Nice job you guys. I’m anxiously awaiting my DK2 to try out work you’re doing!
The GUI wasn’t distorted previously, but I didn’t notice until now since the distortion seems so different now. I wonder how bad it looks now without distortion in the Rift… I’ll work on fixing the black left eye, and then I’ll PM you a link to download an Oculus Rift-enabled version of 4089 if you’d be willing to try it out – tell me how the current GUI looks (and everything else) 
tom,
http://code.google.com/p/jmonkeyengine-oculus-rift/wiki/HowTo
What revision did you check out? The current revision is v84. It is expected to add the jme3 libraries to run the test programs, but you should already have those added for your own project. What things did you need to comment out?
That might have something to do with the http loader that tries to download the scene remotely, perhaps? That should work in 3.0 stable, though… :\
Fixed the FOV culling problem – I had to set the FOV frustrum of the camera before the filters get created. I have it set to 120 degrees, which seems to work pretty good. I also set the near and far frustrum to 0.1 and 512 respectively, which works good for 4089. However, games with stuff very far in the distance might have issues, but increasing the far frustrum may increase Z fighting problems.
I also fixed the filter problems I was having by always creating a FilterPostProcessor and making sure the order is set correctly. Funny enough, fixing the FOV frustrum also made some of my filters work better.
The only issues remaining that I am aware of:
If a filter or processor gets removed or disabled after it was added to the created Oculus Rift views, things break. This happens, for example, when a user changes their effects options in the main menu (e.g. turns off ambient occlusion). There needs to be some way to easily sync changes to the “primary” processor in the other view. I was thinking on making an OculusRift.syncEnabledFilters() function of sorts that could be called after any changes were made.
GUI distortion. Do we need it or not…? I’ll PM @rickard with a link to my latest 4089 build, which has some GUI implemented that does have distortion. Curious how it looks on the DK1… I am aware the current GUI uses the mouse, which is a Rift no-no – a fix is on the to-do list.
http://code.google.com/p/jmonkeyengine-oculus-rift/source/detail?r=85
@phr00t said: Fixed the FOV culling problem -- I had to set the FOV frustrum of the camera before the filters get created. I have it set to 120 degrees, which seems to work pretty good. I also set the near and far frustrum to 0.1 and 512 respectively, which works good for 4089. However, games with stuff very far in the distance might have issues, but increasing the far frustrum may increase Z fighting problems.I also fixed the filter problems I was having by always creating a FilterPostProcessor and making sure the order is set correctly. Funny enough, fixing the FOV frustrum also made some of my filters work better.
The only issues remaining that I am aware of:
If a filter or processor gets removed or disabled after it was added to the created Oculus Rift views, things break. This happens, for example, when a user changes their effects options in the main menu (e.g. turns off ambient occlusion). There needs to be some way to easily sync changes to the “primary” processor in the other view. I was thinking on making an OculusRift.syncEnabledFilters() function of sorts that could be called after any changes were made.
GUI distortion. Do we need it or not…? I’ll PM @rickard with a link to my latest 4089 build, which has some GUI implemented that does have distortion. Curious how it looks on the DK1… I am aware the current GUI uses the mouse, which is a Rift no-no – a fix is on the to-do list.
Google Code Archive - Long-term storage for Google Code Project Hosting.
Sweet! I’ll sync up the changes and verify.
I think we need GUI distortion, or whatever is the convention. It should be easy enough to add.
Looking forward to testing 4089.