Pull requests #21 and #23 issues

[nico87]

After accepting https://github.com/simcodersdotcom/headshake/pull/21 and https://github.com/simcodersdotcom/headshake/pull/23 and releasing HeadShake, users reported that it didn't work with X-Camera anymore.

The reasons are:

1. Once HeadShake is overridden via the simcoders/headshake/override dataref, the head position datarefs are not updated anymore. I've fixed this with commit 7cd0b09acfd81a34148150298df310655a950ad3.
2. The camera movements are now stuttering. I think this is caused by the "quantize" function. See this post: https://forums.x-plane.org/index.php?/files/file/20955-headshake-camera-plugin-lin-win-mac/&do=findComment&comment=279509

@quantumac I've reverted the changes on master and released v1.12.9 to make the stable release of HeadShake work again without issues with X-Camera. Could you check these problems and make a new pull request? @markcellis is available for info about how the integration between X-Camera and HeadShake works.

[markcellis]

Thanks Claudio. If you need assistance in understanding the integration between HeadShake and X-Camera please don’t hesitate to contact me.

Mark

Stick and Rudder Studios, LLC.

Delighting The FlightSim Community

www.StickandRudderStudios.com

From: Claudio Nicolotti [mailto:notifications@github.com] Sent: Sunday, September 1, 2019 5:26 AM To: simcodersdotcom/headshake Cc: Mark Ellis; Mention Subject: [simcodersdotcom/headshake] Pull requests #21 and #23 issues (#24)

After accepting #21 https://github.com/simcodersdotcom/headshake/pull/21 and #23 https://github.com/simcodersdotcom/headshake/pull/23 and releasing HeadShake, users reported that it didn't work with X-Camera anymore.

The reasons are:

1. Once HeadShake is overridden via the simcoders/headshake/override dataref, the head position datarefs are not updated anymore. I've fixed this with commit https://github.com/simcodersdotcom/headshake/commit/7cd0b09acfd81a34148150298df310655a950ad3 7cd0b09.
2. The camera movements are now stuttering. I think this is caused by the "quantize" function. See this post: https://forums.x-plane.org/index.php?/files/file/20955-headshake-camera-plugin-lin-win-mac/ https://forums.x-plane.org/index.php?/files/file/20955-headshake-camera-plugin-lin-win-mac/&do=findComment&comment=279509 &do=findComment&comment=279509

@quantumac https://github.com/quantumac I've reverted the changes on master and released v1.12.9 to make the stable release of HeadShake work again without issues with X-Camera. Could you check these problems and make a new pull request? @markcellis https://github.com/markcellis is available for info about how the integration between X-Camera and HeadShake works.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/simcodersdotcom/headshake/issues/24?email_source=notifications&email_token=AGF4YKVYH3GOOKUPPWZP3D3QHODAVA5CNFSM4ISWEZAKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HIUFKFA , or mute the thread https://github.com/notifications/unsubscribe-auth/AGF4YKW7BR62IYPL5KDZXSDQHODAVANCNFSM4ISWEZAA . https://github.com/notifications/beacon/AGF4YKTRURJDEFPGAZVXTWDQHODAVA5CNFSM4ISWEZAKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HIUFKFA.gif

[quantumac]

As requested, I've created a minimal changeset which addresses just the head roll issues. See it here:

https://github.com/quantumac/headshake/tree/minimal_head_roll_fix

I've also created a pull request.

@markcellis : please take a look at this change and see if it works for you.

[markcellis]

Unfortunately I’m not familiar enough with the HeadShake code to know if this corrects the problem.

Mark

From: quantumac [mailto:notifications@github.com] Sent: Sunday, September 1, 2019 6:51 PM To: simcodersdotcom/headshake Cc: Mark Ellis; Mention Subject: Re: [simcodersdotcom/headshake] Pull requests #21 and #23 issues (#24)

As requested, I've created a minimal changeset which addresses just the head roll issues. See it here:

https://github.com/quantumac/headshake/tree/minimal_head_roll_fix

I've also created a pull request.

@markcellis https://github.com/markcellis : please take a look at this change and see if it works for you.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/simcodersdotcom/headshake/issues/24?email_source=notifications&email_token=AGF4YKSOSXLIFD7MRY3ZBFDQHRBLRA5CNFSM4ISWEZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5UMLMY#issuecomment-526960051 , or mute the thread https://github.com/notifications/unsubscribe-auth/AGF4YKV4X55NJAYPLO7WNOTQHRBLRANCNFSM4ISWEZAA . https://github.com/notifications/beacon/AGF4YKTST73NVV4UQY7M3SDQHRBLRA5CNFSM4ISWEZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5UMLMY.gif

[quantumac]

So I gather those most familiar with the reported issue are not represented here. Unfortunately I'm not familiar with X-Camera.

However I can speculate about it.

If X-Camera modifies pilot head roll, there is currently no way for my fix to know about it. My patch will assume any deviation from the pilot head roll which headshake calculates is caused by X-Plane's pilot head roll drift issue and will compensate. This compensation would interfere with any head roll which any other plugin is trying to induce.

Perhaps one way around this would be for headshake to check if X-Camera is enabled (via dataref or what not) and then turn off its compensation for X-Plane's pilot head roll drift issue automatically.

Another way around this might be for X-Camera to publish its expected pilot head roll via an agreed-upon custom dataref, one which headshake could read and account for.

Of course the real issue is the pilot head roll drift which X-Plane introduces. After a while the issue produces a permanent tilt in the pilot's head. It's most annoying and it has been a long-standing issue. The best solution would be for Laminar Research to delve into their code and figure out why the inaccuracy creeps into the roll. I suspect it has something to do with an inaccurate translation between Euler angles and Quaternions, but that's just speculation.

I've found it difficult to relate subtle issues to Laminar Research in the past. I'm not sure if the fault is on my part or theirs. I try to be very precise in my language, but it's not always interpreted as intended. Perhaps if @nico87 sent Laminar Research a bug report regarding the creeping head roll drift issue they might respond favorably.

Or maybe we should punt and leave it up to the user? Perhaps we could add a checkbox to the preferences dialog to control whether or not the pilot roll drift compensation is enabled. The user can then elect to turn off the pilot head roll drift compensation if it doesn't bother them or if they are using something like X-Camera which may need to add its own roll.

All I know for sure is the creeping pilot head roll drift issue was annoying enough to me to try and provide a solution. It may not be the best solution.

[markcellis]

X-Camera definitely controls the pilot head datarefs when it is enabled. The pilot head roll dataref will be most prominently changed when a user has TrackIR enabled and they tip their head.

You can tell that X-Camera is enabled when the HeadShake dataref simcoders/headshake/override has a one in it. That indicates that X-Camera is enabled and is controlling the cameras. Any headshake effects will be applied to the X-Camera camera by adding the values in the HeadShake offset datarefs:

            gOffset_x = XPLMFindDataRef("simcoders/headshake/offset_x");

            gOffset_y = XPLMFindDataRef("simcoders/headshake/offset_y");

            gOffset_z = XPLMFindDataRef("simcoders/headshake/offset_z");

            gOffset_yaw = XPLMFindDataRef("simcoders/headshake/offset_yaw");

            gOffset_pitch = XPLMFindDataRef("simcoders/headshake/offset_pitch");

            gOffset_roll = XPLMFindDataRef("simcoders/headshake/offset_roll");

I think you might want to disable this roll correction when X-Camera is enabled, simcoders/headshake/override dataref set to 1.

Thoughts?

Mark

From: quantumac [mailto:notifications@github.com] Sent: Monday, September 2, 2019 12:01 PM To: simcodersdotcom/headshake Cc: Mark Ellis; Mention Subject: Re: [simcodersdotcom/headshake] Pull requests #21 and #23 issues (#24)

