Minecrift Discussion Thread

[Jademalo]

Glad you're enjoying it at least!

After further experimentation, it seems that Half Life 2 has exactly the same issues. It's sluggish with distortion on, and gets worse with AA. In this situation, I would normally say the cause was my setup, but Tuscany is really throwing a spanner in the works...

[StellaArtois]

Alright, I've toyed around with the shader code enough for one night. I produced some interesting results, but I'm not sure what it means yet...

In other happy news, I've figured out how to make FSAA work on OSX. I may be doing some shader surgery to reduce the number of rendering passes... no idea if that will help the distortion rending, though. This stuff is fun ^_^

Nice one narrowing it down to the distortion shader then. We need to enlist ben again to help us optimise the shader at the same time...!

Oh, and leave me some stuff to fix

[StellaArtois]

Sounds like you guys could really do with that latency checker device Oculus were talking about a few months back!

Have my name down for one; waiting for them to pull the trigger and release it!

[StellaArtois]

Hey guys just tried minecrift for the first time and I wanted to say well done, good work and thank you! It's the best game experience for the rift so far for me.. I've played a few hours of HL2 too but that's too intense and really makes me feel ill after a while! I love minecraft and this will reinvigorate the game for me. Little bit queasy, but I haven't got my VR legs yet!

Thanks daveo2013! Be sure to give us some critical feedback as you start to get your VR legs...

[pringle444]

I'm getting constant spinning when using a hydra for positional tracking - no amount of restarting/recalibrating seems to help. Any tips?

[Jademalo]

Bed time for me again, a bit more experimenting produced no better results. I've got the latency down as low as it will go.

As a side note, after some testing of TF2 and HL2, they too have a similar kind of lag to this, although it's low enough to not be noticible without any AA. Enable that though, and the same effect happens as in Minecrift.

[mabrowning]

Bed time for me again, a bit more experimenting produced no better results. I've got the latency down as low as it will go.

As a side note, after some testing of TF2 and HL2, they too have a similar kind of lag to this, although it's low enough to not be noticible without any AA. Enable that though, and the same effect happens as in Minecrift.

I'm working on an optimized Distortion shader using texture lookups instead of computing the barrel distortion parameter every single pixel. In Minecraft, I bet we have plenty of texture lookup bandwidth unless people throw on 128x128 texture packs

[mabrowning]

I'm getting constant spinning when using a hydra for positional tracking - no amount of restarting/recalibrating seems to help. Any tips?

That actually caused by the other hydra used for aiming. Aim it "forward" to prevent spinning. Right now I have some stupid velocity based keyhole aiming that I really need to change and add more options.

[Jademalo]

Bed time for me again, a bit more experimenting produced no better results. I've got the latency down as low as it will go.

As a side note, after some testing of TF2 and HL2, they too have a similar kind of lag to this, although it's low enough to not be noticible without any AA. Enable that though, and the same effect happens as in Minecrift.

I'm working on an optimized Distortion shader using texture lookups instead of computing the barrel distortion parameter every single pixel. In Minecraft, I bet we have plenty of texture lookup bandwidth unless people throw on 128x128 texture packs

Oooh! That sounds interesting
(Also, I'm guilty of using Sphax, guess I'll have to switch to my old Doku one =p)

EDIT: I should add that any testing has been done with default, though.

[NewTruthNeomaxim]

Sorry, didn't mean to imply you were in the wrong place Neo
Perhaps I should have said that this is the dev/questions thread, so you're in the right place

I should add, great work on the minecrift project ma, Stella. It's refreshing to see community endeavors like this overtake/beat the official studios. Gotta love the community spirit I'm seeing everywhere surrounding the rift. I thinks that's what tipped me over the "Buy a dev kit/wait for consumer" line.

Can't wait till mine arrives and I can get my head into minecraft

No worries man, and thank you to both you and the Minecrift creator for the answers. I now have to simply sit on my hands as I await my Rift. It sounds like you've done amazing things with a game that is sure to be a tech demo for this amazing machine.

