Issues with OVR SDK 0.4 and DK2

[renaudbedard]

Hi,

Just tried out this project with my new Oculus Rift DK2, and looks like there are a bunch of issues out of the box :

• Direct HMD mode (a new feature of SDK 0.4) is not supported
• Headtracking does not work, and changing aimmode to 1 doesn't seem to do anything either
• Performance seems to suffer... I haven't tried with a DK1, but even at 1280x800 on a DK2 I get sub-30 FPS. I tried to set the correct resolution (1920x1080, 75hz) and got even worse performance. I can run the game fine at 2880x1800 at well over 250fps with VR mode off.
• Kind of a given, but positional tracking does not work, the camera does not turn on

Let me know if I can help test builds!

[dghost]

Which branch/build are you using? Everything except for Direct-to-HMD works fine on my end with the pre-2.0 branch, and I'm working on fixing that tonight.

[renaudbedard]

Ah, I was on master, just grabbed the link from the README file. If I want to try out 2.0-pre, do I need to build from source or are there nightly binaries somewhere?

[renaudbedard]

I tried to build from source, succeeded through some hoops but the game crashes on start due to a gamma shader being null... so I'm probably doing something wrong. I don't want to spend your time debugging my compilation issues, so just let me know when you have a pre-2.0 build ready. :)

[dghost]

Yeah, sorry about that. The documentation is a bit out of date right now. I've been working towards preparing a new release in the next few days and was hoping to get Direct-to-HMD mode working first.

Sadly, Direct-to-HMD appears utterly broken with OpenGL right now, so I'll probably do a pre-release build within the next day to make up for it. Kinda bummed about that.

As far as the issues with shaders - the shaders are in the repository under the misc directory. You can probably copy the entire shader folder into the baseq2 folder to fix that issue, but there may be other files missing and/or absent that I'm not aware of.

[renaudbedard]

Copying the shaders folder over worked! If there are other missing assets they don't crash the game.

Everything works now (except Direct-to-HMD which you know about), the positional tracking doesn't seem buttery smooth but this may be because of my machine (GeForce 650M on an i7 Retina Macbook). I'll try things out!

[dghost]

That's interesting with position tracking - but unfortunately that's also something I have no control over. I haven't seen it locally, so I'll put together a binary today or tonight and see if that fixes it.

However, in the mean time you might try setting the Rift to be the primary display. It makes windows almost entirely unusable, but seems to resolve a lot of issues around vsync and software running on a secondary monitor.

[EricTw]

I was also able to build and run it from the branch yesterday, but it took a bit of fiddling to getting it to debug, thought I'd share in case it's useful (This is for Windows/Visual Studio Professional 2013.)

When trying to Debug from within Visual Studio, I found that the IDE starts with a different working
directory (not the one the .exe is in...the top level of the project?) so it couldn't find any of the .paks or shaders, etc. I was able to fix that by selecting the quakevr2 project, right clicking, selecting Properties, selecting "Configuration Properties/Debugging" and changing the working directory to "$(TARGETDIR)" At least this way running the .exe and running it through the debugger are using the same file paths.

Oh, also, I added OutputDebugString(string) to Sys_ConsoleOutput() in qcommon.h, which sends the very helpful log messages to VS's console window.

I'm sure there are cleaner ways for both but hey, at least it works :)

[dghost]

Good to know - thank you!

It's probably worth pointing out that, if possible, you should be building Retail/Release builds for just casual usage. They are significantly faster, and unless you expect to be debugging a crash it isn't worth the performance hit.

It's also worth mentioning that every time you build the game .DLL's you lose the ability to load save games from previous releases. So, uhh, yeah. Probably not a good thing to do frequently.

[renaudbedard]

Yep, positional tracking is much smoother, and I get more consistently 75hz with the rift as my main display. I set it as my only display and had no problems with the game. Thanks for everything!

Edit : Actually I did have to get the latest .PK3s from the KMQuake2 website. After doing that I stopped getting warnings on UI textures being missing.

[dghost]

In case either of you (or anyone else reading this) is interested - I've put together a pre-release binary here. You should just have to copy pak0.pak into the baseq2 directory, and the pak0.pak and gamex86.dll from any expansions into the expansion directories for it to work. Videos work too, if you feel like copying them into place.

