FreeTrack Forum

First of all I would like too express my deepest feelings of admiration to the people who made FreeTrack, I think the work you've done is simply fantastic.

The only thing that I found was missing was that when looking behind you in BoB2 or Il2 you really had to move your head to the right to move your virtual head left. So I did a little research and saw a thread in this forum which mentiones a program called GlovePIE.

That gave me an idea.  

Anyway. If you type this code into GlovePIE and run it before startup of the desired game, you should get a more natural translation behaviour in afore mentioned sims:
FakeTrackIR.x = RealTrackIR.x * cos(RealTrackIR.yaw) * cos(RealTrackIR.roll) + RealTrackIR.y * (-1 * cos(RealTrackIR.pitch) * sin(RealTrackIR.roll) + sin(RealTrackIR.pitch) * sin(RealTrackIR.yaw) * cos(RealTrackIR.roll)) + RealTrackIR.z * (sin(RealTrackIR.pitch) * sin(RealTrackIR.roll) + cos(RealTrackIR.pitch) * sin(RealTrackIR.yaw) * cos(RealTrackIR.roll))

FakeTrackIR.y = RealTrackIR.x * cos(RealTrackIR.yaw) * sin(RealTrackIR.roll) + RealTrackIR.y * (cos(RealTrackIR.pitch) * cos(RealTrackIR.roll) + sin(RealTrackIR.pitch) * sin(RealTrackIR.yaw) * sin(RealTrackIR.roll)) + RealTrackIR.z * (-1 * sin(RealTrackIR.pitch) * cos(RealTrackIR.roll) + cos(RealTrackIR.pitch) * sin(RealTrackIR.yaw) * sin(RealTrackIR.roll))

FakeTrackIR.z = RealTrackIR.x * (-1 * sin(RealTrackIR.yaw)) + RealTrackIR.y * sin(RealTrackIR.pitch) * cos(RealTrackIR.yaw) + RealTrackIR.z * cos(RealTrackIR.pitch) * cos(RealTrackIR.yaw)

FakeTrackIR.pitch = RealTrackIR.pitch

FakeTrackIR.yaw = RealTrackIR.yaw

FakeTrackIR.roll = RealTrackIR.roll
And for those who don't use the roll option can implement a little less CPU consuming coordinate trasformations:
FakeTrackIR.x = RealTrackIR.x * cos(RealTrackIR.yaw) + RealTrackIR.y * sin(RealTrackIR.pitch) * sin(RealTrackIR.yaw) + RealTrackIR.z * cos(RealTrackIR.pitch) * sin(RealTrackIR.yaw)

FakeTrackIR.y = RealTrackIR.y * cos(RealTrackIR.pitch) - RealTrackIR.z * sin(RealTrackIR.pitch)

FakeTrackIR.z = RealTrackIR.x * -1 * sin(RealTrackIR.yaw) + RealTrackIR.y * sin(RealTrackIR.pitch) * cos(RealTrackIR.yaw) + RealTrackIR.z * cos(RealTrackIR.pitch) * cos(RealTrackIR.yaw)

FakeTrackIR.pitch = RealTrackIR.pitch

FakeTrackIR.yaw = RealTrackIR.yaw

FakeTrackIR.roll = RealTrackIR.roll

Note that these transformations for efficiency's sake assume that your real head rotations are kept at zero (your real head is assumed to allways look strait ahead), but even so this makes looking behind you (which due to my flying skills I do a lot   ) much more natural.

Maybe this could be implemented in the next version of freetrack?

Enjoy!  

PS
Every paragraph in the code should be in one line.

I see that not many people are very interested in this, but I've done some testing in il2 Sturmovik 6 dof mod so I would like to share a few observations.

In the 6 dof mode I noticed that with the z axis forward you move forward in the cockpit up to a point, and after you reach this point you start to zoom in, also if you move back the oposite happens, you zoom out.

Why am I explaining this? If you use global-to-local coordinate transformations from above, you'll get this effect. When looking forward everything's fine, but when looking back and zooming in you'll first move to the back of the cockpit, which is fine, but after that you will start to zoom out, which is oposite of what should happen.

This means that any game that uses the z-axis for zooming in-out, shouldn't apply z-axis transformations, but only x and y.

I've tried flying without z-axis transformations, and it feels much more natural while zooming.

The other thing I noticed was that when y-axis transformations were applied it was much easier to look over the bar in the FW190. It was like the default position in the cockpit was somehow higher.
This is probably because I keep my camera higher up, so it sees me at an angle.