[Jademalo]

Mark, but of a strange question, apologies if I'm completely on the wrong track -
Is it worth the effort to attempt to downscale the image that has been Anti Aliased, and then apply the distortion to that. I was thinking, and that would at least make AA usable without impacting the distortion shader's lag for the time being, at least until you finish the new shader.
If it's a big job, don't bother, but if it's not too much hassle it would undoubtedly be an improvement.

Also a suggestion; would it be possible to add an option that chose which numbered monitor the game was fullscreened on? It would make maxing it on the Rift a lot easier. (If possible, even force fullscreen on whichever the monitor the rift is. iRacing does that, and it's seriously convenient)

Also, is it ever going to be possible to select which Oculus profile is used rather than just selecting the default?

[StellaArtois]

Mark, but of a strange question, apologies if I'm completely on the wrong track -
Is it worth the effort to attempt to downscale the image that has been Anti Aliased, and then apply the distortion to that. I was thinking, and that would at least make AA usable without impacting the distortion shader's lag for the time being, at least until you finish the new shader.
If it's a big job, don't bother, but if it's not too much hassle it would undoubtedly be an improvement.

Also a suggestion; would it be possible to add an option that chose which numbered monitor the game was fullscreened on? It would make maxing it on the Rift a lot easier. (If possible, even force fullscreen on whichever the monitor the rift is. iRacing does that, and it's seriously convenient)

Also, is it ever going to be possible to select which Oculus profile is used rather than just selecting the default?

NINJA EDIT: So currently, with FSAA and distortion ON, we render at (supersample scale factor) * (distortion oversample scale factor) * normal in game resolution. No anti-aliasing is applied to that large image. Then we distort the image (which also shrinks it). Then we downsample using a Lanczos filter to the display size (and that's the bit that anti-aliases the image).

I previously considered downsampling before distortion. That sort of goes against the point of downsampling - to remove artifacts; however I did try it. New artifacts were introduced however - it didn't look too good! We just need to optimise the distortion shader really. I've got the shader going here without using immediate (legacy) openGL mode. Still some stuff to work out, but we're getting there. If Mark gets the shader itself optimised (he's on it) I think we'll be good.

We want to look at the 'fullscreen on the rift' option at some point soon. It should be on the tracker already I hope!

[StellaArtois]

And regarding the Oculus profile; unless I've got it totally wrong, the Oculus driver only reports the currently selected profile to us. That's the one we use.

I may have missed something during implementation however! I was expecting a list of profiles from the driver to be honest.

[Jademalo]

I previously considered downsampling before distortion. That sort of goes against the point of downsampling - to remove artifacts; however I did try it. New artifacts were introduced however - it didn't look too good! We just need to optimise the distortion shader really. I've got the shader going here without using immediate (legacy) openGL mode. Still some stuff to work out, but we're getting there. If Mark gets the shader itself optimised (he's on it) I think we'll be good.

We want to look at the 'fullscreen on the rift' option at some point soon. It should be on the tracker already I hope!

Alright, it was just a thought!
I had a good few hours earlier, it really is fantastic. Knackered my neck though, the rift is heavy

Can't wait for the new shader, fingers crossed it's amazing!
On another note, prediction 35 does make a substantial difference if I up the distortion border. A combination of the two makes it /just/ sensitive enough for me to play for a while, but since I stopped earlier I've had almost 5 hours of blerg >_<

And regarding the Oculus profile; unless I've got it totally wrong, the Oculus driver only reports the currently selected profile to us. That's the one we use.

I may have missed something during implementation however! I was expecting a list of profiles from the driver to be honest.

That sounds really bizzare :S
Is the currently selected one the one you have set to default? That seems like a massive faf.

[TheHolyChicken]

And regarding the Oculus profile; unless I've got it totally wrong, the Oculus driver only reports the currently selected profile to us. That's the one we use.

I may have missed something during implementation however! I was expecting a list of profiles from the driver to be honest.

Oh really? :/ I just assumed you would get the list of profiles - that would allow you to change profiles in-game on the fly. I might write them an email to suggest it, if that's not the case....

[StellaArtois]

I previously considered downsampling before distortion. That sort of goes against the point of downsampling - to remove artifacts; however I did try it. New artifacts were introduced however - it didn't look too good! We just need to optimise the distortion shader really. I've got the shader going here without using immediate (legacy) openGL mode. Still some stuff to work out, but we're getting there. If Mark gets the shader itself optimised (he's on it) I think we'll be good.