I'm still trying to sort out Direct HMD mode, and haven't quite decided if I should hold releasing it until that gets fixed or not. It appears to be irreparably borked without going to SDK rendering, so I'm either faced with rewriting the OVR implementation to support that or holding the release until the next SDK drop and hoping it gets fixed. For some transparency, I've been avoiding using it because it means losing the ability to do things like fully support luminance overdrive (which is right now only available under specific circumstances in the DirectX SDK distortion path, and totally absent from the GL one). Still, it might be worth adding as an option.

Any opinions?

[SilentZero]

I'd say go for it. Seems solid so far even if direct mode isn't working. Most other games/demos are having the same problems.

[jf033]

NOTE: the most up-to-date thoughts are in the latest "edit #". I've not edited old text out.

Created an account to say that positional tracking in the pre-release binary seems to remain, at least up to a certain point, with the world instead of the player view, so that it stays the same direction when using the mouse to turn the character. For example, if I reset postional tracking, then turn my view left 90deg with the mouse, the positional tracking is still pointed in the original direction, so if I lean forward, I'm leaning to my right in-game. It looks like it just needs to be updated with control input.

edit: actually, it looks like it isn't directly connected to the world, but just gets oddly skewed after I turn. I tried turning to the left ~90 degrees with the mouse, then leaning forward, and in-game I was leaning forward-left.

edit 2: it looks like it is attached to where the arm model is, instead of the camera. If my "arm" is to the left, so does my leaning in skew to the left. If my arm is furthest right, leaning forward works correctly.

edit 3: I'm trying different aimmodes. Only 1 sorta does what I want, but for some reason, the positional tracking on mode 1 feels "curved" somehow, like my forward movement is being curved down (pitch-wise), my side movement is being curved yaw-wise, etc. (or perhaps the camera in aimmode 1 isn't moving enough relative to how much I'm actually moving my head). Maybe the tracking is getting skewed again after mouse movement. I've made myself feel a little sick while playing around with these modes, hah, so I'm going to take a break.

edit 4: it is usually a problem of being attached to the arm yaw angle vs. just being attached to the camera angles. I noticed that there was a virtual reality menu, and in every mode, if the angle of the arm relative to the camera changes tracking, acting as if the arm were the head instead of the camera view. But even in the modes where the arm doesn't move relative to the camera, I still get odd behavior when I look far enough left or right, with the camera "swinging around" in such cases.

[renaudbedard]

Chiming in to say that yesterday's binaries work great, but I also experience what jf033 is talking about. I thought it was my setup (my camera isn't facing my directly and that causes some inconstancies) but after playing for a while I definitely feel that the positional tracking works wrong, moving left/right sometimes makes me move forwards/backwards or in a skewed way.

[dghost]

Interesting.

@jf033 and @renaudbedard - I appreciate the detailed reports. And you are correct, it is applying the position offset relative to the aim vector incorrectly. I just pushed commit cf0e3a7 which now applies it in a way that should always be correct relative to the head orientation, and hopefully will fix the issue. A patched executable can be found here.

If this doesn't solve it, let me know. A full fix might involve having to suck it up and rewrite input handling sooner than I wanted, but hopefully not.

[jf033]

Works perfectly now! Thanks so much for your work on this.

Is there a way to disable the output stream of aiming data? Both of the vr_*_debug cvars are set to 0.

[dghost]

Whoops! Thought I removed that before compiling it. Here's a new binary with that removed: http://dgho.st/A72L

[davexoxide]

No head tracking for me. Blue light on camera is on.

Installed game from CD. Downloaded Binaries, then copied over pak0.pak, then players, videos
Tried all possible VR display options. Nothing changes there, all other options seem to be working fine.

Windows 8.1
NVIDIA 750M
16GB Ram

[dghost]

Are you using the 1.9.2-pre release linked in this thread (and now on the home + release pages), or the old 1.3.1 release?

[dghost]

I'm going to close this issue since it's gone way off topic from where it originally was. I've created a new issue so I can keep an eye on headtracking problems, so if it's an issue please comment over in #6.

Thanks.