Minecrift Discussion Thread

[Jademalo]

- hmm, frame rate tanking. Very interesting! Is this a general 'using hydra' issue, or only when pos track is enabled? [If the former, I wonder if the Sixense jni is caching class lookups...]

I'll get back to you on this - It's too hot for me to use the rift for longer than about 5 minutes =[

[Additives]

Hey guys, the mod is amazing, as the far to many hours I have spent on metacraft can attest. A couple of things:

Maps don't work with the full first person view. Not sure what you can do about it, but figured this was the place.

The other thing was: is there a way to install mincrift and forge at the moment? I miss some of my small mods (Better world generation, Timber, Zombie Awareness are all fantastic 'tweak' mods imho, and there was that bookcase one too)

Thanks again!

[Jademalo]

Hey guys, the mod is amazing, as the far to many hours I have spent on metacraft can attest. A couple of things:

Maps don't work with the full first person view. Not sure what you can do about it, but figured this was the place.

The other thing was: is there a way to install mincrift and forge at the moment? I miss some of my small mods (Better world generation, Timber, Zombie Awareness are all fantastic 'tweak' mods imho, and there was that bookcase one too)

Thanks again!

If i'm not mistaken, there is forge compatibility. For 1.6.2, you'll have to mess with json files though...
And with maps, it's a known issue. The reason hand model was added back in was so they could be viewed at least temporarily.

[thenomad]

Very minor recommendation: in the installation instructions on the Minecrift site (congrats on the new site, btw!), specify that the installer.exe should be run as administrator. That tripped me up for a moment.

BTW, I'm super-impressed with how this is all developing. Sorry I haven't managed to do much for the project yet - I WILL get that Wii balance board/Minecrift video up soon!

[thenomad]

Darn it, it's currently crashing after install.

---

Update: Ignore, I reinstalled Minecraft and that fixed it.

---

Second update: HOLY CRAP.

Playing on a much more powerful PC than my first experience with MineCrift, and with a mouse and keyboard, is a FAR better experience. The mouse is so much more controllable than the Hydra - with the HUD turned off, it's incredibly immersive. And the improved framerate and reduced lag makes a colossal difference.

Also, super-impressed with the new installer. I was going to write a guide to installing MineCrift, but it's really not needed!

Ace work, guys.

I do notice that FSAA makes the entire thing much, much more laggy. It looks nicer, for sure, but the lag's a killer.

[mabrowning]

It really shouldn't need admin rights.... I need to figure out why it asks UAC permissions and says 'did it install correctly' yadda yadda

[zwendt]

Thanks for the incredible work on this mod! I've easily logged the most Rift time here.

minecrift-1.6.2-b99-installer.exe looks like it has a simple bug when installing Hydra support. The version dir, jar and json all end up named minecrift-1.6.2-b99null
Manually renaming to remove the null makes everything work.

You probably want that string to start as ""?

[mabrowning]

Yep, fixed in b100+. Sorry about that.

[mabrowning]

The relevant parties are probably aware, since its only useful on a multiplayer server, but b105+ has positional audio support for mumble. If you use mumble as a voice chat client, Minecraft VR now natively supports sending your position. On MetaCraft, we ask people to configure it so you can only hear people within ~70m. It uses your head orientation too to do positional playback, so players voices will sound like they are actually coming from their respective characters. Its actually really awesome!

Also, I've got some progress on reworking the hydra control scheme to be remappable and actually usable. I will also support a "hybrid" mode where you can use one hydra for positional head tracking, one for natural aiming, and use a controller in your left hand for moving. I personally think that will be the best of both worlds and the "best" we can do with current tech.

I haven't made any progress on accelerating the shaders... sorry; the hydra stuff was more fun to develop, and most people seem to be ok with the current performance. Its still on my list, but no progress on that front.

[StellaArtois]

I haven't made any progress on accelerating the shaders... sorry; the hydra stuff was more fun to develop, and most people seem to be ok with the current performance. Its still on my list, but no progress on that front.

...however I have been looking into it, so we should see some progress on that soon. Teamwork!

[StellaArtois]

Darn it, it's currently crashing after install.

---

Update: Ignore, I reinstalled Minecraft and that fixed it.

---

Second update: HOLY CRAP.

Playing on a much more powerful PC than my first experience with MineCrift, and with a mouse and keyboard, is a FAR better experience. The mouse is so much more controllable than the Hydra - with the HUD turned off, it's incredibly immersive. And the improved framerate and reduced lag makes a colossal difference.

Also, super-impressed with the new installer. I was going to write a guide to installing MineCrift, but it's really not needed!

Ace work, guys.

I do notice that FSAA makes the entire thing much, much more laggy. It looks nicer, for sure, but the lag's a killer.

thenomad, what are the specs of the PC you're playing on out of interest?

[thenomad]

@Stella - i5-2559k CPU, 12GB RAM, GTX 560 Ti with 2Gb of VRAM

[Jademalo]

Nice to see mumble positional audio in! I'm a massive mumble fan.
Out of curiosity - did you do it from scratch or is it an implementation of the already existing mod?

I haven't been able to play or test all week due to insane heat, I get sick after like 5 minutes =[
In addition to that, im off down south to watch TI3 finals (and demo the rift!) in a few days, so I should get some feedback from there.

Also Stella - I'm not 100% sure yet because I wasnt able to be on long enough to test, but I think Hydra positional might also affect the tracking latency somewhat. I've had to stop using it because of that reason, I'm sort of alright with 35 prediction and no AA, but anything other than that is difficult for me >_<

Hopefully it will cool down over the next few days so I can do some playing, the more I've been using the rift the more I've been enjoying it. I was worried before I got it it would be the case of the novelty wearing off the more I used it, but amazingly it seems to work in the opposite way.

[mabrowning]

Nice to see mumble positional audio in! I'm a massive mumble fan.
Out of curiosity - did you do it from scratch or is it an implementation of the already existing mod?

I started off by making forge compatibility work again and using mod_MumbeLink, but it didn't properly account for head roll or decoupled move/look. I was going to modify it, but the mod was huge for no apparent reason. I ended up taking someone else's windows-only JNI wrapper and rewrote 50% of it to be cross platform. About 200 C++ lines. The java side of things was then ~10lines of actual logic. We were already doing 3D audio positioning, so I just tacked it on to that.

[Jademalo]

I started off by making forge compatibility work again and using mod_MumbeLink, but it didn't properly account for head roll or decoupled move/look. I was going to modify it, but the mod was huge for no apparent reason. I ended up taking someone else's windows-only JNI wrapper and rewrote 50% of it to be cross platform. About 200 C++ lines. The java side of things was then ~10lines of actual logic. We were already doing 3D audio positioning, so I just tacked it on to that.

Oooh, nice. Is the 3D audio implementation you were talking about a few days ago finished? I've been using the binaural OpenAL DLLs for the past few days, figured out how to get them to extract on the launcher. Will they enhance, detract, or are you using new sound lib dlls?

[mabrowning]

I started off by making forge compatibility work again and using mod_MumbeLink, but it didn't properly account for head roll or decoupled move/look. I was going to modify it, but the mod was huge for no apparent reason. I ended up taking someone else's windows-only JNI wrapper and rewrote 50% of it to be cross platform. About 200 C++ lines. The java side of things was then ~10lines of actual logic. We were already doing 3D audio positioning, so I just tacked it on to that.

Oooh, nice. Is the 3D audio implementation you were talking about a few days ago finished? I've been using the binaural OpenAL DLLs for the past few days, figured out how to get them to extract on the launcher. Will they enhance, detract, or are you using new sound lib dlls?

Currently, all the audio comes out of Mumble, so it won't have HRTF applied to it, sadly, so it will be unaffected by your configs.

The wave-tracing true audio demo I mentioned a few weeks ago is just a future plan. I haven't started looking at it, just finding out from the original researcher if it is feasible. It is!

[Jademalo]

Currently, all the audio comes out of Mumble, so it won't have HRTF applied to it, sadly, so it will be unaffected by your configs.

The wave-tracing true audio demo I mentioned a few weeks ago is just a future plan. I haven't started looking at it, just finding out from the original researcher if it is feasible. It is!

Bleh, silly me. Of course it does!
Looking forward to see if anything comes of the wave-tracing thing, it sounds pretty sweet =]