We want to look at the 'fullscreen on the rift' option at some point soon. It should be on the tracker already I hope!

Alright, it was just a thought!
I had a good few hours earlier, it really is fantastic. Knackered my neck though, the rift is heavy

Can't wait for the new shader, fingers crossed it's amazing!
On another note, prediction 35 does make a substantial difference if I up the distortion border. A combination of the two makes it /just/ sensitive enough for me to play for a while, but since I stopped earlier I've had almost 5 hours of blerg >_<

And regarding the Oculus profile; unless I've got it totally wrong, the Oculus driver only reports the currently selected profile to us. That's the one we use.

I may have missed something during implementation however! I was expecting a list of profiles from the driver to be honest.

That sounds really bizzare :S
Is the currently selected one the one you have set to default? That seems like a massive faf.

Ack! Blergh not good.

Again, I may be missing something on the profiles. I'm not really up to speed on any other in-game / demo implementations of the Oculus Profile - do they allow profile selection by name?

[Jademalo]

Ack! Blergh not good.

Again, I may be missing something on the profiles. I'm not really up to speed on an other in-game / demo implementations of the Oculus Profile - do they allow name selection?

I haven't actually come across another demo with it implemented. Heck, I can't even tell if tuscany has.
It seems really bizzare if they don't though...

Actually... Thinking, stereoificator might. However, it only has one profile thing under user, titled default. It did have my IPD though.
It must only report default at present. That's so strange

[mabrowning]

We can of course go to the source: find where Oculus stores the profiles and read from there

Stella: what we need to do is use the Tesselator class instead of drawing our own quads. That already supports using VBO if they are available or other ways if not. Then, we could support OSX, which limits you to OpenGL Core 3.2 (minecraft uses deprecated features removed from this profile) OR OpenGL 2.1.

I thought I had come up with a way of merging the last step of the FSAA and distortion.. and I may yet get it to work... but for now I'm probably just going to implement the indirect texture coordinate optimization (store the texture coordinates of the post-distroted buffer in a pre-computed texture themselves)

[StellaArtois]

And regarding the Oculus profile; unless I've got it totally wrong, the Oculus driver only reports the currently selected profile to us. That's the one we use.

I may have missed something during implementation however! I was expecting a list of profiles from the driver to be honest.

Oh really? :/ I just assumed you would get the list of profiles - that would allow you to change profiles in-game on the fly. I might write them an email to suggest it, if that's not the case....

I'd guessed this was their first iteration on the profile support. It's quite 'lean' at the moment, but seems to work.

[StellaArtois]

We can of course go to the source: find where Oculus stores the profiles and read from there

Stella: what we need to do is use the Tesselator class instead of drawing our own quads. That already supports using VBO if they are available or other ways if not. Then, we could support OSX, which limits you to OpenGL Core 3.2 (minecraft uses deprecated features removed from this profile) OR OpenGL 2.1.

I thought I had come up with a way of merging the last step of the FSAA and distortion.. and I may yet get it to work... but for now I'm probably just going to implement the indirect texture coordinate optimization (store the texture coordinates of the post-distroted buffer in a pre-computed texture themselves)

Right. Tesselator class it is; didn't realise it had the backwards compat stuff in there (but should have guessed). On it!

Merging the last step of FSAA and distortion? Surely the first step with distortion could work, but the last? What kind of black magic were you cooking up?

[mabrowning]

