1 (edited by rlk 2013-07-29 01:14:03)

Topic: Neverball and Neverputt for the Oculus Rift

I've ported both Neverball and Neverputt to use the OpenHMD API, thus enabling support for the Oculus Rift virtual reality headset. The code is in branches/hmd at https://s.snth.net/projects/neverball/b … anches/hmd.

I've attached a couple screenshots. The first shows Neverball during play. Obviously, seeing it in motion is the key. It's a hell of a thing.

https://dl.dropboxusercontent.com/u/28320415/never-vr1.png

Here's Neverputt at the main menu (just to prove I didn't overlook Neverputt).

https://dl.dropboxusercontent.com/u/28320415/never-vr3.png

Here's Neverball at the set selection screen. This demonstrates the GUI, which works especially well. GUIs are a problem in Rift ports, but ours looks great. A virtual mouse pointer appears when necessary, as the system mouse pointer doesn't work in VR.

https://dl.dropboxusercontent.com/u/28320415/never-vr2.png

Both games take advantage of the Rift sensors to provide full look-around. This works with the GUIs and the replays as well as during gameplay.

Both games have an HMD toggle in their configuration screens, and HMD support may be switched off and on in-game.

Some might wonder why OpenHMD was chosen instead of LibOVR, the library provided by the official Oculus SDK. That's a topic worth discussing, but Cheeseness and I both examined the issue in depth and agreed that OpenHMD is the best path forward. It's true that OpenHMD currently lacks features that LibOVR provides. Most notably, these include predictive tracking, chromatic aberration correction, and neck modeling. However, I'm confident that OpenHMD will evolve to support all such features, and ultimately an independent library will provide a more stable and useful environment with broader device support than any manufacturer's software can. I'm totally willing to be proven wrong on that.

As of now, I've tested this port only under Linux. I'm working on OSX. A Windows port will follow soon, and we'll try to produce some binary executables so people can try it out.

A couple notes:

- If your Rift is connected as secondary display, set the environment variable SDL_VIDEO_FULLSCREEN_HEAD to 1. Then when you enable the "fullscreen" option in the config file, the game will move to your Rift.

- If the view is not level when the game starts, wait a moment and it will correct itself. If it's really messed up, hold your head steady and toggle HMD off and on again. This will reset the sensor to default to your current head position.

- This port is by-no-means finished. There may be interactions with other features that I haven't uncovered. Report your findings. OpenHMD has a lot of growing up to do, and Neverball will have to change with it as it matures. We can expect breakage as upstream improvements occur.

- Many people experience VR sickness when using HMDs. This is largely due to a conflict between your visual and vestibular balance systems. When you read while riding in a car, your eyes see a steady image while your vestibular system detects motion, so you get car sick. HMD is the exact opposite, and your eyes see a moving image while your vestibular system is stable, so you get VR sick. Neverball is especially bad as it has very few stable points of reference and is a game designed entirely around environmental rotation. After many hours of VR Half-Life 2, I got over my VR sickness, but Neverball brought it right back. Be warned. Neverputt is fine though.

