Pull requests #21 and #23 issues

[nico87]

After accepting #21 and #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 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/&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 <#21> and #23 <#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 <7cd0b09> 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 <#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 <#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 <#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 <#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 <#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 ***@***.***> 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 <#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.