Merging the last step of FSAA and distortion? Surely the first step with distortion could work, but the last? What kind of black magic were you cooking up?

"The first shall be last and the last shall be first."

[StellaArtois]

Merging the last step of FSAA and distortion? Surely the first step with distortion could work, but the last? What kind of black magic were you cooking up?

"The first shall be last and the last shall be first."

Ok. Black magic indeed!

[mabrowning]

Sorry no, just mixed up my words!

[Render] → Render FBO → [DIstortion + x-lanczos shader] → Intermediate FBO → [y-lanczos shader] → Output FB

[StellaArtois]

Ok cool!

[Jademalo]

Gah I'm so hype for this, it's a nightmare though because TI3 is starting tomorrow!
Hopefully I can find some time to play =]

[Tbone]

I'm getting constant spinning when using a hydra for positional tracking - no amount of restarting/recalibrating seems to help. Any tips?

That actually caused by the other hydra used for aiming. Aim it "forward" to prevent spinning. Right now I have some stupid velocity based keyhole aiming that I really need to change and add more options.

My Hydra arrives today. Does this mean that the Hydra's current implementation is busted and not recommended? I was looking forward to testing it out.

[mabrowning]

Oh, it certainly "works". Being able to mine in a given direction by pointing the hydra there is really neat! I wouldn't call it busted, but I also don't think I'd like playing with it as it for more than 10 minutes, since if you point it too far left or right, you'll "spin".

[Tbone]

I spent a little bit of time in this and other demos that involve the Hydra. I can't get positional tracking to work out right for the life of me, in any demo. Minecraft also has too many keybinds to be limited to one controller, I think. I'm determined to get positional tracking working in SOMETHING, though!

[Jademalo]

I got positional working in Minecrift with mine, so it certainly works. Played for an hour or so with it. It's not perfect, but it's certainly neat

[NeoCortex]