So this is the code that I found works best for il2 at least:
FakeTrackIR.x = RealTrackIR.x * cos(RealTrackIR.yaw) + RealTrackIR.y * sin(RealTrackIR.pitch) * sin(RealTrackIR.yaw) + RealTrackIR.z * cos(RealTrackIR.pitch) * sin(RealTrackIR.yaw)

FakeTrackIR.y = RealTrackIR.y * cos(RealTrackIR.pitch) - RealTrackIR.z * sin(RealTrackIR.pitch)

FakeTrackIR.z = RealTrackIR.z

FakeTrackIR.pitch = RealTrackIR.pitch

FakeTrackIR.yaw = RealTrackIR.yaw

FakeTrackIR.roll = RealTrackIR.roll

In FT 2.2 I have a 'translation relative to rotation' transformation using a simple DirectX matrix rotation helper function, I couldn't assess whether your code did the same thing just by looking at it, but after testing, it appears to be the same, just in trig form. I'll stick with the optimised helper function but nice work anyway.  

Note that these transformations for efficiency's sake assume that your real head rotations are kept at zero (your real head is assumed to allways look strait ahead)

Given that the screen is the reference plane, not your head, I can't see why you would do it any other way?

This means that any game that uses the z-axis for zooming in-out, shouldn't apply z-axis transformations, but only x and y.

Unless you're not using 'translation relative to rotation' mode.

The other thing I noticed was that when y-axis transformations were applied it was much easier to look over the bar in the FW190. It was like the default position in the cockpit was somehow higher.
This is probably because I keep my camera higher up, so it sees me at an angle.

If the camera is up high it will measure downward y movement when you move forward and upward y movement when you move back.


Out of interest, in a forward cockpit view, roll your aircraft roughly 40 degrees and roll your head opposite to make the horizon level, now try to turn you head to check your six while maintaining a level horizon, to do this you need to yaw, pitch and roll your head all at the same time, which is difficult and feels unnatural. It feels like something that could be fixed up with some maths, a 'yaw and pitch relative to roll' transformation but it's impossible using absolute tracking. This is why roll is very difficult to use practically while looking around or tracking aircraft because it is unnaturally independent of yaw and pitch.

Note that these transformations for efficiency's sake assume that your real head rotations are kept at zero (your real head is assumed to allways look strait ahead)

What I meant was that if you wanted to be really accurate you could make your head the reference plane by using 2 transformations.
This means that if you rotate your head by an angle of A and the virtual head rotates by an angle of B, you would first use a transformation matrix with the angle A to convert fixed axes into real head axes and then multiply the result with a transformation matrix using an angle of A-B.

For example. If you rotate the virtual head in the yaw direction by 90deg and you rotate your real head by 30deg, and then try to move left (virtual head needs to move towards the front of the cockpit), by using only one transformation you vould have to move paralel to the screen, while by using two transformations you would do this by moving towards your left ear. I think that would be more natural since the virtual head is also moving towards it's left ear.
I would try to do this myself but I didn't find a way to acces real head rotation angles with GlovePIE.

Unless you're not using 'translation relative to rotation' mode.

It would still be nice to be able to just turn off the z-axis trasformations while maintaining x and y for games that use zoom.

Out of interest, in a forward cockpit view, roll your aircraft roughly 40 degrees and roll your head opposite to make the horizon level, now try to turn you head to check your six while maintaining a level horizon, to do this you need to yaw, pitch and roll your head all at the same time, which is difficult and feels unnatural.

I tried it. It doesnt feel that bad to me. Anyway, no sollution for that one. I don't really fly with the roll option on since rolling your head without it is really more realistic (the movement is then 1:1).

lelek @ 01/02/2008 - 18h36 a dit:

by using only one transformation you vould have to move paralel to the screen,

The translation plane is actually curved due to the camera's perspective which is not taken into consideration by the tracking algorithm.  This is  better than a flat plane for fixed screen head tracking because the leds need to point at the camera and you need to look at the monitor so a curved, monitor-centric plane, is actually better than a flat one. It also reduces the likelihood of the leds leaving the camera frame when rotating at the outer translation limits. What you're suggesting will make it harder to see the monitor and harder for the camera to see the tracking points.

while by using two transformations you would do this by moving towards your left ear. I think that would be more natural since the virtual head is also moving towards it's left ear.

