Oculus Rift Support

User Code & Projects virtual-reality
181
@toolforger said: That OVR:: thing is just a namespace qualifier. Namespaces are C++'s equivalent of package names.

Ptr<SensorFusion> is a template, which is C++'s way of doing generics. I read the error message as “you’re dealing with a Ptr here, which does not have a Reset() function”.
I suspect the correct code would be using pFusionResult->Reset() instead of pFusionResult.Reset().

That did the trick, thanks! @rickard, may I be added to the SVN so I can commit changes? I have the input file compiling correctly, and it should compile on Windows too (I removed the platform-dependent includes). I did have to make a change to the OculusSDK (that Release() in the deconstructor) for some reason, though (but it doesn’t seem to be related to your code).

Also, what is the status on the “non-ideal” situations, like the left camera being the center when rotating etc.? I’d like to get all that fixed if those problems still exist.

1 Like
182

Great. Ofcourse, send me your login and I’ll add you.
The basic usage of the Oculus should work fine in jMonkeyEngine now. There are some issues with some of the filters, most notably, I haven’t gotten the reflections in the post water filter working correctly yet.
Then there’s the more serious issue where I, at least, have problems using the project in some ways (the problem i described earlier). In this case, you’ll get the “OculusRift can’t be initialized” if it’s not created inside a static context. Maybe your change will change that.

183

My login is phr00t at gmail dot com – is that all you need?

I noticed all of your modified classes use the same name as the standard jME3 ones, like DirectionalLightShadowRenderer. I assume to use these, I just need to change what imports I use? Would it make more sense to have an OculusDirectionalLightShadowRenderer, that extends DirectionalLightShadowRenderer, so we don’t need to mirror similar code and manually merge in updates from the standard DirectionalLightShadowRenderer?

I also think having different classes for the Oculus versions will make them play nicer when used side-by-side… like for a game that has a “Use Oculus?” option.

184

Done.

I don’t know. I created the project with seamlessness, and ease of use, in mind, the classes are fully backwards compatible and the package names are intact. Just so that you can simply add the StereoCamAppState and don’t have to do anything else.
My idea was that the sources in the plugin would take precedence over the engine ones. A bit more to maintain when changes occur, but it should be less of a hassle from a user point of view.

Thoughts?

185

Thanks – I committed my changes. When rebuilding the project, I noticed I had to comment out the loadproperties section in build-impl.xml:

[java] <target depends="-pre-init,-init-private,-init-private-libraries" name="-init-libraries">
<!–loadproperties encoding=“ISO-8859-1” srcfile="${libraries.path}">
<filterchain>
<replacestring from="$${base}" to="${libraries.dir}"/>
<escapeunicode/>
</filterchain>
</loadproperties–>
</target>[/java]

Not sure what that is about or if that should be committed…

Also, I had to comment out a ((WaterFilter)filer).clone(); line in StereoCamAppState, since it didn’t look like that method existed(?).

Regarding the class names: I understand what you were going for, and after reading the Wiki, I thought “ooo this is easy!”. So, I believe the intent was good. However, I think it may cause more confusion when the class names & namespaces clash… I can picture people posting code and always having to mention, “make sure you are importing the Oculus libs, not the jME3 libs!”.

In 4089, I’m most likely going to want to have a non-Oculus mode, where I use the standard DirectionalLightShadowRenderer, and an Oculus mode where I want your DirectionalLightShadowRenderer… if we had an OculusDirectionalLightShadowRenderer, then I could do something like this easily:

[java]
DirectionalLightShadowRenderer myShadows;
if( oculus_enabled) {
myShadows = new OculusDirectionalLightShadowRenderer();
} else {
myShadows = new DirectionalLightShadowRenderer();
}[/java]

Also, I think as we add more Oculus code, maintaining the base code we are duplicating will become more of a chore & potentially introduce bugs. Developers will have to take into consideration lots of things when moving a game from non-Oculus to Oculus, and having to specify using Oclulus classes (like OculusDirectionalLightShadowRenderer) will verify they are using the right code where it is needed, in my humble opinion.

186

