26

Re: Neverball and Neverputt for the Oculus Rift

Cheeseness wrote:

Something else you mentioned that's worth highlighting is that with this implementation, the HMD itself isn't a limiting factor, unlike the other stuff I've played so far where it comes a bit of a handicap.

The HMD is a handicap in other stuff you've played? Like what?

27 (edited by Cheeseness 2013-08-04 00:10:06)

Re: Neverball and Neverputt for the Oculus Rift

rlk wrote:
Cheeseness wrote:

Something else you mentioned that's worth highlighting is that with this implementation, the HMD itself isn't a limiting factor, unlike the other stuff I've played so far where it comes a bit of a handicap.

The HMD is a handicap in other stuff you've played? Like what?

Mostly first person shooters (TF2, Quake, Descent, whatever demo thingy that had with Game On was, etc.). TF2 on the Rift was the first FPS I'd tried which didn't use headtracking for aiming (and which offers a bunch of different implementations to try out), but the even with that decoupling, lower resolutions, chance for disorientation, queasiness that others report, more potentially distracting visual latency/judder stuff, etc., not to mention the Rift's narrow region of focus, still make for a disadvantage/skill reduction.

Cheese
==========
cheesetalks.net

28

Re: Neverball and Neverputt for the Oculus Rift

Oh, yeah okay, anything where you aim using your nose is terrible terrible terrible. The vehicle-based weapons in Half-Life 2 are like that, even though the mouse position is going completely unused. It's impossible. (And it doesn't calibrate correctly.)

But in general, I really enjoy first person shooters that disconnect the look from the aim, like TF2. I feel empowered when I can look around independent of the gameplay. My situational awareness is much higher, and of course my immersion is deeply enhanced. When head tilt properly peeks around corners, it'll be amazing.

For this reason, I'm quite sure that using the Rift tilt sensor to tilt the floor in Neverball would suck. This hypothesis will be easy to test.

29

Re: Neverball and Neverputt for the Oculus Rift

rlk wrote:

Oh, yeah okay, anything where you aim using your nose is terrible terrible terrible.

For sure.

rlk wrote:

But in general, I really enjoy first person shooters that disconnect the look from the aim, like TF2. I feel empowered when I can look around independent of the gameplay. My situational awareness is much higher, and of course my immersion is deeply enhanced. When head tilt properly peeks around corners, it'll be amazing.

This is the thing though - TF2 (for example) was never designed with leaning in mind. There would be fundamental gameplay implications when adding such a thing in which could dramatically change the way the game works (alright, dramatic may be over the top, but it would impact on balancing, which is something that Valve already struggle with).

I don't feel like I have significantly greater situational awareness (I can twitch my mouse around to keep an eye on the battle much more and much faster than I can move my head). The potential for disorientation (or misorientation as a term for knowing where you are situated and your direction, but having no idea where your reticle is) would, IMO, balance out that benefit anyway. The Rift's narrow area of focus also costs you the rapid movement of your eyes. I definitely enjoy playing TF2 on the Rift, but if I want to play for winning rather than enjoyment, it's definitely going to hinder, and I don't believe that that's something that more HMD playtime is going to change.

Our implementation in Neverball however, doesn't feel like it suffers from these issues (or the ones I mentioned earlier) so much, and if you keep your head still, the game plays as it always does. Unlike TF2 (still using that as our example), the player's means of controlling and interacting with the game has not changed - instead, we've added an extra layer of perception on top without undermining any existing experience/skills or requiring the learning of new controls.

On a side note, I would be super interested in playing Thief 1 and 2 with headtracking (and a HMD). Those games' sense of claustrophobia and slower pace seem like a much better match to me. Personally though, I think that cockpit simulators (driving games, flight sims, mech sims) are where HMDs will feel most comfortable and natural, and I hope that consumer accessible devices will help give those genres better visibility and popularity (judging from the hype surrounding Hawken and Star Citizen, I think that's totally likely big_smile ).

rlk wrote:

For this reason, I'm quite sure that using the Rift tilt sensor to tilt the floor in Neverball would suck. This hypothesis will be easy to test.

Yup. I totally expect it to be uncomfortable and unwieldy - as I said earlier, the reason I'm fiddling with alternative implementations in Neverball is not because I believe it will directly result in any improvement for Neverball, but because exploring the dead ends can help give extra insights into what's good and bad about what does work.

Cheese
==========
cheesetalks.net

30

Re: Neverball and Neverputt for the Oculus Rift

Oh, by the way, I had a chance to test out the Windows build at a friend's place. He was pretty impressed, but it was his first HMD experience and I think he was just blown away in general.

Cheese
==========
cheesetalks.net

31

