Blend the effect while panning around

[nico87]

When using the hat or the keyboard to pan around the cockpit, the headshake "freezes" until the camera stops moving. After 1 second, it resumes (sort of a harsh resuming, no blending between states).
It would be nice to blend the pause/resume of the effects.

This doesn't happen when panning with mouse right click, even while you are holding the button it continues working normally.

[rdrehmer]

This issue seems to become way more evident with the new head roll feature.
There is a big snap after the pan animation ends.

Simple way to reproduce: try panning around with joystick hat switch (or camera presets on keypad) while making a turn.

It seems that the camera transition from A to B kind of bypasses plugins while in motion. I pointed this out to Ben a couple of years ago, but he wasn't aware and just said that the devs should talk directly to him about this...

I know nothing about coding, so this is the farthest I can go with troubleshoothing :(

Any thoughts? I think I'm going to e-mail Ben or someone else from Laminar to get a hint about how you awesome guys could overcome this.

[rdrehmer]

Here's a recording of the behavior described above
https://www.dropbox.com/s/mydmc4mxdr7h5gu/Headshake_camera_plugin_1.mp4?dl=0

[nico87]

@abdullah-radwan Maybe it's just the head roll that does not blend in?

[rdrehmer]

No, the entire plugin stands-by. You can see this with every effect: g-force, ground roll, engine vibrations...

Easy way to test:
Aircraft on the ground, low RPM (let it vibrate). Watch the vibration stopping during camera transitions, it resumes back a second after.

The problem is that vibrations are subtle so you hardly notice. Head roll, on the other hand, is a big change on the horizon angle. There's no way it could go unnoticed during resume.

Edit:
Again, I'm probably talking BS here, because I'm not a developer, but it seems to me that the difference between using mouse and keyboard/hat switch is that using mouse it updates the camera data every frame. But the camera transitions seems to take control over the plugin, completely bypassing it for a brief moment.

[nico87]

I must take a look and do some tests. I have an idea to blend this in, but I must try.

[abdullah-radwan]

I've noticed that as well. I have no idea how to fix it. It would be great if you fixed it.

[nico87]

What if you use this version? https://www.dropbox.com/s/lfp6orjl90ya853/HeadShake_v1.12.1b1.zip?dl=0
It should blend in the level head effect.

[rdrehmer]

Yeap, it really helps smoothing out the suddenness of plugin resuming back to action.

But I still hope there is a way to make it actually never stop, so the shake/vibration/roll/g-force effects keep on going during the transition seamlessly.

I've contacted Laminar about this already, maybe one of the devs could give a hint. But no answers so far. If anyone of you have a closer contact, like a direct e-mail to Ben, maybe it's a way to go.
edit: nevermind, I found Ben's e-mail. Trying to contact him directly.

Oh man, I wish I could code to be more useful than just pointing fingers at issues :(

[nico87]

Yeap, it really helps to smooth out the suddenness of plugin resuming back to action.

Good!

But I still hope there is a way to make it actually never stop, so the shake/vibration/roll/g-force effects keep on going during the transition seamlessly.

I don't think this will be possible because of the way the datarefs work.

[rdrehmer]

I don't think this will be possible because of the way the datarefs work.

Could you provide me some details (for Dummies) about this? Datarefs stops updating while the camera is in motion?

[nico87]

Camera motion and HS overwrite the datarefs at the same time. So, if you want the camera commands to work, you need HS to stop writing the datarefs temporarily, and then take control again of it.

[rdrehmer]

Oh, I see. But why it doesn't stop writing if you hold RMB? It overwrites for each frame?

[nico87]

What's RMB?

[abdullah-radwan]

Right mouse button.

[nico87]

Oh I see. Well, I don't know. The point is that HS needs to stop if you want the other commands to work.

[rdrehmer]

Ok, so I started copying a Headshake function (engine vibration) in a FlyWithLua script, because it's easier for me to learn and now I have something to work with and test by myself.

I've got to the point where l hit the same wall, now I understand the limitations you've described.

The good news is that XPRealisticPRO (is in LUA too) somehow managed to overcome this very same issue in one of it's updates in the past, so there must be a way to solve it, I just need to figure it out...
I hope.

[nico87]

The best thing would be to apply the changes AFTER X-plane. A draw loop would be perfect...but are we allowed to write datarefs in a draw loop?

[rdrehmer]

Humm I guess we are not...

My hope is that there was some kind of hierarchy. Like in animation, if I want to make subtle variations in an object but keep its main animation, I just set a parent-child relationship. Parent would get the "master" animation (X-Plane) and the child receives the small ones (Headshake)

There is a lot of datarefs that relates to camera head/pitch, pilot head head/pitch, view head/pitch... but they seem to affect nothing. I can't even understand what each one of them stands for and what are the relation between them.

[rdrehmer]

Well, I think I found the "parent-child" relation that answers my question about why does it work well with mouse.

Mouse controls the following non writable DataRefs (the "master pivot")
sim/graphis/view/cockpit_pitch
sim/graphis/view/cockpit_roll

Joystick and Keyboard controls the writable ones:
sim/graphics/view/pilots_head_x
sim/graphics/view/pilots_head_y
sim/graphics/view/pilots_head_z
sim/graphics/view/pilots_head_phi
sim/graphics/view/pilots_head_psi
sim/graphics/view/pilots_head_the

At the given point, it seems that we would need inside help of another "layer" of transformation that doesn't fight those controled by XP.

[nico87]

What I don't get is that HS reads a value, updates it and then writes into the same dataref, all this inside a flight loop. If this overwrites the hat-switch values to the point that the changes of the hat-switch are totally ignored by the sim, it means that the two things are managed in different loops.

[rdrehmer]

Well, I think there is a workaround. It seems that you can write on the following datarefs whitout interfering on X-Plane's own commands:

sim/graphics/view/field_of_view_horizontal_deg
sim/graphics/view/field_of_view_vertical_deg
sim/graphics/view/field_of_view_roll (I don't think this one is necessary, because nothing seems to write on 'pilots_head_phi' anyway, so we could stick to it for the roll.)

What do you guys think?

[abdullah-radwan]

I don't think this is a good idea. The current datarefs are tilting the pilot head, while the datarefs you've provided is tilting the entire screen, this will break multimonitor compatibility, and doesn't support sound changes due to tilting.

Currently, only sim/graphics/view/field_of_view_roll is being used on X-Plane versions older than 11.02, as pilots_head_phi wasn't introduced until 11.02.

[rdrehmer]

Oh, I get it...
Well, the only response I've got from Ben is that the devs should talk directly to him to ask for what's needed.

I think it is not a huge deal to ask for another "layer" of datarefs that are independent of that ones used by x-plane. Worth a try, at least.

[rdrehmer]

Just so you guys know, LR accepted the feature request of a set of datarefs that doesn't conflict with X-Plane default view system. It will be listed as XPD-10230 when it comes (long wait, probably).

[nico87]

Great!