OK, I committed some changes to clean up the namespace. Give it a look over & let me know if everything still works on your end. It really didn’t change the simplicity for the end user, as seen in the minimal changes to the test cases. However, the refactoring completely got rid of the need of our own CameraControl, which was a 1:1 duplicate. OculusDirectionalLightShadowRenderer has been reduced by about 90%, since it only really needs the clone() function. I like it!

187

Looking over the OculusDirectionalLightShadowRenderer, shouldn’t it include a second DirectionalLightShadowRenderer, so you don’t need to define two of these renderers like in TestDirectionalLightShadow.java? You could just define the OculusDirectionalLightShadowRenderer, and it would also create the second shadow renderer for the second eye. You could have a .sync() function that passes all the settings from the first renderer to the other (which would have to be called after any & all changes were made to the OculusDirectionalLightShadowRenderer).

EDIT: WWWaaaaiiittt, one is a DirectionalLightShadowFilter, while the other is the OculusDirectionalLightShadowRenderer… everything I said in this post is probably wrong / misinformed. :stuck_out_tongue: I suspect we only need one renderer & it is handled by having two cameras, correct?

188

@phr00t the TestDirectionalLightShadows has a Renderer and a filter initialized yes. that’s for testing purpose only (I needed to switch between them at runtime).
You only need one in a game.
I’m sorry this thing has already been misleading for numerous people. I need to do something about it.
I’ll probably put a big warning in the comments.

189

Sorry, but I’m really busy nowadays, so I don’t have time to review your suggestions or changes. It’s been so long since I wrote those classes, so there could be temp stuff there that was never removed.
I think it’s fine if you change things though, as not that many are using the lib now anyways. Just try to keep in mind that the philosophy is that it should be as plug and play as possible for the user. I’d also prefer if the switch between normal and oculus mode can be done in real time.

190
@rickard said: Just try to keep in mind that the philosophy is that it should be as plug and play as possible for the user. I'd also prefer if the switch between normal and oculus mode can be done in real time.

I have already mentioned it, but have you looked at new version of oculus lib? It is a lot more invasive and will probably require rethinking a bit of the integration solution. On good side, API seems to be get more streamlined, I suppose it should be possible to generate reasonable bindings with SWIG.

191
@nehon said: @phr00t the TestDirectionalLightShadows has a Renderer and a filter initialized yes. that's for testing purpose only (I needed to switch between them at runtime). You only need one in a game. I'm sorry this thing has already been misleading for numerous people. I need to do something about it. I'll probably put a big warning in the comments.

OK, thanks. We can probably just remove OculusDirectionalLightShadowRenderer… the only difference with DirectionalLightShadowRenderer is the clone() function, but it isn’t used in any of the test programs…

@rickard said: Sorry, but I'm really busy nowadays, so I don't have time to review your suggestions or changes. It's been so long since I wrote those classes, so there could be temp stuff there that was never removed. I think it's fine if you change things though, as not that many are using the lib now anyways. Just try to keep in mind that the philosophy is that it should be as plug and play as possible for the user. I'd also prefer if the switch between normal and oculus mode can be done in real time.

OK, understandable. I have the same philosophy! I hope you do stick around as much as possible, I may need your help from time to time!

@abies said: I have already mentioned it, but have you looked at new version of oculus lib? It is a lot more invasive and will probably require rethinking a bit of the integration solution. On good side, API seems to be get more streamlined, I suppose it should be possible to generate reasonable bindings with SWIG.

I haven’t looked at the new API yet… they don’t have a Linux build yet & I don’t have a developer kit yet (waiting on the DK2). However, all that has been added theoretically is the positional head tracking due to the camera… things like head rotation should be the same. Where do you see more invasive stuff?

192
Where do you see more invasive stuff?

Distortion is not a simple shader anymore:

We now support two approaches to rendering distortion: SDK Distortion Rendering and Client Distortion Rendering. SDK Distortion Rendering will be the recommended approach going forward as it gives us the most opportunity for future optimizations and benefiting from evolving hardware. In this mode, the application renders stereo views into one or more render targets, and then the Oculus SDK takes care of distortion rendering, frame timing, buffer swap, and GPU synchronization. Client Distortion Rendering now uses a mesh for rendering distortion instead of a coefficient-driven pixel shader. The distortion function is encoded into the UVs of the distortion mesh, thereby moving much of the complexity inside the SDK.