So I gather those most familiar with the reported issue is not represented here. Unfortunately I'm not familiar with X-Camera.

However I can speculate about it.

If X-Camera modifies pilot head roll, there is currently no way for my fix to know about it. My patch will assume any deviation from the pilot head roll which headshake calculates is caused by X-Plane's pilot head roll drift issue and will compensate. This compensation would interfere with any head roll which any other plugin is trying to induce.

Perhaps one way around this would be for headshake to check if X-Camera is enabled (via dataref or what not) and then turn off its compensation for X-Plane's pilot head roll drift issue automatically.

Another way around this might be for X-Camera to publish its expected pilot head roll via an agreed-upon custom dataref, one which headshake could read and account for.

Of course the real issue is the pilot head roll drift which X-Plane introduces. After a while the issue produces a permanent tilt in the pilot's head. It's most annoying and it has been a long-standing issue. The best solution would be for Laminar Research to delve into their code and figure out why the inaccuracy creeps into the roll. I suspect it has something to do with an inaccurate translation between Euler angles and Quaternions, but that's just speculation.

I've found it difficult to relate subtle issues to Laminar Research in the past. I'm not sure if the fault is on my part or theirs. I try to be very precise in my language, but it's not always interpreted as intended. Perhaps if @nico87 https://github.com/nico87 sent Laminar Research a bug report regarding the creeping head roll drift issue they might respond favorably.

Or maybe we should punt and leave it up to the user? Perhaps we could add a checkbox to the preferences dialog to control whether or not the pilot roll drift compensation is enabled. The user can then elect to turn off the pilot head roll drift compensation if it doesn't bother them or if they are using something like X-Camera which may need to add its own roll.

All I know for sure is the creeping pilot head roll drift issue was annoying enough to me to try and provide a solution. It may not be the best solution.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/simcodersdotcom/headshake/issues/24?email_source=notifications&email_token=AGF4YKXYLXSRNJJQL43Y453QHU2DTA5CNFSM4ISWEZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5WFMFQ#issuecomment-527193622 , or mute the thread https://github.com/notifications/unsubscribe-auth/AGF4YKVACU3CJUWGBUMLZF3QHU2DTANCNFSM4ISWEZAA . https://github.com/notifications/beacon/AGF4YKSUDCPCIOBFRM77JJDQHU2DTA5CNFSM4ISWEZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5WFMFQ.gif

[markcellis]

Claudio,

Just as an FYI it does not look like you completely backed out the change in 1.12.9. See this post:

https://forums.x-plane.org/index.php?/files/file/20955-headshake-camera-plugin-lin-win-mac/ https://forums.x-plane.org/index.php?/files/file/20955-headshake-camera-plugin-lin-win-mac/&do=findComment&comment=279661&tab=comments &do=findComment&comment=279661&tab=comments

Mark

From: Mark Ellis [mailto:Mark@StickandRudderStudios.com] Sent: Monday, September 2, 2019 5:54 PM To: 'simcodersdotcom/headshake'; 'simcodersdotcom/headshake' Cc: 'Mention' Subject: RE: [simcodersdotcom/headshake] Pull requests #21 and #23 issues (#24)

X-Camera definitely controls the pilot head datarefs when it is enabled. The pilot head roll dataref will be most prominently changed when a user has TrackIR enabled and they tip their head.

You can tell that X-Camera is enabled when the HeadShake dataref simcoders/headshake/override has a one in it. That indicates that X-Camera is enabled and is controlling the cameras. Any headshake effects will be applied to the X-Camera camera by adding the values in the HeadShake offset datarefs:

            gOffset_x = XPLMFindDataRef("simcoders/headshake/offset_x");

            gOffset_y = XPLMFindDataRef("simcoders/headshake/offset_y");

            gOffset_z = XPLMFindDataRef("simcoders/headshake/offset_z");

            gOffset_yaw = XPLMFindDataRef("simcoders/headshake/offset_yaw");

            gOffset_pitch = XPLMFindDataRef("simcoders/headshake/offset_pitch");

            gOffset_roll = XPLMFindDataRef("simcoders/headshake/offset_roll");