Re: Neverball and Neverputt for the Oculus Rift

I've made a number of improvements to the HMD branch.

I've modularized the HMD implementation to support different backends. I wanted to be able to compare OpenHMD with LibOVR directly. Both of these are fully supported now, and there's a null backend that's used when neither is selected at compile time. Any code shared by all backends is factored out into a separate module, so it's easy to make improvements across the board.

LibOVR does a better job of providing configuration information, so that backend will adapt well to different hardware. As of now though, OpenHMD configuration consists of hard-coded values that were previously reported by LibOVR for the 7'' Oculus DK1.

Both backends function correctly without an actual HMD connected, so you can test even with no device just by enabling the HMD option in the configuration.

I've also implemented the chromatic aberration correction shader. It looks great. This code lives in the common module, so both OpenHMD and LibOVR benefit from it.

The major difficulty in the LibOVR backend implementation lies in the fact that LibOVR is a C++ class library. Thus, I've had to add a C++ build rule and configuration to the Makefile. This is ugly. It pulls in the C++ standard library. There's a bit of hackage in the Makefile at accommodate this. This alone is a sufficient reason to favor OpenHMD.

Given 3 platforms (Linux, OSX, Windows) and two backends (OpenHMD, LibOVR) there are six run-time configurations. I have tested five of them, as I could not get LibOVR to link using MinGW. Maybe Parasti's cross compilation method will succeed.

Anyway, the HMD implementation is much closer to complete.

32

Re: Neverball and Neverputt for the Oculus Rift

Sweet!

I had some of the OpenHMD guys testing stuff the other day. They said they needed to make changes to the makefile (eplacing "-lhidapi" with "-lhidapi-raw" for linking against the apporpriate hidapi library). I don't recall needing to do this though.

General feedback was that it was nice. Nobody claimed to feel queasy, but said they thought other people would (couldn't really nail down whether that was HMD specific, or just part of what Neverball normally does to people - getting to watch people-off-the-street sit down and play during SFDs has make it pretty clear that first approach for new players is pretty disorienting, especially if they're not used to stuff with fast camera moves).

Cheese
==========
cheesetalks.net

33

Re: Neverball and Neverputt for the Oculus Rift

The best approach to -lhidapi under Linux is actually to remove the library from the link line and allow -lopenhmd to pull in its own dynamic dependencies. I only added it because of the static linking I was doing under MinGW, which has since been separated out.

It's worth noting that the use of LibOVR opens the door to predictive tracking, yaw drift correction, and the use of calibration profiles. All of these things are absolutely necessary for a complete HMD application. I have yet to investigate the use of any of these mechanisms in Neverball and Neverputt, but I will soon. Once these are working, we can declare the HMD branch ready.

I'll also add a neck model, but that'll apply to all backends.

34

Re: Neverball and Neverputt for the Oculus Rift

Okay, here's a Windows build with the LibOVR backend. Since I don't have a Rift and I only launched it once through Wine, I only know that it runs and the HMD option works. No idea if it works on Windows with an actual device.

http://icculus.org/neverball/neverball- … 130828.zip

Here's my hacks to get LibOVR compiling with MinGW. There is a libovr.a 32-bit release build that I compiled in LibOVR/Lib/...

https://github.com/parasti/OculusSDK-MinGW

I also took the liberty to make a couple commits to the HMD branch.

35

Re: Neverball and Neverputt for the Oculus Rift

Wow, great work! I'll give this a try today.

Thanks for cleaning up the Makefile too.

36

Re: Neverball and Neverputt for the Oculus Rift

Okay, I played for half an hour or so, and parasti's build is good.

The most serious issue remaining is the yaw drift. Fortunately, the latest version of the SDK should take care of that for us. If a user generates and saves a correct calibration then the game should automatically use it. Without this feature, you end up having to slowly turn your body over the course of tens of minutes to keep up with the rotation of the HMD's frame of reference. I haven't calibrated my system since the release of SDK 0.2.4, but I'll give it a go soon.

I did encounter one strange behavior: the motion sensor would stop working once in a while after a game exit. Restarting the game did not reset it. I had not encountered this previously. If I unplug and replug the Rift's USB cable then it's fixed. It's not likely our problem, and it might be limited only to LibOVR under Windows. I'm pretty sure we're shutting down the SDK properly on exit, but there's always a chance we're doing something wrong.

37

Re: Neverball and Neverputt for the Oculus Rift

Sweet, thanks for testing. Sorry it took me so long.

38

Re: Neverball and Neverputt for the Oculus Rift

I tested the magnetometer calibration in LibOVR 0.2.4 under Windows, and ran parasti's build. There was no significant drift after 20 minutes of play, in contrast to 30 degrees or more of drift in the same period without calibration. This indicates that the yaw drift issue has been resolved for us.