Maybe we need to share some info about how and where to fix the hydra to the Rift, as it seems to be hard to reproduce any setting or problem without knowing where to start from. The setup i tried yesterday was as follows:
Hydra base positioned to the left of my keyboard, maybe 30cm to the left and 40cm to the front of the center of my body.
The left Hydra controller strapped in the middle of the top head band of the Rift, above the center of my head, cable running to the base at the left and straight down.
I took the right controller in my right hand.
As for calibrating: first of all i had several crashes to desktop each time i called the calibrate routine (i should have copied the output ), then i pointed each controller to the base holding them a bit left from my body (which was a bit weird with that left one strapped to the Rift).
I also encountered the (horizontal) spinning and played with some of the sensitivities but finally went back to using the mouse for aiming.
Continuing that would have been an instand ticket to puketown
The positional tracking worked fine, though i still feel it needs some minor tweaking (hard to spot and i am still growing my VR feet, so i cant stay in that long). but e.g. turning my head far left or right started the screen rotating and that made me feel immediately sick.
Would it be possible to start that kind of rotating with a very slowly rising speed ramp so one could influence the turning speed by the amount of head spin?
You know what? It feels great to be a part of this community, building the foundation of out future virtual worlds!
cu all there soon, i hope,
Neo
(hmm, seems we have two Neo's here now, but hey there are a lot of John's and Jane's out there too ^^)

[StellaArtois]

Maybe we need to share some info about how and where to fix the hydra to the Rift, as it seems to be hard to reproduce any setting or problem without knowing where to start from. The setup i tried yesterday was as follows:
Hydra base positioned to the left of my keyboard, maybe 30cm to the left and 40cm to the front of the center of my body.
The left Hydra controller strapped in the middle of the top head band of the Rift, above the center of my head, cable running to the base at the left and straight down.
I took the right controller in my right hand.
As for calibrating: first of all i had several crashes to desktop each time i called the calibrate routine (i should have copied the output ), then i pointed each controller to the base holding them a bit left from my body (which was a bit weird with that left one strapped to the Rift).
I also encountered the (horizontal) spinning and played with some of the sensitivities but finally went back to using the mouse for aiming.
Continuing that would have been an instand ticket to puketown
The positional tracking worked fine, though i still feel it needs some minor tweaking (hard to spot and i am still growing my VR feet, so i cant stay in that long). but e.g. turning my head far left or right started the screen rotating and that made me feel immediately sick.
Would it be possible to start that kind of rotating with a very slowly rising speed ramp so one could influence the turning speed by the amount of head spin?
You know what? It feels great to be a part of this community, building the foundation of out future virtual worlds!
cu all there soon, i hope,
Neo
(hmm, seems we have two Neo's here now, but hey there are a lot of John's and Jane's out there too ^^)

My positional track setup is as follows:

- Left Hydra taped to the left side of the Rift
- Base station slightly in front and to the left of me on my desk (the position and rotation *should* be unimportant, but I keep it as close as possible to my general head movement area, plus with the base station cables facing directly out to the back of my desk).
- Hydra offsets as per Left HMD defaults.
- EDIT for good results you MUST run the hydra / Rift calibration at startup (well at least once before playing).
- Lately I've been using mouse input to play with no issues.

When I get back from vacation I need to start fully testing Mark's new controller tweaks. The fact that if you move your head too far to the left or right creates a rotation effect sounds wrong. I'm wondering if we still have some hard-coded values within the code as to which controller is used for what - sounds to me like we're picking up the Move/Aim hydra rotation on the hydra that should be used purely for pos track. Or maybe you have the move / aim stuff enabled for the left controller?

[StellaArtois]

I spent a little bit of time in this and other demos that involve the Hydra. I can't get positional tracking to work out right for the life of me, in any demo. Minecraft also has too many keybinds to be limited to one controller, I think. I'm determined to get positional tracking working in SOMETHING, though!

Would you mind describing the issues you've had with this? Seems we still have some work todo to get this working easily 'out-of-the-box'.

That said, I'm looking forward to getting support in for the Hydra V2 with it's dedicated pos track sensor, I'm hoping that will be easier to use while still allowing the use of two controllers. Failing that it would be nice to see a pos track enabled dev Rift pop onto our doorstep!

[StellaArtois]

It's not perfect, but it's certainly neat

Would you mind elaborating Jade? Did you have any issues other than 'cable hell'?

[Jademalo]

It's not perfect, but it's certainly neat

Would you mind elaborating Jade? Did you have any issues other than 'cable hell'?

I have mine strapped in the top strap at the back of my head so I don't have to tape anything. It seems logical to put it there. When configuring, setting the direction it's pointing is inversed, and if I do it wrong then all directions are opposite. That's instant hurl city lol.
On top of that, the tracking isnt completely precise with the Hydra stationed there. sometimes you don't quite move right, and it's apparent when it happens.

The final issue is that reset origin is semi-broken when pos tracking is enabled. Neither of the Reset Origin buttons reset the direction that you're facing properly, so over time the interface can drift away. The two solutions I found were to disable positional, reset origin, reenable positional, and recalibrate with the looking left right up.
Reset origin on the main VR settings page should, im assuming, set both the origin point of the positional tracking and the current direction of facing as forward, but it seems to only do the origin if pos is enabled.

EDIT: Also, for whatever reason, it causes the framerate to TANK. Like, 30-40%.

[StellaArtois]

It's not perfect, but it's certainly neat

Would you mind elaborating Jade? Did you have any issues other than 'cable hell'?

I have mine strapped in the top strap at the back of my head so I don't have to tape anything. It seems logical to put it there. When configuring, setting the direction it's pointing is inversed, and if I do it wrong then all directions are opposite. That's instant hurl city lol.
On top of that, the tracking isnt completely precise with the Hydra stationed there. sometimes you don't quite move right, and it's apparent when it happens.

The final issue is that reset origin is semi-broken when pos tracking is enabled. Neither of the Reset Origin buttons reset the direction that you're facing properly, so over time the interface can drift away. The two solutions I found were to disable positional, reset origin, reenable positional, and recalibrate with the looking left right up.
Reset origin on the main VR settings page should, im assuming, set both the origin point of the positional tracking and the current direction of facing as forward, but it seems to only do the origin if pos is enabled.

EDIT: Also, for whatever reason, it causes the framerate to TANK. Like, 30-40%.

I asked for feedback and I got it! Thanks!

Ok, so a number of issues:

- inversion of direction on back of head. Interesting, thought I had all that sorted. I assume you've been calibrating the hydra?
- the tracking is imprecise on the back of head. Trouble with the back of head is the offsets have to match your head (quite hard), and the offsets are quite large. Any differences are magnified; and on top of that any yaw error throws things further out. Hmmm. Maybe we need to attempt to calibrate offsets as well when we (in a future release) calibrate the neck model offsets.
Alternatively getting support in for a hydra body position sensor plus neck model may be a better bet.
- origin needs fixing. Again!
- 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...]

[mabrowning]

I don't think we can calibrate the eyecenter->head hydra offset. I thought long and hard about it, but the only way to calibrate is to have a known in one reference frame that we can compare to, but we don't have one of those. Maybe we could know a priori how far away a "standard position" is. For example, placing the hydra directly under the headset under your nose. That should get us X & Y offsets pretty easily, but the Z offset wouldn't be truly known (people could have differently offset upper lips->eyes). We might get closer than having them manually enter values, though.

The other thing that I really need to do is remove all notion of using the hydra orientation (which we currently do, and the reason we ask "pointing left or pointing right". I really need to

1) Calibrate magnetometer on Rift
2) Calibrate hemisphere tracking on hydra (aim with left, trigger, aim right, trigger)
3) Lean forward and backward (with head-tracking hydra "in position"). This will allow us to associate the same direction in hydra reference frame as Oculus reference frame (assuming the user didn't wobble their head left/right). Then, THAT angle difference is what we use for "base station yaw offset". This will sort the "inverted motion"


I wonder if the framerate tanking is due to all the math we do to get the head position in place. Probably not; you're probably right with the JNI calls being responsible if any hydra is enabled. Worth looking into.

Origin recentering: I think we need to get rid of the "GUI yaw offset" and draw it solely based on the player's "move direction" With look/move coupled, it will always be "in front" of them and can't get out of alignment. If look/move is decoupled, then the GUI still marks their "move" direction, but a "recenter origin" will set their head "yaw" to 0(we'll need a new offset there) and their body (move) yaw to current body + current head yaw. A similar pattern would need to be applied to aim offset as well.

[Tbone]

I spent a little bit of time in this and other demos that involve the Hydra. I can't get positional tracking to work out right for the life of me, in any demo. Minecraft also has too many keybinds to be limited to one controller, I think. I'm determined to get positional tracking working in SOMETHING, though!

Would you mind describing the issues you've had with this? Seems we still have some work todo to get this working easily 'out-of-the-box'.

That said, I'm looking forward to getting support in for the Hydra V2 with it's dedicated pos track sensor, I'm hoping that will be easier to use while still allowing the use of two controllers. Failing that it would be nice to see a pos track enabled dev Rift pop onto our doorstep!

I'm not sure what my problem was yesterday, but I finally got Hydra positional tracking working on the Cover Shooter and on Minecrift. Today I attached it to the left side of my head and made sure it was facing the base. I had to disable using Hydra as a controller so that it wouldn't spin me if I went too far to the edges. It's pretty neat, but I noticed it was very jittery. Probably a flaw of the Hydra itself, as I noticed it in the Cover Shooter as well. Perhaps it's interference? Or maybe the Hydra just isn't precise enough?

Still, I was able to peer around corners and stuff. It seems fairly natural once you have it, though I'm not sure how long I could play with a controller strapped to the side of my head

[StellaArtois]

I don't think we can calibrate the eyecenter->head hydra offset. I thought long and hard about it, but the only way to calibrate is to have a known in one reference frame that we can compare to, but we don't have one of those. Maybe we could know a priori how far away a "standard position" is. For example, placing the hydra directly under the headset under your nose. That should get us X & Y offsets pretty easily, but the Z offset wouldn't be truly known (people could have differently offset upper lips->eyes). We might get closer than having them manually enter values, though.

The other thing that I really need to do is remove all notion of using the hydra orientation (which we currently do, and the reason we ask "pointing left or pointing right". I really need to

1) Calibrate magnetometer on Rift
2) Calibrate hemisphere tracking on hydra (aim with left, trigger, aim right, trigger)
3) Lean forward and backward (with head-tracking hydra "in position"). This will allow us to associate the same direction in hydra reference frame as Oculus reference frame (assuming the user didn't wobble their head left/right). Then, THAT angle difference is what we use for "base station yaw offset". This will sort the "inverted motion"


I wonder if the framerate tanking is due to all the math we do to get the head position in place. Probably not; you're probably right with the JNI calls being responsible if any hydra is enabled. Worth looking into.

Origin recentering: I think we need to get rid of the "GUI yaw offset" and draw it solely based on the player's "move direction" With look/move coupled, it will always be "in front" of them and can't get out of alignment. If look/move is decoupled, then the GUI still marks their "move" direction, but a "recenter origin" will set their head "yaw" to 0(we'll need a new offset there) and their body (move) yaw to current body + current head yaw. A similar pattern would need to be applied to aim offset as well.

Would it not be possible to firstly calibrate eye protrusion (as previously suggested). Then you could ask the user to rotate their head in place (maybe combined with the Rift calibration if the Rift is being used) and take a number of samples to triangulate hydra position to neck centre? Sounds a pain, but may be doable.

Actually, in general I think we should combine calibration steps where possible to give the user less of a calibration headache.

I would be surprised if any head math is causing a slow down (unless we had some unintended recursion or similar). Depends if only the pos track is causing this. Can't say I've noticed a slowdown with pos track on my machine, but then maybe I'm usually too busy noticing issues with position to notice a fps drop as well.

With you on the GUI yaw offset.

[StellaArtois]

I spent a little bit of time in this and other demos that involve the Hydra. I can't get positional tracking to work out right for the life of me, in any demo. Minecraft also has too many keybinds to be limited to one controller, I think. I'm determined to get positional tracking working in SOMETHING, though!

Would you mind describing the issues you've had with this? Seems we still have some work todo to get this working easily 'out-of-the-box'.

That said, I'm looking forward to getting support in for the Hydra V2 with it's dedicated pos track sensor, I'm hoping that will be easier to use while still allowing the use of two controllers. Failing that it would be nice to see a pos track enabled dev Rift pop onto our doorstep!

I'm not sure what my problem was yesterday, but I finally got Hydra positional tracking working on the Cover Shooter and on Minecrift. Today I attached it to the left side of my head and made sure it was facing the base. I had to disable using Hydra as a controller so that it wouldn't spin me if I went too far to the edges. It's pretty neat, but I noticed it was very jittery. Probably a flaw of the Hydra itself, as I noticed it in the Cover Shooter as well. Perhaps it's interference? Or maybe the Hydra just isn't precise enough?

Still, I was able to peer around corners and stuff. It seems fairly natural once you have it, though I'm not sure how long I could play with a controller strapped to the side of my head

It is quite jittery. On my setup if I stay within about 1m of the base, it's not bad. Any further and it really gets the jitters. The filter does help somewhat but adds latency. I may think about adding some adjustment of the filter parameters at some point, but it doesn't change the fact that inherently there is some jitter with the current Hydra.

I also have the 'not sure what the problem is but this time it works' issues with the hydra. I'd love to know what causes that. It is very annoying and quite infuriating when trying to test!

[Tbone]

Did I read that you are working on an option that attaches the UI to the look rather than anchored to the front? Because that would really save my neck a lot of grief! =D