I think you might want to disable this roll correction when X-Camera is enabled, simcoders/headshake/override dataref set to 1.

Thoughts?

Mark

From: quantumac [mailto:notifications@github.com] Sent: Monday, September 2, 2019 12:01 PM To: simcodersdotcom/headshake Cc: Mark Ellis; Mention Subject: Re: [simcodersdotcom/headshake] Pull requests #21 and #23 issues (#24)

So I gather those most familiar with the reported issue is not represented here. Unfortunately I'm not familiar with X-Camera.

However I can speculate about it.

If X-Camera modifies pilot head roll, there is currently no way for my fix to know about it. My patch will assume any deviation from the pilot head roll which headshake calculates is caused by X-Plane's pilot head roll drift issue and will compensate. This compensation would interfere with any head roll which any other plugin is trying to induce.

Perhaps one way around this would be for headshake to check if X-Camera is enabled (via dataref or what not) and then turn off its compensation for X-Plane's pilot head roll drift issue automatically.

Another way around this might be for X-Camera to publish its expected pilot head roll via an agreed-upon custom dataref, one which headshake could read and account for.

Of course the real issue is the pilot head roll drift which X-Plane introduces. After a while the issue produces a permanent tilt in the pilot's head. It's most annoying and it has been a long-standing issue. The best solution would be for Laminar Research to delve into their code and figure out why the inaccuracy creeps into the roll. I suspect it has something to do with an inaccurate translation between Euler angles and Quaternions, but that's just speculation.

I've found it difficult to relate subtle issues to Laminar Research in the past. I'm not sure if the fault is on my part or theirs. I try to be very precise in my language, but it's not always interpreted as intended. Perhaps if @nico87 https://github.com/nico87 sent Laminar Research a bug report regarding the creeping head roll drift issue they might respond favorably.

Or maybe we should punt and leave it up to the user? Perhaps we could add a checkbox to the preferences dialog to control whether or not the pilot roll drift compensation is enabled. The user can then elect to turn off the pilot head roll drift compensation if it doesn't bother them or if they are using something like X-Camera which may need to add its own roll.

All I know for sure is the creeping pilot head roll drift issue was annoying enough to me to try and provide a solution. It may not be the best solution.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/simcodersdotcom/headshake/issues/24?email_source=notifications&email_token=AGF4YKXYLXSRNJJQL43Y453QHU2DTA5CNFSM4ISWEZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5WFMFQ#issuecomment-527193622 , or mute the thread https://github.com/notifications/unsubscribe-auth/AGF4YKVACU3CJUWGBUMLZF3QHU2DTANCNFSM4ISWEZAA . https://github.com/notifications/beacon/AGF4YKSUDCPCIOBFRM77JJDQHU2DTA5CNFSM4ISWEZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5WFMFQ.gif

[quantumac]

@markcellis

There is a check in the "CameraControl::compensate_for_head_roll_drift()" method I added which makes sure mOverride is false before returning the calculated head roll drift. If mOverride is set by an external plugin, zero is returned by the method. So headshake should not perform the compensation as long as the override holds. However, if the override is ever released, the compensation would be calculated and applied.

I think I favor placing this "pilot head roll drift compensation" under a user control checkbox, with some documentation explaining why it is present and what its limitations are. I suppose I could maintain a forked version specifically for users who are annoyed by the issue, who aren't actively using X-Camera or TrackIR and who are sophisticated enough to realize what a work-around is and that it has limitations.

It's not an ideal solution, but like I wrote earlier, I'm not sure I can explain it sufficiently for Laminar Research to understand or even care enough to fix the drift. If there weren't a drift being introduced by X-Plane, @nico87 's original code would be sufficient. There would be no need to introduce a compensation factor.

