search

dghost / quake2vr

Quake II for Oculus Rift
114 stars 13 forks source link

Issues with OVR SDK 0.4 and DK2 #5

Closed renaudbedard closed 10 years ago

renaudbedard commented 10 years ago

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 :

Let me know if I can help test builds!

dghost commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 cf0e3a7b787865ef96d22fcf35c8c2eaed9f5c42 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 commented 10 years ago

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 commented 10 years ago

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

mrdavidburns commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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.