[CaptnYesterday]

35 hours of Minecrift later: So much fun! (Told you I would drop off the forums )

Issues:
-Upon loading up a world, the 3D & headtracking stops. A bit jarring everytime, but I am sure that you know this issue.
-Can you change the tool tip for regular AA to recommend FSAA within VR options->optics (I see no reason to ever use this AA over your FSAA in 1280x800 and first time users may get confused
-Holding and viewing the map. Is there a shortcut key for this? Currently I have to go into VR options-> player prefs to toggle this.
-Defaulting full screen: 'ON'; MIP Mapping: 1 or 2 ; FSAA: ON may be a good idea for people new to this stuff.
-May be alone on this, but the judder or latency is still apparent when I use FSAA and MIP Mapping even with a cosostent 75-80FPS (A friend with a different brand video and CPU still prefers this method as the visual quality outweighs possible judder/latency). I would kill for a latency tester to see if I am just crazy. Doubt this is worth testing without said latency tester.


General feedback:
-Still playing with 1920x1080 rift extended on Desktop as main monitor. No FSAA or MIP Mapping enabled as both show visible judder when turning my head. Funny thing about this is there is less motion blur when on FSSA/MIP Mapping. I can only guess that it is due to the image judder keeping the same image on screen for a few more ms?
-I play for at least 3hours at a time and there are 0 negative effects by the time I quit. My eyes are relaxed and no symptoms of any associated simulator or motion sickness.


Positional voice chat!? That is freak'n awesome! Knew from back in March that this would become a very important aspect of multilayer VR. Pretty undeveloped area too. Great work!! Hate to ask for more in this area but i did have an idea:
-Dynamic Voice Intensity: If a person is 10m compared another at 50m away, the voices are directionalized relative to source and receiver but is there a relative intensity system in play? Speaker at 10m is louder than speaker at 50m?
-Intercom: Say your team/friends are more than 70m away, can it switch over to type of intercom system at that point? I remember Borderlands 1&2 did this really well. Positional and intensity audio would be based on rerlative position to the source and once the character reached a threshold distance where the NPS voice would become difficult to hear, an intercom system would kick in.

As always, great work. This is fully playable for me (hence the absence) and I am really enjoying learning a new game too! Still hard to get over how well this has all been implemented and how professionally it's all done. You guys are really impressive.

[mabrowning]

35 hours of Minecrift later: So much fun! (Told you I would drop off the forums )

Issues:
-Upon loading up a world, the 3D & headtracking stops. A bit jarring everytime, but I am sure that you know this issue.

Ah yes. I've known about this, but have just ignored it until now. I'll add it to our issue tracker so we don't forget about in our next bug-fixing-spree.

-Can you change the tool tip for regular AA to recommend FSAA within VR options->optics (I see no reason to ever use this AA over your FSAA in 1280x800 and first time users may get confused

Sure. We could probably even remove this altogether.

-Holding and viewing the map. Is there a shortcut key for this? Currently I have to go into VR options-> player prefs to toggle this.

ctrl+H should do it. While a simple(ish) solution would be to allow remapping it, I've got something else planned that starts to add a fully featured 1st person VR model. It wouldn't just be the 3rd person model drawn without a head. This will allow us to do fancy stuff like showing your hotbar as a "utility belt" of sorts or tracking Hydra->InGame Hand position+orientation etc. Pretty cool stuff, I just need to come up with a plan and start working on it.

-Defaulting full screen: 'ON'; MIP Mapping: 1 or 2 ; FSAA: ON may be a good idea for people new to this stuff.

Defaults are tricky, because those settings exist before a user even installs minecrift, so we'd need some way of saying "I already set the 'defaults'" in case the user changes them back. Definitely doable; my only concern then is finding reasonable defaults...

-May be alone on this, but the judder or latency is still apparent when I use FSAA and MIP Mapping even with a cosostent 75-80FPS (A friend with a different brand video and CPU still prefers this method as the visual quality outweighs possible judder/latency). I would kill for a latency tester to see if I am just crazy. Doubt this is worth testing without said latency tester.

You are not alone. Jademalo was also having noticeable issues with this. Perhaps I'm not as sensitive to this stuff (have yet to even feel a bit queezy, even when jumping off buildings, spinning in circles, etc), but I don't notice it. StellaArtois is working to improve the performance of the distortion shader, which is the emergent culprit (with FSAAx2, the pre distortion framebuffer is something insane, like 4096x3092; maybe thats why it looks so "good" ^_^)

Positional voice chat!? That is freak'n awesome! Knew from back in March that this would become a very important aspect of multilayer VR. Pretty undeveloped area too. Great work!! Hate to ask for more in this area but i did have an idea:
-Dynamic Voice Intensity: If a person is 10m compared another at 50m away, the voices are directionalized relative to source and receiver but is there a relative intensity system in play? Speaker at 10m is louder than speaker at 50m?
-Intercom: Say your team/friends are more than 70m away, can it switch over to type of intercom system at that point? I remember Borderlands 1&2 did this really well. Positional and intensity audio would be based on rerlative position to the source and once the character reached a threshold distance where the NPS voice would become difficult to hear, an intercom system would kick in.

We actually are just using the positional audio features of mumble. It does do Dynamic Voice Intensity already, and there is the option to have a separate hotkey for "intercom" chat. I don't think there is a way to do it automatically, though.

As always, great work. This is fully playable for me (hence the absence) and I am really enjoying learning a new game too! Still hard to get over how well this has all been implemented and how professionally it's all done. You guys are really impressive.

If things turn out the way I'm planning, we're just getting started.

[CaptnYesterday]

^ If things turn out the way I'm planning, we're just getting started. I don't even know what that means! Honestly cannot think of too much more you guys can accomplish here. Minecrift is already on the forefront of new VR interface and experience. I'm not gushing, it is pretty much true. Any spoilers for what you are referring to here????????

Ctrl+H I will remember that, but agree that a mappable key would be a better solution as this will not be as easy with the rift on. Dropping my diamond sword by accidentally hitting 'Q' is already a problem when I asscidentally look at an enderman (Those guys are so f-ing scary.

VR moments (NEW!):
-Scaling a jungle tree, getting ontop of highest foliage and harvesting the wood and cutting away leaves... I am so careful because of how high up I am. I wouldn't say scared, but an acute awareness/jitteryness that you just do not feel on a monitor.
-Jumping off of a huge cliff into water STILL gives me that feeling I am jumping off a high dive.
-After 35 hours I have been to the bottom of a massive cave complex and huge underground crevasse. It just looks so intentional rather than procedurally generated structures. Very neat.

[Nibre]

So this is my first post here, but I've been following this thread pretty much since the first Beta was released. For the last few months I've been kicking around a certain idea in my head for the best way to control body<->world rotation while using the Rift, a way that is more natural and minimizes the potential for motion sickness (where using things like thumb sticks or keyholes for rotation can make some people sick pretty easily due to the disconnect from their body control).

A few days ago, because of the glory of open source, I finally went about compiling Minecrift myself to tinker with it. With my minor experience with Java, over the weekend I was able to hobble together my control scheme that is about 60% of the way to where I would like it to be, where it is fully functional and usable. It uses a control combination of Hydra+Rift+Controller (but it will optionally work without the controller), and a conglomerate of ratcheting/keyholes/differentials/aim offsetting for the logic. It's a pain at first to implement, but it seems to be working as intended so far, and should fairly natural to use when it's done.

I'm definitively willing to explain it further if anyone wants me to, but it is one of those things that involves a ton of conditional logic and math, and it would be easier to show how it 'just works' before getting into its intricacies.


Once I have a version I am satisfied with, I would like to have some of you who have at least a Hydra+Rift to try it out. I'm going to try my best to get it all finished up when I get home later today, but no promises. Once I'm done, I'll just upload a version of the installer for those who would like to try it out. Would I need to include a copy of the source with it or anything like that to be able to share the installer? I probably will anyway.

Also, while creating it, I couldn't figure out how to get a re-labeled version of MCHydra to show up in the settings concurrently with the vanilla MCHydra, so I had to just butcher my default one (have any pointers on getting both to work correctly?).


Heh I'm pretty excited to maybe get this all working and have people finally try out the crazy math I've had building up in my head . Hopefully it will live up to my expectations.

[mabrowning]

So this is my first post here, but I've been following this thread pretty much since the first Beta was released. For the last few months I've been kicking around a certain idea in my head for the best way to control body<->world rotation while using the Rift, a way that is more natural and minimizes the potential for motion sickness (where using things like thumb sticks or keyholes for rotation can make some people sick pretty easily due to the disconnect from their body control).

A few days ago, because of the glory of open source, I finally went about compiling Minecrift myself to tinker with it. With my minor experience with Java, over the weekend I was able to hobble together my control scheme that is about 60% of the way to where I would like it to be, where it is fully functional and usable. It uses a control combination of Hydra+Rift+Controller (but it will optionally work without the controller), and a conglomerate of ratcheting/keyholes/differentials/aim offsetting for the logic. It's a pain at first to implement, but it seems to be working as intended so far, and should fairly natural to use when it's done.

I'm definitively willing to explain it further if anyone wants me to, but it is one of those things that involves a ton of conditional logic and math, and it would be easier to show how it 'just works' before getting into its intricacies.


Once I have a version I am satisfied with, I would like to have some of you who have at least a Hydra+Rift to try it out. I'm going to try my best to get it all finished up when I get home later today, but no promises. Once I'm done, I'll just upload a version of the installer for those who would like to try it out. Would I need to include a copy of the source with it or anything like that to be able to share the installer? I probably will anyway.

Also, while creating it, I couldn't figure out how to get a re-labeled version of MCHydra to show up in the settings concurrently with the vanilla MCHydra, so I had to just butcher my default one (have any pointers on getting both to work correctly?).


Heh I'm pretty excited to maybe get this all working and have people finally try out the crazy math I've had building up in my head . Hopefully it will live up to my expectations.

Fantastic!

I'd love to see what you've got; I'm not afraid of intricate math . Since the code is licensed as LGPL, yes, you'll need to include the sources (or how to get the sources) for any modifications you release. The simplest way is just to fork the project on github and push your changes up there.

Probably the best way to handle multiple hydra behaviors is to split off the controller polling code into a static-ish class and have two different IBodyAimController implementations, both of which get their updates from the single (static) hydra plugin/manager. I'll be doing something similar to that when I add my "hybrid" controller method, though it sounds like you've already got that.

Does this use the hydra for head/body position tracking, or just a single for "rotation"?

I'll be heading off on vacation on Wednesday for about a week, but I might peek at what you've done while I'm gone

[StellaArtois]

So this is my first post here, but I've been following this thread pretty much since the first Beta was released. For the last few months I've been kicking around a certain idea in my head for the best way to control body<->world rotation while using the Rift, a way that is more natural and minimizes the potential for motion sickness (where using things like thumb sticks or keyholes for rotation can make some people sick pretty easily due to the disconnect from their body control).

A few days ago, because of the glory of open source, I finally went about compiling Minecrift myself to tinker with it. With my minor experience with Java, over the weekend I was able to hobble together my control scheme that is about 60% of the way to where I would like it to be, where it is fully functional and usable. It uses a control combination of Hydra+Rift+Controller (but it will optionally work without the controller), and a conglomerate of ratcheting/keyholes/differentials/aim offsetting for the logic. It's a pain at first to implement, but it seems to be working as intended so far, and should fairly natural to use when it's done.

I'm definitively willing to explain it further if anyone wants me to, but it is one of those things that involves a ton of conditional logic and math, and it would be easier to show how it 'just works' before getting into its intricacies.


Once I have a version I am satisfied with, I would like to have some of you who have at least a Hydra+Rift to try it out. I'm going to try my best to get it all finished up when I get home later today, but no promises. Once I'm done, I'll just upload a version of the installer for those who would like to try it out. Would I need to include a copy of the source with it or anything like that to be able to share the installer? I probably will anyway.

Also, while creating it, I couldn't figure out how to get a re-labeled version of MCHydra to show up in the settings concurrently with the vanilla MCHydra, so I had to just butcher my default one (have any pointers on getting both to work correctly?).


Heh I'm pretty excited to maybe get this all working and have people finally try out the crazy math I've had building up in my head . Hopefully it will live up to my expectations.

Fantastic!

I'd love to see what you've got; I'm not afraid of intricate math . Since the code is licensed as LGPL, yes, you'll need to include the sources (or how to get the sources) for any modifications you release. The simplest way is just to fork the project on github and push your changes up there.

Probably the best way to handle multiple hydra behaviors is to split off the controller polling code into a static-ish class and have two different IBodyAimController implementations, both of which get their updates from the single (static) hydra plugin/manager. I'll be doing something similar to that when I add my "hybrid" controller method, though it sounds like you've already got that.

Does this use the hydra for head/body position tracking, or just a single for "rotation"?

I'll be heading off on vacation on Wednesday for about a week, but I might peek at what you've done while I'm gone

Nibre, this all sounds great stuff. We'd encourage anyone else to do exactly the same thing; if you have a good idea, jump in there and modify the code yourself! Or failing that, let us know and if it makes sense to us we'll implement it.

[Jademalo]

Mark and Stella, I've avoided asking any general timescales for anything up to now, but I am going to ask just this once since I'm going to be doing probably my one and only demo.

Next weekend I'm off down to Leeds to meet up with a few friends and demo the rift to them and more. I've been planning and putting together what to show them, and the main thing I'm excited to show is obviously Minecrift. I'm planning on showing them a bit around Metacraft, but also FyreUK since they have some truly astonishing megabuilds. However, Fyre is currently running 1.5.2, and that build is seriously behind.
So the only time I'm ever going to ask - Will you be able to push a more recent build of 1.5.2 before next weekend?
In addition to this, I'm obviously incredibly excited about the new distortion shader, and I'd like to be showing the rift, the game and the mod off in the best of lights. I don't know how much work it is to release the current build for a previous version, but considering you don't do it particularly often I'm assuming it's a decent bit. In that same vein, will the distortion shader be finished before the next 1.5.2 build, and will it be a fairly simple job to release it all on said 1.5.2?

The shader obviously isn't a neccesity, that's just more curiosity, but I'd seriously appreciate a 1.5.2 build for when I go down. I feel like I'd be doing the thing a disservice if I wasn't showing off the latest build of the mod =p

The work you two have been doing is absolutely fantastic, I cannot believe just how thorough everything has been in my testing. Hopefully since it seems like the heatwave is over now I'll be able to play a bit more as of next week, and as I'm sure you are aware I'll report anything I find out of the ordinary =p
If you want me to test anything spesifically or need any feedback on any aspect, just ask and I'll be more than happy to give you my analysis or opinion. I'd really like to help as much as I can with this project =]

Thanks!

[Nibre]

I'd love to see what you've got; I'm not afraid of intricate math . Since the code is licensed as LGPL, yes, you'll need to include the sources (or how to get the sources) for any modifications you release. The simplest way is just to fork the project on github and push your changes up there.

I'm not really that experienced with forks/pushes and all that github stuff unfortunately. So I guess it's about time for me to figure it all out.

Probably the best way to handle multiple hydra behaviors is to split off the controller polling code into a static-ish class and have two different IBodyAimController implementations, both of which get their updates from the single (static) hydra plugin/manager. I'll be doing something similar to that when I add my "hybrid" controller method, though it sounds like you've already got that.

I might get to that once everything's working the way I need it to. It doesn't sound like it would be too hard to implement.

Does this use the hydra for head/body position tracking, or just a single for "rotation"?

So what the hydra controllers are actually used for are use as left and right 'shoulder' inputs. It is intended that you strap a hydra to each shoulder to help calculate intended body movement, and then you use a controller in your hands for additional button input. You can also use the hydra buttons as the button input instead if you choose to, but you would have to continually hold the controllers up to your shoulders (and I imagine that would be tiring for anything more than 10-15 minutes tops). The ideal way would be to have 2 sets of hydra, one set for your hands and one smaller, button-less set for shoulder positioning.

The default body 'center/forward' is calculated by taking the average yaw of both controllers. Then from that point on, all rotation changes for the body are calculated by a common delta between the two controller yaws (Body won't move if only one shoulder is moving. Both must move together, and body changes by the smaller value). This allows you to twist your 'body' left and right while keeping the camera yaw stationary/locked with your head. To keep your head and body centered correctly after the initial calibration, I'm using a head 'keyhole' that detects when your head rotates further than what is physically possible, more than 90 degrees relative to your shoulders. This is a 1:1 match to our 'natural' kinematic head keyhole; our shoulders. When ever the head passes this keyhole, the body 'center/forward' is reset again to the new average yaws of the controllers.

A benefit of using this method is that the base station rotation offset isn't relevant at all in regards to calculating body rotation. It doesn't matter which way you are facing, how the controllers are oriented or where the base station is, the rotation will always be accurate and self correcting. It ensures it is impossible to accidentally have your game body facing the opposite direction of your head. Then you can use the controllers' delta pitch+vertical position for orienting the shoulders in-game for leaning, and on top use the Rift 'neck model' to position the camera on the shoulders with its relation to gravity.


With the above implemented, everything works out fine as far as keeping your head control unlinked from your body control in-game. But where the super secret sauce lies is figuring out how to offset the in-game world rotation from your real world rotation, so that the game world and real world can be just as seemingly unlinked from each other relative to your body (even though they're directly linked), as your head+body rotation are relative to your head (even though they're directly linked). Let me explain. Your brain has taught itself throughout your entire lifetime that when you want to rotate only your body, and based on you staring at something, to automatically negate the body rotation on your head by rotating your head the opposite direction, keeping it stationary while your body moves. Literally, without you even noticing at all, it subtly takes care of head rotation for you by counteracting it, just because it assumes you intend to continue staring at something. We need to make the game world rotating separately from the real world exactly as unnoticeable as that. And we can only do that by making your subconscious do the heavy lifting.

With controlling the game world rotation, if you can do it just right, after only a few minutes of playing the game, you should lose the perception that the game world rotation relative to you isn't still matched by the world rotation of reality. When you take the Rift off and come out of the game world, you should be instinctively surprised that you are still facing the same direction on your chair that you were when you first put it on. And if you're standing up, and actually spinning around with the Rift, your game world should more closely match reality than when sitting, because you have no need to use your shoulders for input. When you're sitting down though, it needs to train your brain that by it utilizing your shoulders for body rotation, it is causing equivalent change to what it is experiencing (seeing the world rotate). It is exactly the same thing that your brain does if you were to start pushing yourself around in a wheelchair, driving a car, or riding around on a Segway. Motion sickness is directly caused by any disconnect from this vital brain adaptation function, and the brains control of reality.

My secret sauce for making this all work correctly is to derive your 'staring' intention by the way you rotate your your head+shoulders together, and to rotate the world around you by 'ratcheting' up to your previous shoulder position, from the new head+shoulder rotation. In essence, by subconsciously teaching you the head+shoulders ratcheting maneuver, you associate both the unlocked, outward ratcheting of your shoulders toward your head position to what your head+shoulders are doing in real life (which are the same), and the locked, inward ratchet of your head+body movement to that of your hips/legs in real life, rotating the world around you as if you were standing. To put it a little more basically, I want to use your ingrained 'staring' counter-body head-movement against you, by now forcing you to associate it directly to sitting-based world rotation. This causes your brain to unknowingly over-compensate this world rotation by a factor of two with your head, and secretly returns your head back to its neutral 'forward' position relative to your body. It made you believe that you rotated your body 90 degrees, when actuality you haven't rotated even an inch. Your brain keeps the game world perception in check, because it thinks it is still in control.

------------------

I hope that explanation was good enough to at least vaguely get across what I'm trying to accomplish. Sorry for the wall of text .

The only hard part that I have left to get functioning right is the 'staring' intention I was just referring to. It involves tons of conditional logic and testing to get exactly right. My only priority right now is getting this world rotation working, to at the very least prove it can in fact be done.

After that, all that's left is the controller button implementation, which should be really quick to do, and that leaning positional stuff later on. I'm hoping to maybe leave the leaning, 3-dimensional camera transform stuff to you two experts who actually know what you're doing . It would probably take me more than a week

Now, back to work I go

[StellaArtois]

I'd love to see what you've got; I'm not afraid of intricate math . Since the code is licensed as LGPL, yes, you'll need to include the sources (or how to get the sources) for any modifications you release. The simplest way is just to fork the project on github and push your changes up there.

I'm not really that experienced with forks/pushes and all that github stuff unfortunately. So I guess it's about time for me to figure it all out.

Probably the best way to handle multiple hydra behaviors is to split off the controller polling code into a static-ish class and have two different IBodyAimController implementations, both of which get their updates from the single (static) hydra plugin/manager. I'll be doing something similar to that when I add my "hybrid" controller method, though it sounds like you've already got that.

I might get to that once everything's working the way I need it to. It doesn't sound like it would be too hard to implement.

Does this use the hydra for head/body position tracking, or just a single for "rotation"?

So what the hydra controllers are actually used for are use as left and right 'shoulder' inputs. It is intended that you strap a hydra to each shoulder to help calculate intended body movement, and then you use a controller in your hands for additional button input. You can also use the hydra buttons as the button input instead if you choose to, but you would have to continually hold the controllers up to your shoulders (and I imagine that would be tiring for anything more than 10-15 minutes tops). The ideal way would be to have 2 sets of hydra, one set for your hands and one smaller, button-less set for shoulder positioning.

The default body 'center/forward' is calculated by taking the average yaw of both controllers. Then from that point on, all rotation changes for the body are calculated by a common delta between the two controller yaws (Body won't move if only one shoulder is moving. Both must move together, and body changes by the smaller value). This allows you to twist your 'body' left and right while keeping the camera yaw stationary/locked with your head. To keep your head and body centered correctly after the initial calibration, I'm using a head 'keyhole' that detects when your head rotates further than what is physically possible, more than 90 degrees relative to your shoulders. This is a 1:1 match to our 'natural' kinematic head keyhole; our shoulders. When ever the head passes this keyhole, the body 'center/forward' is reset again to the new average yaws of the controllers.

A benefit of using this method is that the base station rotation offset isn't relevant at all in regards to calculating body rotation. It doesn't matter which way you are facing, how the controllers are oriented or where the base station is, the rotation will always be accurate and self correcting. It ensures it is impossible to accidentally have your game body facing the opposite direction of your head. Then you can use the controllers' delta pitch+vertical position for orienting the shoulders in-game for leaning, and on top use the Rift 'neck model' to position the camera on the shoulders with its relation to gravity.


With the above implemented, everything works out fine as far as keeping your head control unlinked from your body control in-game. But where the super secret sauce lies is figuring out how to offset the in-game world rotation from your real world rotation, so that the game world and real world can be just as seemingly unlinked from each other relative to your body (even though they're directly linked), as your head+body rotation are relative to your head (even though they're directly linked). Let me explain. Your brain has taught itself throughout your entire lifetime that when you want to rotate only your body, and based on you staring at something, to automatically negate the body rotation on your head by rotating your head the opposite direction, keeping it stationary while your body moves. Literally, without you even noticing at all, it subtly takes care of head rotation for you by counteracting it, just because it assumes you intend to continue staring at something. We need to make the game world rotating separately from the real world exactly as unnoticeable as that. And we can only do that by making your subconscious do the heavy lifting.

With controlling the game world rotation, if you can do it just right, after only a few minutes of playing the game, you should lose the perception that the game world rotation relative to you isn't still matched by the world rotation of reality. When you take the Rift off and come out of the game world, you should be instinctively surprised that you are still facing the same direction on your chair that you were when you first put it on. And if you're standing up, and actually spinning around with the Rift, your game world should more closely match reality than when sitting, because you have no need to use your shoulders for input. When you're sitting down though, it needs to train your brain that by it utilizing your shoulders for body rotation, it is causing equivalent change to what it is experiencing (seeing the world rotate). It is exactly the same thing that your brain does if you were to start pushing yourself around in a wheelchair, driving a car, or riding around on a Segway. Motion sickness is directly caused by any disconnect from this vital brain adaptation function, and the brains control of reality.

My secret sauce for making this all work correctly is to derive your 'staring' intention by the way you rotate your your head+shoulders together, and to rotate the world around you by 'ratcheting' up to your previous shoulder position, from the new head+shoulder rotation. In essence, by subconsciously teaching you the head+shoulders ratcheting maneuver, you associate both the unlocked, outward ratcheting of your shoulders toward your head position to what your head+shoulders are doing in real life (which are the same), and the locked, inward ratchet of your head+body movement to that of your hips/legs in real life, rotating the world around you as if you were standing. To put it a little more basically, I want to use your ingrained 'staring' counter-body head-movement against you, by now forcing you to associate it directly to sitting-based world rotation. This causes your brain to unknowingly over-compensate this world rotation by a factor of two with your head, and secretly returns your head back to its neutral 'forward' position relative to your body. It made you believe that you rotated your body 90 degrees, when actuality you haven't rotated even an inch. Your brain keeps the game world perception in check, because it thinks it is still in control.

------------------

I hope that explanation was good enough to at least vaguely get across what I'm trying to accomplish. Sorry for the wall of text .

The only hard part that I have left to get functioning right is the 'staring' intention I was just referring to. It involves tons of conditional logic and testing to get exactly right. My only priority right now is getting this world rotation working, to at the very least prove it can in fact be done.

After that, all that's left is the controller button implementation, which should be really quick to do, and that leaning positional stuff later on. I'm hoping to maybe leave the leaning, 3-dimensional camera transform stuff to you two experts who actually know what you're doing . It would probably take me more than a week

Now, back to work I go

Nibre, very interesting idea, and thanks for sharing it!

So please excuse me if I have got the wrong end of the stick, or missed important concepts. Am I right in saying that basically:

- Hydras are strapped to each shoulder; average yaw value is taken on calibration - this is your 'neutral' position.
- If you move your left shoulder back, and the right shoulder forward, you begin a rotation of your in game body to the left.
- As you move your shoulders back to a neutral position, the rotation subsides.
- During this rotation, your head yaw *will not change* until you hit a keyhole of 90degrees body rotation; then your view yaw will rotate fixed to body rotation.

Is that a fair summary? Or a hopeless misunderstanding?

[StellaArtois]

Mark and Stella, I've avoided asking any general timescales for anything up to now, but I am going to ask just this once since I'm going to be doing probably my one and only demo.

Next weekend I'm off down to Leeds to meet up with a few friends and demo the rift to them and more. I've been planning and putting together what to show them, and the main thing I'm excited to show is obviously Minecrift. I'm planning on showing them a bit around Metacraft, but also FyreUK since they have some truly astonishing megabuilds. However, Fyre is currently running 1.5.2, and that build is seriously behind.
So the only time I'm ever going to ask - Will you be able to push a more recent build of 1.5.2 before next weekend?
In addition to this, I'm obviously incredibly excited about the new distortion shader, and I'd like to be showing the rift, the game and the mod off in the best of lights. I don't know how much work it is to release the current build for a previous version, but considering you don't do it particularly often I'm assuming it's a decent bit. In that same vein, will the distortion shader be finished before the next 1.5.2 build, and will it be a fairly simple job to release it all on said 1.5.2?

The shader obviously isn't a neccesity, that's just more curiosity, but I'd seriously appreciate a 1.5.2 build for when I go down. I feel like I'd be doing the thing a disservice if I wasn't showing off the latest build of the mod =p

The work you two have been doing is absolutely fantastic, I cannot believe just how thorough everything has been in my testing. Hopefully since it seems like the heatwave is over now I'll be able to play a bit more as of next week, and as I'm sure you are aware I'll report anything I find out of the ordinary =p
If you want me to test anything spesifically or need any feedback on any aspect, just ask and I'll be more than happy to give you my analysis or opinion. I'd really like to help as much as I can with this project =]

Thanks!

Regarding the shader optimisation, stage 1 of my planned improvements is in (next build - #106).

Stages are:

1. Use VBOs for distortion shader
2. Provide texture lookup version of the shader
3. Move away from ARBShaderObjects

and then slightly separately

4. Implement VBO support for all Minecraft draw calls

although I've no idea if they will make any difference at the moment TBH. I've tried 1. on my laptop, while on vacation, with no Rift available. It makes little to no difference on that setup as far as I can tell. So don't get your hopes up on that front! The texture lookup stuff may make it in before the weekend, but no promises. Please let me know how you get on with #106 when it appears.

On the 1.5.2 front, it should be 'just a back merge' with some git black magic; that said I haven't previously done it (Mark's always done that). I need to learn to give Mark a break! So again, no promises on that one (sorry).

[StellaArtois]

And sorry, can't resist; it's 3.20am here and this is post 300!

[Jademalo]

Regarding the shader optimisation, stage 1 of my planned improvements is in (next build - #106).

Stages are:

1. Use VBOs for distortion shader
2. Provide texture lookup version of the shader
3. Move away from ARBShaderObjects

and then slightly separately

4. Implement VBO support for all Minecraft draw calls

although I've no idea if they will make any difference at the moment TBH. I've tried 1. on my laptop, while on vacation, with no Rift available. It makes little to no difference on that setup as far as I can tell. So don't get your hopes up on that front! The texture lookup stuff may make it in before the weekend, but no promises. Please let me know how you get on with #106 when it appears.

On the 1.5.2 front, it should be 'just a back merge'; that said I haven't previously done it (Mark's always done that). I need to learn to give Mark a break! So again, no promises on that one (sorry).

No problem, thanks a lot for the extra info and your roadmap! 1.5.2 not a supermassive issue since there is still the old build, but it would certainly be nice.
Also, did you have a nice holiday? =]

Also also, I feel really dumb (+ curious!), but what's a vbo? I'm assuming something like virtual buffer object, but I have no idea what that is
In that vein, what advantage do phases 1 and 4 have?

Also, haha, grats! =p

[Nibre]

Nibre, very interesting idea, and thanks for sharing it!

So please excuse me if I have got the wrong end of the stick, or missed important concepts. Am I right in saying that basically:

- Hydras are strapped to each shoulder; average yaw value is taken on calibration - this is your 'neutral' position.
- If you move your left shoulder back, and the right shoulder forward, you begin a rotation of your in game body to the left.
- As you move your shoulders back to a neutral position, the rotation subsides.
- During this rotation, your head yaw *will not change* until you hit a keyhole of 90degrees body rotation; then your view yaw will rotate fixed to body rotation.

Is that a fair summary? Or a hopeless misunderstanding?

Pretty close;
- Hydras are strapped to each shoulder; average yaw value is taken on calibration - this is your 'neutral' position.
- If you move your left shoulder back, and the right shoulder forward at the same time, you rotate your in game body to the left the exact amount they rotated together that tick.
- As you move your shoulders together back to a neutral position, the exact amount they rotated together this tick (so backwards this time) is added to body rotation, again bringing your body back to a neutral position with your head.
- If you move only your left shoulder, nothing at all happens (because right shoulder has 0 change that tick, together they share 0 common change)
- If you move only your right shoulder, nothing at all happens (because left shoulder has 0 change that tick, together they share 0 common change)
- During this rotation, your head yaw *will not change*. If you hit a keyhole of 90degrees of head rotation (relative to body position); then your body yaw will again recalibrate the 'neutral' body position to the average yaw value of the shoulders.

[mabrowning]

VBO is a vertex buffer object. Basically, instead of sending the full geometry of <something> to the graphics card every single frame, we send it down to a buffer in VideoRAM and get a buffer index. Then, you can later say "draw buffer #941" and that results in theoretically better performance.

Frankly, we have 2 triangles(4 vertices) that we're using in the distortion and in each FSAA step for a total of 12 vertices @ ~20bytes each. I'm pretty sure we measure memory bus bandwidth in GB/s or TB/s, so 60*240bytes is hardly going to make a dent.


And I think Optifine already uses GL Display Lists (which is another way of achieving what a VBO does, though in a less flexible (and deprecated) way), so the performance impact of moving the entire game rendering to VBOs may or may not be worth it.

Now, some news. I've completed the backport of new features to the 1.5.2 and 1.4.7 branch. Some of those new features were specifically added to make future backports easier, so I'll try to keep the old builds up-to-date(ish) now that every single merge doesn't require manual intervention(hopefully). (I love parenthetical statements today).

On the 1.5.2 front, it should be 'just a back merge' with some git black magic; that said I haven't previously done it (Mark's always done that). I need to learn to give Mark a break! So again, no promises on that one (sorry).

Oh, there is no black magic involved. Just judicious use of `git merge <SHA1-of-last-commit-before-1.6.2>` to get all the changes before the forward port followed by `git merge --strategy=ours <SHA-1-of-last-commit-IN-1.6.2-forward-port>` to skip over all the forward-port mess (strategy=ours does a "merge" but doesn't make any change to the target branch; just updates the source branch's HEAD's "parent" to the target commit so future merges between those branches share that as a baseline). Finally, `git merge master` to get all the changes made since the 1.6.2 switchover. At that point, there are quite a few merge conflicts because of the differences between underlying 1.4.7/1.5.2/1.6.2 codebases that needed to be manually resolved. (They changed how textures are bound, how language translation works, the packages of a few key classes, and there are a few less helper methods in older code). Finally, `git cherry-pick` any commits that slipped through the merge crack. Congrats, you've just backported a series of changes!

The next step is getting an installer for 1.4.7 and 1.5.2; should be easy enough, I abstracted away the versions there, so hopefully a 1 line change. The backported 1.6.2 libraries need the new launcher anyway, so the installer is more than a nice-to-have.

[mabrowning]

Pretty close;
- Hydras are strapped to each shoulder; average yaw value is taken on calibration - this is your 'neutral' position.
- If you move your left shoulder back, and the right shoulder forward at the same time, you rotate your in game body to the left the exact amount they rotated together that tick.
- As you move your shoulders together back to a neutral position, the exact amount they rotated together this tick (so backwards this time) is added to body rotation, again bringing your body back to a neutral position with your head.
- If you move only your left shoulder, nothing at all happens (because right shoulder has 0 change that tick, together they share 0 common change)
- If you move only your right shoulder, nothing at all happens (because left shoulder has 0 change that tick, together they share 0 common change)
- During this rotation, your head yaw *will not change*. If you hit a keyhole of 90degrees of head rotation (relative to body position); then your body yaw will again recalibrate the 'neutral' body position to the average yaw value of the shoulders.

I feel like you're wasting half (or more) of the information in the hydras. Both controllers report position AND orientation, but it seems like you're using two controllers' position data to calculate an orientation. You could instead just attach a single controller to the body and use that for your orientation and ratcheting. That particular control scheme is on my TODO list (like the HydraDeck demo, but with automatic calibration instead of all the manually input parameters).

[mabrowning]

Note to self... never say "should be a 1 line change" again...

1.5.2 installer is still forthcoming. Somehow I screwed up reobfuscation?

[SkoobyDoo]

Code: Select all

Client> 2013-08-05 23:54:56 [SEVERE] [ForgeModLoader] The minecraft jar file:/C:/Users/KEvin/AppData/Roaming/.minecraft/libraries/net/minecraft/Minecraft/1.6.2/Minecraft-1.6.2.jar!/net/minecraft/client/ClientBrandRetriever.class appears to be corrupt! There has been CRITICAL TAMPERING WITH MINECRAFT, it is highly unlikely minecraft will work! STOP NOW, get a clean copy and try again!
Client> 2013-08-05 23:54:56 [SEVERE] [ForgeModLoader] FML has been ordered to ignore the invalid or missing minecraft certificate. This is very likely to cause a problem!
Client> 2013-08-05 23:54:56 [SEVERE] [ForgeModLoader] Technical information: ClientBrandRetriever was at jar:file:/C:/Users/KEvin/AppData/Roaming/.minecraft/libraries/net/minecraft/Minecraft/1.6.2/Minecraft-1.6.2.jar!/net/minecraft/client/ClientBrandRetriever.class, there were 0 certificates for it
Client> 2013-08-05 23:54:57 [INFO] [ForgeModLoader] Launching wrapped minecraft
Client> 2013-08-05 23:54:57 [SEVERE] [ForgeModLoader] There is a binary discrepency between the expected input class net.minecraft.client.Minecraft (ats) and the actual class. Checksum on disk is eda19954, in patch aa95f186. Things are probably about to go very wrong. Did you put something into the jar file?
Client> 2013-08-05 23:54:57 [SEVERE] [ForgeModLoader] The game is going to exit, because this is a critical error, and it is very improbable that the modded game will work, please obtain clean jar files.
Game ended with bad state (exit code 1)
Ignoring visibility rule and showing launcher due to a game crash
Deleting C:\Users\KEvin\AppData\Roaming\.minecraft\versions\minecrift-1.6.2-b105-forge\minecrift-1.6.2-b105-forge-natives-27026958871381

Can't seem to get it working. Procedure im using to get this is:

• -delete .minecraft in %appdata%
  -Redownload and launch minecraft 1.6.2
  -install forge using the installer
  -run forge profile titled "Forge"
  -run minecrift installer with admin rights, check install with forge and hydra support buttons
  -change Forge profile to use the appropriate jar file
  -launch the newly adapted Forge profile (I also rename it minecrift at this point)

Any help?

[mabrowning]

You need to add "-Dfml.ignorePatchDiscrepancies=true" to the JVM arguments in the Profile Editor.

[mattyeatsmatts]

Love this mod

[mabrowning]

Ok..... 1.5.2-b11 was working well enough for me. Didn't do extensive testing, but got in game and tried out the newer features (Controller support etc).

1.4.7 support should be relatively straightforward; there weren't any massive problems with creating the 1.5.2 installer, just lots of little ones. Should have most of them worked out; the build system between 1.4.7 and 1.5.2 is very similar (and now they are both more similar to 1.6.2 than before).

Just to put a few things in perspective. If I would have put my hours today towards actual work, this backport alone would be worth a few $100... haha oh well. Have it for free, you lucky sods!

[SkoobyDoo]

added it, still getting errors.

[Jademalo]

Ok..... 1.5.2-b11 was working well enough for me. Didn't do extensive testing, but got in game and tried out the newer features (Controller support etc).

Thank you so much! That was incredibly quick

Just to put a few things in perspective. If I would have put my hours today towards actual work, this backport alone would be worth a few $100... haha oh well. Have it for free, you lucky sods!

:O
I feel bad now =[


Thanks for the quick explanation on VBOs too, and sorry again for the questions - I like to know roughly how stuff works so I'm not totally left guessing.

[mabrowning]

I feel bad now =[

Don't worry about it. I had already actually worked for 11 hours yesterday anyway; I couldn't have put any more time in at the "office" if I'd wanted to.

I don't even want to calculate what the total cost of this project has been... but the thing is, it isn't a cost. I love working on this stuff, but if I hadn't, I sure wouldn't have been pursuing money-making exploits. Probably just playing videogames instead of making them. I wrote that post last night as a "I can't believe its already 3am" type frustration, not a "you people are freeloaders!" one. I'm super-stoked by all the feedback and suggestions, so don't worry! And don't feel bad!