[markcellis]

This sounds like a good way to handle it.

In all honesty I have never encountered this head roll drift that you mention and I don’t recall seeing other people talk about it. To be fair, I’m always running with X-Camera and it has complete control of the camera so I may never have experienced this problem.

I have a close relationship with Laminar so I might be able to help enlighten them on the issue. Can you provide me some detail as to how you produce the problem in X-Plane? Does it happen with all aircraft. Are there any threads on X-Plane.org that contain discussions of the problem.

Mark

From: quantumac [mailto:notifications@github.com] Sent: Monday, September 2, 2019 9:26 PM To: simcodersdotcom/headshake Cc: Mark Ellis; Mention Subject: Re: [simcodersdotcom/headshake] Pull requests #21 and #23 issues (#24)

@markcellis https://github.com/markcellis

There is a check in the "CameraControl::compensate_for_head_roll_drift()" method I added which makes sure mOverride is false before returning the calculated head roll drift. If mOverride is set by an external plugin, zero is returned by the method. So headshake should not perform the compensation as long as the override holds. However, if the override is ever released, the compensation would be calculated and applied.

I think I favor placing this "pilot head roll drift compensation" under a user control checkbox, with some documentation explaining why it is present and what its limitations are. I suppose I could maintain a forked version specifically for users who are annoyed by the issue, who aren't actively using X-Camera or TrackIR and who are sophisticated enough to realize what a work-around is and that it has limitations.

It's not an ideal solution, but like I wrote earlier, I'm not sure I can explain it sufficiently for Laminar Research to understand or even care enough to fix the drift. If there weren't a drift being introduced by X-Plane, @nico87 https://github.com/nico87 's original code would be sufficient. There would be no need to introduce a compensation factor.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/simcodersdotcom/headshake/issues/24?email_source=notifications&email_token=AGF4YKVJLGF6NRG2K6HRLXTQHW4MLA5CNFSM4ISWEZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5WYAGY#issuecomment-527269915 , or mute the thread https://github.com/notifications/unsubscribe-auth/AGF4YKVMWHTS7CWFBY3P7UTQHW4MLANCNFSM4ISWEZAA . https://github.com/notifications/beacon/AGF4YKTTLQK6G7JF7VQTLPTQHW4MLA5CNFSM4ISWEZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5WYAGY.gif

[quantumac]

@markcellis

To reproduce the issue, turn head leveling on in headshake. You should make several steep left and right banks and do it repeatedly over 15 to 20 minutes (i.e. think aerobatics, not calm "passenger-jet" maneuvers). When I do this without my patch in place, I usually end up with a 5 to 7 degree permanent tilt when I land. Looks like I have a crick in my neck.

If you look at the headshake FAQ, you can see mention of the issue:

https://www.simcoders.com/headshake/faqs/

Question: The viewport rolls after using HeadShake and I cannot realign it Answer: This problem occurs when using a multimonitor setup. To avoid it, just enable the “Multimonitor Compatibility” in HeadShake’s settings.

Unfortunately, if you turn on "Multimonitor Compatibility", the code disables any head roll adjustment (i.e. mMultimonitorCompatibility is false, so head roll is not set for X-Plane). The issue is not related strictly to multiple monitors. I have one monitor and I see the issue.

Why does this happen? The pilot head roll value which the headshake plugin sets for X-Plane is not necessarily the value returned later to headshake by X-Plane. A slight difference can be seen creeping in. Over time this offset can grow as headshake repeatedly reads the roll, subtracts its old offset, adds a new offset and sets the roll in X-Plane again.

[markcellis]

Can you fill me in on what the purpose of the head leveling feature is?

Mark

Sent from my iPhone

On Sep 3, 2019, at 10:55, quantumac notifications@github.com wrote:

@markcellis