(edit to inline the images)
(edit again because non-users can't see attachments)

Post's attachments

screen00005.png 547.28 kb, 62 downloads since 2013-07-28 

screen00006.png 624.92 kb, 66 downloads since 2013-07-28 

screen00011.png 376.36 kb, 72 downloads since 2013-07-28 

2

Re: Neverball and Neverputt for the Oculus Rift

WOOT

3

Re: Neverball and Neverputt for the Oculus Rift

Right on, thanks! smile

Our Lord and Savior Jesus Christ loves and cares about you most of all!

4

Re: Neverball and Neverputt for the Oculus Rift

Wow, man yikes

Even if I don't understand it, it looks very cool!

~DEV

5

Re: Neverball and Neverputt for the Oculus Rift

It's my birthday today. Best present ever ^_^

I'll have a fiddle and offer some feedback this evening big_smile

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

6

Re: Neverball and Neverputt for the Oculus Rift

Cheeseness wrote:

It's my birthday today.

(I hope this won't lead the whole conversation off topic...)

Happy Birthday!

~DEV

7

Re: Neverball and Neverputt for the Oculus Rift

Now I need to buy an Occulus Rift... thank you, awesome big_smile

8 (edited by Cheeseness 2013-07-29 12:24:56)

Re: Neverball and Neverputt for the Oculus Rift

Thanks ht-never big_smile

For anybody who hasn't seen it, I did a belated unboxing/first impressions review when the official Oculus SDK got Linux support, which people seem to like.

To expand on rlk's comments on OpenHMD, it's also worth noting that OpenHMD aims to be a generic library for HMD/headtracking/other VR type stuff (it currently only supports the Rift, but I believe there are plans to add Razr Hydra support as well as other VR oriented input devices and HMDs). By using this API, we'll hopefully also give ourselves more opportunity to support more stuff down the track with less work.

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

9

Re: Neverball and Neverputt for the Oculus Rift

Cheeseness wrote:

It's my birthday today

Missed it, by THAT much... Happy Birthday d00d !!

Currently Playing:
Celeste and Electronic Super Joy

10

Re: Neverball and Neverputt for the Oculus Rift

This is crazy awesome, but I don't have an Oculus Rift ... so, like, whatever, dude. ;(

Um.

But seriously, nice work you guys.

I went over the patch briefly, looks pretty good to me.

I take a bit of an issue with the screenshot function placement, though. I see why you moved it, but it can't really happen after the buffer swap. It reads the back buffer (and basically has to because of GLES lacking glReadBuffer), which becomes undefined after the swap. It has to go draw to back->screenshot->swap to front.

(BTW, happy belated birthday, Cheese!)

11 (edited by Cheeseness 2013-07-29 22:03:45)

Re: Neverball and Neverputt for the Oculus Rift

parasti wrote:

This is crazy awesome, but I don't have an Oculus Rift ... so, like, whatever, dude. ;(

It'll do the Rift's stereoscopic rendering and lens distortion even if you don't have a rift (if you're way super excited to, you can go crosseyed and not quite get the effect big_smile )

As a part of the VR Game Jam, Oculus are apparently setting up "playtest hubs" in cities around the world. If there ends up being one close enough, it could be worth taking a peek at if you have an opportunity.

parasti wrote:

(BTW, happy belated birthday, Cheese!)

Well, it's still yesterday in some parts of the world, so I'm happy to consider it on time.

Edit:

parasti wrote:

But seriously, nice work you guys.

I should probably highlight that this is all rlk's work. I've been poking around a bit over the past month or two, but hadn't really had time to get anywhere. By contrast, rlk pulled this together in a day or two.

I had meant to share some impressions last night before I hit the hay, but it seems I closed the tab without posting. I might pop something something up later this evening ^_^

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

12

Re: Neverball and Neverputt for the Oculus Rift

I finished OSX compatibility testing in branches/hmd. It's solid. Is there still anyone maintaining an OSX package?

I discovered a couple old bugs while testing, and I also optimized all the PNGs because the latest version of libpng is pick about ICC profiles and was complaining. These are things that should be moved to the trunk, but there's no hurry, and we can hold off until such time as the HMD branch is deemed worthy of merge.

I'll look into the Windows port as soon as possible.

I understand something needs to be done about the shot/swap ordering. I changed it for obvious reasons. Sorry I broke something. I'm okay with whatever works in both cases.

Also, I made another ball:

https://dl.dropboxusercontent.com/u/28320415/rift.png

13

Re: Neverball and Neverputt for the Oculus Rift

It's worthy now as far as I'm concerned.

14 (edited by Cheeseness 2013-07-30 09:27:15)

Re: Neverball and Neverputt for the Oculus Rift

rlk wrote:

Also, I made another ball:

https://dl.dropboxusercontent.com/u/28320415/rift.png

Ha, I had the same idea! I'll check that off my todo list too big_smile

It's a bit of a shame that the ball occludes the screen.

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

15

Re: Neverball and Neverputt for the Oculus Rift

parasti wrote:

It's worthy now as far as I'm concerned.

The Windows side is completely untested, and Windows users are going to be the largest group of Rift testers. I want to get some binaries out and allow for some testing before declaring the branch mature.

Cheeseness wrote:

It's a bit of a shame that the ball occludes the screen.

Yeah, it is. There is, of course, a screen shot (the first one, above) textured onto the inside of the Rift model, and the ball is looking at it through a pair of lens cones, but you can't see it in-game. I considered trying to fix that, but there are so many passes and transparency layers in the ball renderer that I was unlikely to improve this case without breaking another one somewhere.

16

Re: Neverball and Neverputt for the Oculus Rift

Okay, the Windows port of the OpenHMD implementation has been completed and tested. I produced a static build using MinGW, which you can find here: http://cct.lsu.edu/~rkooima/neverball-rift.zip

This includes Windows binaries of both Neverball and Neverputt with HMD support. If you are a Windows user, please give them a shot even if you don't have a Rift.

There are a lot of Rift demos floating around right now, and most Rift users use Windows. I'd really like to have a solid binary ZIP of a Windows EXE that these people can easily grab and try. This is the first draft of that.

Package maintainers for OSX and Linux: please try to produce a binary build of this branch for people to try.

With this finished, we have Oculus Rift support on all three platforms. That's a big deal. It's not DONE done, as there's no real calibration mechanism, but that's an issue (among others) to be resolved within OpenHMD. Hopefully with our support and assistance, OpenHMD can improve quickly.

17 (edited by Cheeseness 2013-07-31 04:10:04)

Re: Neverball and Neverputt for the Oculus Rift

rlk wrote:

Yeah, it is. There is, of course, a screen shot (the first one, above) textured onto the inside of the Rift model, and the ball is looking at it through a pair of lens cones, but you can't see it in-game. I considered trying to fix that, but there are so many passes and transparency layers in the ball renderer that I was unlikely to improve this case without breaking another one somewhere.

I've been running it without the basic ball mesh. It's amusing to me in that not seeing the ball mirrors the disconnect from the real world you suffer when using HMDs (not being able to see your hands, your input devices, etc.).
http://i.imgur.com/06ApL77.png

I was originally considering doing a ball with the Rift floating inside, but I think the ball actually wearing it is a better idea.

I'm also wondering if it might not be a bad idea to make the Rift ball default in Rift test builds.

rlk wrote:

I produced a static build using MinGW

I'm not really familiar with the Boost licence. Are there any GPL compatibility concerns to be aware of with this?


So, I promised some ramblings, and here they are!

First up, it's awesome to have this. I've been on and off poking around with it in what little spare time I've had, and though I'm still intending to mess around an experiment with different control/presentation stuff (most of which I expect to be completely unusable), what we have feels pretty solid and hopefully will generate some good enthusiasm for the project.

I don't have much interest in running it fullscreen, but I had a go using SDL_VIDEO_FULLSCREEN_HEAD and didn't have much success (possibly because I'm running Twinview?). I prefer to have it windowed and make the Rift a clone of a portion of my screen that I can just put an application over, allowing me to see what's going on regardless of whether I'm wearing the device or not. This ends up resulting in potential misalignment thanks to window borders, but that's only one or two pixels and it's not visible to me when using the device.

rlk wrote:

Neverball is especially bad as it has very few stable points of reference and is a game designed entirely around environmental rotation.

Having never had a "motion sickness" experience with HMDs or headtracking, I can't really comment on this aspect (I did seek out every twisty, loopy level I could find to see if I could get something that would make me feel awful though), but I can argue that Neverball has aspects which make disorientation less likely (providing you've already mastered not feeling disoriented in the game itself or are using manual camera).

Unlike first person shooters, Neverball's main focus (the ball) is always in the same direction. If you glance away, you always know where to look to find the ball. Since the position of the ball is always known, the direction of apparent world movement is always clear, which I believe makes it easier to keep track of what's happening within the game.

After watching Mim play (it does make her feel a bit queasy), her biggest issue was when a replay started playing on the main menu without warning - I think this is to be expected, as people generally seem to experience motion sickness less when they have a sense of control over whatever movement is problematic. I think I'd lean towards disabling automatic playing of replays when idle, but I'd be happy to hear other thoughts.


I have noticed that blurring/juddering/whatever you want to call it feels more present than the other stuff I've played with on the Rift. I'm going to guess that this has to do with our bright colour palette (and perhaps it's more noticeable when solid red, green or blue are dominant? I don't know enough about how the Rift's LCD screen works to say for sure), but it could also be to do with the way in which the camera moves independently of head movement when rotating.


The UI feels good, although I wouldn't mind tidying up the mouse cursor (its edges are pretty noisy), and perhaps experimenting with some rotation or shift to bring UI elements closer to the camera when looking left or right, or perhaps when moving the mouse cursor.

So far as the gameplay HUD UI goes, having to glance at the coin counter to bring it into focus feels pretty awkward to me (but I don't feel that shrinking the HUD as well as the non HUD GUI elements would be a good move).


I'm also interested in seeing how the game would feel if head movements rotated the view around the ball rather than around the camera's location, keeping the ball in-frame at all times and giving a more solid point of reference. I'm not certain that this would be preferable to what we have now, but it's all possibility space that I'm personally interested in exploring.

Similarly, I'm also interested in seeing how the game feels with headtracking pitch and roll controlling the world's tilt - I fully expect this to be cumbersome, uncomfortable and inaccurate, but again, I'm keen to experiment with different implementations, not only for my own interests, but also for potential insights into what's good and bad about the current mechanisms by having something to compare them to.


I wouldn't mind seeing us have some "virtual headtracking" controls so that camera movement could be controlled without a Rift.


All up, it's super neat, and I totally agree with rlk's assertion that this is potentially a "big deal" (both for us and for OpenHMD), and though it's still early, what we have feels solid and playable.

It's really interesting to see the different perspective this gives on the game. It also highlights how glaringly bad the shooting star animation is in the Volcano background (though the environment as a whole feels much broader/more impressive) big_smile


Great work, rlk!

Edit: I've got a little bit of time off work that I'm trying to fit a lot of stuff into. I was hoping to hack around with HMD support a bit, but if nobody else is willing to put together pre-release testing builds for Desura/IndieDB (which gives us some space for "beta" builds that I think we should take some advantage of), I guess I can spend my time doing that instead (I also have a Mac now, but haven't looked at what's involved with building on that yet) sad

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

18

Re: Neverball and Neverputt for the Oculus Rift

I don't get the static linkage. Is that something PLATFORM=mingw is supposed to support from now on?

19

Re: Neverball and Neverputt for the Oculus Rift

parasti wrote:

I don't get the static linkage. Is that something PLATFORM=mingw is supposed to support from now on?

No. Sorry about that. I knew I would be stepping on one of your toes there. I'm completely willing to revert that for our future deployments.

My MinGW setup is organized to favor static builds because this eases the distribution of some of my other projects. I felt it would make sense to take the same approach for beta-testing of the HMD code, since it's very convenient to unzip and run a beta, while a full-fledged installer implies greater permanence.

I'm not advocating any change in distribution policy.

20

Re: Neverball and Neverputt for the Oculus Rift

rlk wrote:

I discovered a couple old bugs while testing, and I also optimized all the PNGs because the latest version of libpng is pick about ICC profiles and was complaining.

The question of optimizing PNGs comes up every now and then, so I'll just leave a link to the last discussion. My suggestion would be to strip all unwanted or unneeded chunks but leave the original image type intact so that every file remains 8-bits-per-sample RGB, RGBA, greyscale, or greyscale with alpha. When using optipng, the -nx command line option will do the trick.

21

Re: Neverball and Neverputt for the Oculus Rift

Elviz, if you're looking at carrying Rift support across to Nuncabola (I don't know of anybody working on OpenHMD bindings for Java though), I'm happy to do testing on Mac OS and Linux

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

22

Re: Neverball and Neverputt for the Oculus Rift

Elviz wrote:

The question of optimizing PNGs comes up every now and then, so I'll just leave a link to the last discussion. My suggestion would be to strip all unwanted or unneeded chunks but leave the original image type intact so that every file remains 8-bits-per-sample RGB, RGBA, greyscale, or greyscale with alpha. When using optipng, the -nx command line option will do the trick.

My primary motivation was to toss out all of the ICC profiles. For that I used Imagemagick's convert -strip.

Afterward, I did hit the files with optipng -o4, simply because I'm in the habit of doing so. Clearly you've discussed this and thought it through more than I have, so I'm alright with doing whatever you think is best, just so long as it involves stripping the ICC. I do agree that it's a reasonable policy to stick with those four image formats, and, in particular, to disallow optimizations that produce palette formatted images.

(ICC profiles have no bearing on the look of the game, and libpng 1.6.2 complains about many of our PNGs, so that's the problem I was looking to solve.)

23 (edited by Elviz 2013-08-02 03:31:17)

Re: Neverball and Neverputt for the Oculus Rift

rlk wrote:

(ICC profiles have no bearing on the look of the game, and libpng 1.6.2 complains about many of our PNGs, so that's the problem I was looking to solve.)

I understand entirely and agree with the measure you took.

As for the optimization part, after the discussion with jammnrose last year I did some more tests, and the reported issues were basically all due to OptiPNG's "lossless image reduction" step. As long as we disable that, everything should be fine. Nothing wrong with -o4'ing the iCCP-stripped files.

Cheeseness wrote:

Elviz, if you're looking at carrying Rift support across to Nuncabola (I don't know of anybody working on OpenHMD bindings for Java though), I'm happy to do testing on Mac OS and Linux

Thanks, Cheese. I don't have (and haven't pre-ordered) a Koronis Rift – I mean, Icculus Rift – so there aren't any plans at the moment really. Once that changes, I'll be sure to take up your offer.

What I wonder about is whether the Oculus Rift will give the player enough of a feeling of orientation and balance that serious playing becomes possible. I mean, will you be able to finish the more difficult levels that require very careful movements and camera rotation?

24

Re: Neverball and Neverputt for the Oculus Rift

Elviz wrote:

What I wonder about is whether the Oculus Rift will give the player enough of a feeling of orientation and balance that serious playing becomes possible. I mean, will you be able to finish the more difficult levels that require very careful movements and camera rotation?

This is a good question. However, it presupposes that HMD use is a limiting factor. Could it instead be an enhancement? It's clearly more difficult for me to play in HMD mode, but I'm pretty sure that's because I've been playing Neverball for ten years on a 2D screen. Given practice, HMD mode might actually be a more powerful interaction.

It would certainly be possible to construct a level which was playable with HMD and unplayable in 2D. I make this claim on the basis that a player can always see where they're going in HMD mode. You always know right where you're going to land a big bounce because you can look straight at it as you approach it.

25

Re: Neverball and Neverputt for the Oculus Rift

rlk wrote:

You always know right where you're going to land a big bounce because you can look straight at it as you approach it.

Yeah, that's a good point.

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.

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