Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Pull requests #21 and #23 issues #24

Open
nico87 opened this issue Sep 1, 2019 · 17 comments
Open

Pull requests #21 and #23 issues #24

nico87 opened this issue Sep 1, 2019 · 17 comments

Comments

@nico87
Copy link
Contributor

nico87 commented Sep 1, 2019 •
edited

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.
@nico87 nico87 assigned nico87 and unassigned nico87 Sep 1, 2019
@markcellis
Copy link

markcellis commented Sep 1, 2019 via email

@quantumac
Copy link
Contributor

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
Copy link

markcellis commented Sep 2, 2019 via email

@quantumac
Copy link
Contributor

quantumac commented Sep 2, 2019 •
edited

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
Copy link

markcellis commented Sep 2, 2019 via email

@markcellis
Copy link

markcellis commented Sep 2, 2019 via email

@quantumac
Copy link
Contributor

@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
Copy link

markcellis commented Sep 3, 2019 via email

@quantumac
Copy link
Contributor

@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
Copy link

markcellis commented Sep 3, 2019 via email

@quantumac
Copy link
Contributor

@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
Copy link

markcellis commented Sep 3, 2019 via email

@quantumac
Copy link
Contributor

quantumac commented Sep 3, 2019 •
edited

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
Copy link

markcellis commented Sep 4, 2019 via email

@quantumac
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

nico87 commented Sep 5, 2019

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@nico87 @markcellis @quantumac