To reproduce the issue, turn head leveling on in headshake. You should make several steep left and right banks and do it repeatedly over 15 to 20 minutes (i.e. think aerobatics, not calm "passenger-jet" maneuvers). When I do this without my patch in place, I usually end up with a 5 to 7 degree permanent tilt when I land. Looks like I have a crick in my neck.

If you look at the headshake FAQ, you can see mention of the issue:

https://www.simcoders.com/headshake/faqs/

Question: The viewport rolls after using HeadShake and I cannot realign it Answer: This problem occurs when using a multimonitor setup. To avoid it, just enable the “Multimonitor Compatibility” in HeadShake’s settings.

Unfortunately, if you turn on "Multimonitor Compatibility", the code disables any head roll adjustment (i.e. mMultimonitorCompatibility is false, so head roll is not set for X-Plane). The issue is not related strictly to multiple monitors. I have one monitor and I see the issue.

Why does this happen? The pilot head roll value which the headshake plugin sets for X-Plane is not necessarily the value returned later to headshake by X-Plane. A slight difference can be seen creeping in. Over time this offset can grow as headshake repeatedly reads the roll, subtracts its old offset, adds a new offset and sets the roll in X-Plane again.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[quantumac]

@markcellis

Head leveling is an attempt to emulate how a pilot tends to tilt their head to keep it somewhat level with the horizon when in a bank. The settings provide a limit for this effect as well as a response factor. See the latest headshake preference window for details.

[markcellis]

Ok, that makes sense. I’m not sure why X-Plane does not maintain the roll value you set for the pilot head. One option might be for you to maintain our own private value and just set the camera roll value you want on each frame, or if X-Camera is enabled as a roll offset in the offset datarefs.

One thought on this is I’m not sure of TrackIR users would want this. They may already be tipping their head a bit based on what they are seeing on the screen which gets applied by X-Camera when TrackIR is enabled. They could turn it off in HeadShake but there is also an X-Camera dataref that can be used to know if TrackIR is enabled on a camera.

Mark

From: quantumac [mailto:notifications@github.com] Sent: Tuesday, September 3, 2019 1:04 PM To: simcodersdotcom/headshake Cc: Mark Ellis; Mention Subject: Re: [simcodersdotcom/headshake] Pull requests #21 and #23 issues (#24)

@markcellis https://github.com/markcellis

Head leveling is an attempt to emulate how a pilot tends to tilt their head to keep it somewhat level with the horizon when in a bank. The settings provide a limit for this effect as well as a response factor. See the latest headshake preference window for details.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/simcodersdotcom/headshake/issues/24?email_source=notifications&email_token=AGF4YKQIHWPJ7AOR4U3DMVTQH2KHBA5CNFSM4ISWEZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5Y4EVY#issuecomment-527549015 , or mute the thread https://github.com/notifications/unsubscribe-auth/AGF4YKWVXCSKSOQVEVTY7GTQH2KHBANCNFSM4ISWEZAA . https://github.com/notifications/beacon/AGF4YKQ6A4NAMZ73MIN7CSDQH2KHBA5CNFSM4ISWEZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5Y4EVY.gif

[quantumac]

Ok, that makes sense. I’m not sure why X-Plane does not maintain the roll value you set for the pilot head.

Yeah, I suspect it might involve converting between Euler angles and a Quaternion and back again. In my own experience writing graphics code, converting from Quaternion to Euler angles can involve an arctangent function. This might result in subtle floating point inaccuracies when done repeatedly, where the output of the conversion is fed back as input.

One thought on this is I’m not sure of TrackIR users would want this. They may already be tipping their head a bit based on what they are seeing on the screen which gets applied by X-Camera when TrackIR is enabled. They could turn it off in HeadShake but there is also an X-Camera dataref that can be used to know if TrackIR is enabled on a camera.

Yeah, this issue is subtle and kinda frustrating.

If I had Laminar Research's ear, I might suggest they solve this by allowing plugins to register a new entry on the OpenGL matrix stack. That would be the most flexible option. It would have to appear after X-Plane's pilots head transformation but before the left and right eye transformations in VR. Multiple plugins, like X-Camera, TrackIR and headshake, could maintain their own matrix transformations affecting the view point. The plugin matrix changes wouldn't interfere with each other.