API has completely changed

Reorganized all HMD and sensor interfaces to be exposed through a simplified C API. The new API makes it easy to use LibOVR from other languages.

Timewarp

Introduced a new technique called Timewarp to reduce motion-to-photon latency. This technique re-projects the scene to a more recently measured orientation during the distortion rendering phase.

I feel that new distortion mechanism + timewarp support might require some basic changes in approach. API change is probably less disruptive, will be mostly small refactoring.

193
@abies said: Distortion is not a simple shader anymore:

API has completely changed

Timewarp

I feel that new distortion mechanism + timewarp support might require some basic changes in approach. API change is probably less disruptive, will be mostly small refactoring.

Welp, we should still be able to use our shader until we figure out how to integrate the SDK’s Distortion Rendering method. I will have to look more into Timewarp, too. However, these are things that will improve the experience, not break what is currently implemented.

Do you have an Oculus Rift and/or are you looking at contributing to this project directly?

194
@phr00t

OK, understandable. I have the same philosophy! I hope you do stick around as much as possible, I may need your help from time to time!

No worries, I’m not going anywhere. It’s just the upcoming month that is quite hectic.

I haven’t looked at the SDK but I hadn’t thought the differences were that big. Good in a sense since it’s improving the decent experience.
Now I must take a look at it.

Edit:
It seems quite well documented.

195

Also, I plugged jMonkeyEngine & the work we are doing here on reddit’s Oculus community:

http://www.reddit.com/r/oculus/comments/254kku/phr00ts_software_jmonkeyengine_building_a_free/

@rickard said: No worries, I'm not going anywhere. It's just the upcoming month that is quite hectic.

I haven’t looked at the SDK but I hadn’t thought the differences were that big. Good in a sense since it’s improving the decent experience.
Now I must take a look at it.

Sounds good. Did you pre-order the DK2?

196
@phr00t said: Sounds good. Did you pre-order the DK2?

Nah. I’ve hardly used the DK beyond this lib. I haven’t really had time as all my spare time has gone into the cookbook I’m writing. Maybe when that is finished I can do some project on my own again :slight_smile:
I’ll most likely stick to the DK and get the consumer version whenever that is out, given that there is a decent amount of games supporting it (or just the one which I must have)

197

Pretty big update. I also updated the wiki to better explain how to use the library. Basically, if people want to use it just as JAR libraries, they need to add both (now called) oculus-natives.jar & the built project JAR, JMonkeyOculusRift.jar (which includes the shaders now). Once I set it up this way, it was much easier to get Oculus support added into my game, 4089:

1274×718

I also added an option to swap the cameras, so it is easier to go crosseyed and see the 3D effect without an Oculus Rift. I fixed the crashes that would happen if you didn’t have an Oculus Rift hooked up.

Looks like some filters are still having trouble, haven’t narrowed it down yet but when I use FXAA, SSAO & the translucent bucket filter, things break (causes stuff to be double-rendered on the left viewport).

2 Likes
198

Great work!

Yeah, filters require some work. I thought I had fixed most of the common ones, except the water filter.

199

Thanks rickard!

I committed some more updates today. I was having trouble with shadows rendering on top of geometry in just the right viewport, so I made sure the shadows get added first in the processor list which fixed the problem for me. I also added my BasicSSAO implementation into the library, since it runs much faster than the jME3 one & I needed to have it automatically cloned. So, people can use the built-in BasicSSAO if they want & it will work :slight_smile:

At some point in the future, would you be willing/able to test out 4089 on your DK1 while I await my DK2? :slight_smile:

200
@phr00t said:

At some point in the future, would you be willing/able to test out 4089 on your DK1 while I await my DK2? :slight_smile:

Certainly! Let me know when it’s ready to be checked out.
I’ll also sync up you changes as soon as I get some time on my hands. In a couple of weeks time I hope to take a closer look at the SDK changes, too.

/Rickard