I also added a little bit of neck offset to the LibOVR HMD mode. This accounts for the fact that tilting your head does not cause your view to rotate about its center, but instead about the base of your neck (plus a little to account for spine.) It's subtle, but effective in enhancing realism. I've currently hard-coded the neck length to 10 cm. Ideally, neck length would be a value in the Oculus user profile, but it's not. I don't see much point in making it a Neverball config item, since it really doesn't belong there.

(Though setting the neck offset too long actually feels quite good. It's as though your entire torso pivots as you look around, and you can really get different angles on things in a very intuitive way.)

I encountered some difficulty when I upgraded LibOVR to 0.2.4 under Linux. Requesting the head orientation from the SensorFusion object results in a segmentation fault, and shutting down the device causes a thread deadlock. Compiling against 0.2.3 resolves both issues, so clearly something has regressed.

39

Re: Neverball and Neverputt for the Oculus Rift

I took Neverball and my Rift along to our Software Freeom Day event this year and got people to try it out and share their thoughts.

As was to be expected a few people felt pretty queasy, though I don't believe that that was a significantly higher ratio than I'd observed at previous SFD events without the Rift (though the impact did seem more pronounced).

Observed average playtime was around 3 - 5 minutes, with a couple of younger kids playing for 15 - 20 minutes (balancing out those who couldn't stand more than 30 seconds).

Most people seemed to feel more comfortable with manual camera than automatic camera.

Interestingly, people seemed less inclined to bounce randomly off the walls (this may indicate that camera behaviour when in automatic camera mode is less pleasant on a HMD?)

Most people commented on how difficult the UI is to read. I didn't have a chance to experiment with bringing the UI closer to the camera at the event though.

As I was running Neverball in windowed mode (at 1280x800 with the Rift mapping to a portion of the primary monitor so that other people could see what was going on), we did have numerous occasions where the mouse escaped the Neverball window (often resulting in people bringing up Gnome Shell's activities overlay).

http://farm6.staticflickr.com/5480/9884728825_0984e223a7_n.jpg http://farm8.staticflickr.com/7424/9944696444_93baa84823_n.jpg

Larger photos: http://www.flickr.com/photos/cheeseness … 778398056/
SFD writeup: http://www.taslug.org.au/modules/news/a … toryid=222

Cheese
==========
cheesetalks.net

40

Re: Neverball and Neverputt for the Oculus Rift

Awesome Cheese!

41

Re: Neverball and Neverputt for the Oculus Rift

So is this good to merge now?

42

Re: Neverball and Neverputt for the Oculus Rift

It's been merged. I'm impatient.

43

Re: Neverball and Neverputt for the Oculus Rift

I'll probably make another branch for my fiddling around once I've got something to show.

Cheese
==========
cheesetalks.net

44

Re: Neverball and Neverputt for the Oculus Rift

parasti wrote:

It's been merged. I'm impatient.

Cool. Nice work. That was a big job.

45

Re: Neverball and Neverputt for the Oculus Rift

Cheers. It is always immensely exciting to see you doing Neverball stuff.

46

Re: Neverball and Neverputt for the Oculus Rift

I updated my MinGW patch to work with the 0.2.5 SDK.

There's no build, though, because as of this version Neverball crashes during global initialization (i.e., before main). This occurs for me on both MinGW and Linux.

47

Re: Neverball and Neverputt for the Oculus Rift

parasti wrote:

There's no build, though, because as of this version Neverball crashes during global initialization (i.e., before main). This occurs for me on both MinGW and Linux.

I know what causes this crash now. I discovered it when fixing an unrelated project. Basically, you can't declare an OVR::SensorFusion globally because its constructor assumes that OVR::System::Init has already been called. Hopefully I can patch it relatively soon.

48

Re: Neverball and Neverputt for the Oculus Rift

Thanks for fixing this.

I updated the nightly Windows build to include HMD-enabled binaries compiled against LibOVR.

49

Re: Neverball and Neverputt for the Oculus Rift

Awesome. I want to push on a 1.6.0 release so we can have Oculus support in the main-line binaries. I've got fixes for the remaining GL issues brewing now.

50

Re: Neverball and Neverputt for the Oculus Rift

rlk wrote:

Awesome. I want to push on a 1.6.0 release so we can have Oculus support in the main-line binaries.

I'm anxious about licencing concerns with the Oculus library. Its licence doesn't seem to be GPL compatible, and if that's the case, pushing out release binaries with it compiled in would be Wrong (the builds we have floating around at the moment make me uncomfortable).

Has anybody else looked into this?

Cheese
==========
cheesetalks.net