[markcellis]

You know it could be an aircraft issue. Some aircraft may inject their own camera affects. If they are doing something to roll in-between your changes then HeadShake and the aircraft plugin code might be fighting each other. I don’t run into this with X-Camera as I always jam the pilot datarefs to what I want them to be on every frame.

Mark

From: quantumac [mailto:notifications@github.com] Sent: Tuesday, September 3, 2019 7:32 PM To: simcodersdotcom/headshake Cc: Mark Ellis; Mention Subject: Re: [simcodersdotcom/headshake] Pull requests #21 and #23 issues (#24)

Ok, that makes sense. I’m not sure why X-Plane does not maintain the roll value you set for the pilot head.

Yeah, I suspect it might involve converting between Euler angles and a Quaternion and back again. In my own experience writing graphics code, converting from Quaternion to Euler angles involves an arctangent function. This may reinforce subtle floating point inaccuracies when done repeatedly, where the output of the conversion is fed back as input.

One thought on this is I’m not sure of TrackIR users would want this. They may already be tipping their head a bit based on what they are seeing on the screen which gets applied by X-Camera when TrackIR is enabled. They could turn it off in HeadShake but there is also an X-Camera dataref that can be used to know if TrackIR is enabled on a camera.

Yeah, this issue is subtle and kinda frustrating.

If I had Laminar Research's ear, I might suggest they solve this by allowing plugins to register a new entry on the OpenGL matrix stack. That would be the most flexible option. It would have to be after the pilots head transformation but before the left and right eye transformations in VR. Multiple plugins could maintain their own matrix transformations affecting the view point.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/simcodersdotcom/headshake/issues/24?email_source=notifications&email_token=AGF4YKXZK4OPNPUBULBQM7DQH3XY3A5CNFSM4ISWEZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5Z37BQ#issuecomment-527679366 , or mute the thread https://github.com/notifications/unsubscribe-auth/AGF4YKTQM6Y2O242KWDCE6DQH3XY3ANCNFSM4ISWEZAA . https://github.com/notifications/beacon/AGF4YKWNLGIPDKFUYH5IWFDQH3XY3A5CNFSM4ISWEZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5Z37BQ.gif

[quantumac]

You know it could be an aircraft issue. Some aircraft may inject their own camera affects. If they are doing something to roll in-between your changes then HeadShake and the aircraft plugin code might be fighting each other. I don’t run into this with X-Camera as I always jam the pilot datarefs to what I want them to be on every frame.

Except I'm running my own aircraft. I created a freeware BD-5J jet available on x-plane.org. I wrote the plugin for the aircraft. And I'm not using X-Camera or TrackIR. I've tested headshake without my plugin active and headshake exhibits the same roll issue.

[quantumac]

Okay, I just modified by own fork of headshake to have the following warning:

QUANTUMAC FORK COMPATIBILITY WARNING

This fork of HeadShake was created specifically to work around a head roll drift issue caused by X-Plane, especially when the level head effect is enabled. This bug can cause a tilt in the view over time, which makes it appear as if the pilot has a crick in their neck.

THIS PLUGIN IS INCOMPATIBLE WITH X-CAMERA AND TRACKIR. Use the SimCoder's version of HeadShake if you use those plugins.

If users are irritated enough with the issue to want a fix, and they don't use X-Camera or TrackIR, and they are sophisticated enough to download and compile code, then they can have a fix.

Most folks fly big airliners in X-Plane, or sedate GA aircraft, so they probably won't even notice the issue.

[nico87]

Yeah, seems a good solution for the moment. I hope that Laminar adds the datarefs we requested to control the views. Basically, those would be datarefs in between the pilot's head position and the final Laminar internal variables. That would save us a ton of time working around this problem, I believe!