Remember without head relative translation when you rotate your head to check your six, your virtual body is fixed, only your head moves and because you're looking over your shouder the x translation direction is reversed. This is both logical and realistic. But many people think it feels unnatural, why?, because you've only rotated your real head a few degrees and you're using the screen as a reference plane for translation. You expect left movement relative to the screen to correspond with a virtual movement in the same direction. Since your eyes are fixed to the screen, as far as they are concerned, you haven't rotated your head at all.

Your idea of using the real head pose as a translation reference instead of the screen would have a similar paradox,  sideways translation while looking 90 virtual degrees to the side would require some real world z-movement, so you would expect some corresponding z movement on the screen, but there won't be any. Because of this, the most natural head tracking is when the absolute translation coordinates are fixed relative to the screen.

It would still be nice to be able to just turn off the z-axis trasformations while maintaining x and y for games that use zoom.

Have you tried it yourself?

I don't really fly with the roll option on since rolling your head without it is really more realistic (the movement is then 1:1).

Each angle is optional for relative translation in 2.2.

The translation plane is actually curved due to the camera's perspective which is not taken into consideration by the tracking algorithm.

You are quite right. I didnt take that in to consideration.

Have you tried it yourself?

Yes I did. It's better to switch of z-axis transf. for games that zoom and leave it on for games that move you back and forth in the cockpit. The problem in il2 only is that it does both. It first moves you to the front of the cockpit and then starts zooming in and vise versa. So you will get a good behaviour while doing only one thing depending on wether you have z-axis transf. turned on or not. Look at the third code I posted, you will notice that I left "FakeTrackIR.z = RealTrackIR.z".

But many people think it feels unnatural.

Well, that's why it should be left as an option. It's just that in the heat of battle my head kind of wants to move oposite of what it should when looking back and having no transformations. I gues I could get used to it, it's just that I don't want to.  

You would first use a transformation matrix with the angle A to convert fixed axes into real head axes and then multiply the result with a transformation matrix using an angle of A-B.

Sorry. This is actualy wrong. You should first multiply with an inverse transformation matrix using angle A, and then multiply the results with a normal transformation matrix using angle B.

Not that anyone is going to try this.  

Hi... It's me again. I gues I just can't sleep unless I've solved all of my problems.  

Anyway. If you want to fly il2 in 6dof AND you want to do it with coordinate transformations AND if you want to dissable the zooming action implemented in the 6dof MOD, then type this into GlovePIE:
PIE.FrameRate = 120 Hz

FakeTrackIR.x = RealTrackIR.x * cos(RealTrackIR.yaw) * cos(RealTrackIR.roll) + RealTrackIR.y * (-1 * cos(RealTrackIR.pitch) * sin(RealTrackIR.roll) + sin(RealTrackIR.pitch) * sin(RealTrackIR.yaw) * cos(RealTrackIR.roll)) + RealTrackIR.z * (sin(RealTrackIR.pitch) * sin(RealTrackIR.roll) + cos(RealTrackIR.pitch) * sin(RealTrackIR.yaw) * cos(RealTrackIR.roll))

FakeTrackIR.y = RealTrackIR.x * cos(RealTrackIR.yaw) * sin(RealTrackIR.roll) + RealTrackIR.y * (cos(RealTrackIR.pitch) * cos(RealTrackIR.roll) + sin(RealTrackIR.pitch) * sin(RealTrackIR.yaw) * sin(RealTrackIR.roll)) + RealTrackIR.z * (-1 * sin(RealTrackIR.pitch) * cos(RealTrackIR.roll) + cos(RealTrackIR.pitch) * sin(RealTrackIR.yaw) * sin(RealTrackIR.roll))

var.z = RealTrackIR.x * (-1 * sin(RealTrackIR.yaw)) + RealTrackIR.y * sin(RealTrackIR.pitch) * cos(RealTrackIR.yaw) + RealTrackIR.z * cos(RealTrackIR.pitch) * cos(RealTrackIR.yaw)

If ((var.z > -0.2) And (var.z < 0.2))
  FakeTrackIR.z = var.z
elseif var.z >= 0.2
      FakeTrackIR.z = 0.2
Else
   FakeTrackIR.z = -0.2
Endif

FakeTrackIR.pitch = RealTrackIR.pitch

FakeTrackIR.yaw = RealTrackIR.yaw

FakeTrackIR.roll = RealTrackIR.roll
What this does is limit the forward-backward movement in the cockpit so that you don't trigger the zooming.
I tested this with the Fw190D9, so you might have to play with the 0.2, -0.2 numbers to suit your ride.

Ok. Maybe I'll sleep better now...