I am currently creating a shared cockpit application for the NGX in SimConnect. Unfortunately, I cannot use the default shared cockpit for P3D since not everyone can get a good connection through it. I can set and get position from SimConnect, but internet connection isn't the best and a 50Hz polling time results in a very stuttery and glitchy client side movement. Do you guys have any method to smooth out Position and Rotation? I know Aerosoft has obviously managed to do this, but I can't figure it out.
-
Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:
- Tag FS2020 specific questions with the MSFS2020 tag.
- Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
- Questions about aircraft design can be posted in the Aircraft design forum
- Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
- Questions about terrain design can be posted in the FS2020 terrain design forum.
- Questions about SimConnect can be posted in the SimConnect forum.
Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.
By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.
Shared Cockpit with SimConnect
- Thread starter 997R8V10
- Start date
Are you interpolating between updates? 50Hz sounds like you're just sending new positions, but you should be sending position, velocities and accelerations (including angular), plus a timestamp from the sender in each packet, and using those to interpolate the likely position and orientation at each frame (also, 50Hz is way overkill, I only needed about 4Hz in a remote viewing application I did, but you can adjust it upward until it looks good enough).
As for internet problems, you probably want to be using UDP instead of TCP/IP to send your position/velocity updates because packets can get dropped or received out of order and TCP/IP will waste time resending and holding on to packets before giving them to you. With UDP, if the sender's timestamp is prior to the last packet (packet received out of order) you can simply drop it and keep extrapolating until the next one comes in, or if a packet is dropped you don't really care because again you just keep extrapolating. Then variable lag you can handle by comparing sender's timestamps to yours when you receive it and adjusting/extrapolating accordingly. You'll also need to smoothly adjust for errors between predicted path since last update, and actual position when a new packet comes in.
That's all if you're intent on controlling position and orientation directly. I found I had to use "sim disabled" to do that smoothly because (I'm guessing) there is some other kind of interpolation going on between the sim's physics calculations (which maybe updating only each "sim frame" or even less) and the actual rendering which draws at a different rate and I think just interpolates object positions based on the last physics calculation. If you set "sim disabled" I don't think the instruments like airspeed work properly, so you might want to leave it enabled and try setting the body velocities and accelerations (but not the position) and let the sim do the position updates.
As for internet problems, you probably want to be using UDP instead of TCP/IP to send your position/velocity updates because packets can get dropped or received out of order and TCP/IP will waste time resending and holding on to packets before giving them to you. With UDP, if the sender's timestamp is prior to the last packet (packet received out of order) you can simply drop it and keep extrapolating until the next one comes in, or if a packet is dropped you don't really care because again you just keep extrapolating. Then variable lag you can handle by comparing sender's timestamps to yours when you receive it and adjusting/extrapolating accordingly. You'll also need to smoothly adjust for errors between predicted path since last update, and actual position when a new packet comes in.
That's all if you're intent on controlling position and orientation directly. I found I had to use "sim disabled" to do that smoothly because (I'm guessing) there is some other kind of interpolation going on between the sim's physics calculations (which maybe updating only each "sim frame" or even less) and the actual rendering which draws at a different rate and I think just interpolates object positions based on the last physics calculation. If you set "sim disabled" I don't think the instruments like airspeed work properly, so you might want to leave it enabled and try setting the body velocities and accelerations (but not the position) and let the sim do the position updates.
I am sending velocities and accels with rotation data, but I did not think of sending a timestamp. That should probably help, and yeah I'm thinking of reducing it to like 25 or so. I will also try the sim disabled as I had not tried that before! Thanks, I will reply with results!
Another possibility is make sure you're smoothing and handling positions all in 64 bit floats. 32 bits aren't precise enough and it'll jump around.
Hopefully it's that and you don't have to use sim disabled, because with that you lose animations on the aircraft and other artifacts (like smoking tires just from taxiing around sometimes).
Hopefully it's that and you don't have to use sim disabled, because with that you lose animations on the aircraft and other artifacts (like smoking tires just from taxiing around sometimes).
So you've double-checked you're requesting position as a 64 bit value and handling it everywhere as 64 bit? The definition of the data structure you want from FSX should also be FLOAT64's and look something like (C++):
hr = SimConnect_AddToDataDefinition(hSimConnect, POS_MSL_STRUCT_ID, "plane latitude", "degrees", SIMCONNECT_DATATYPE_FLOAT64);
If that's right, how are you interpolating exactly? I get perfectly smooth movement first converting lat/lon/altitude to orthogonal XYZ (the math is easier that way -- I use a simple spherical earth model and it works fine, and of course use the same units for position, velocity and acceleration e.g. meters and seconds), then you can use classical equations of motion and simple integration to calculate velocity and position.
So for example when you want to get the position "now," you have time T (time now) and time TL (time of last update) and first calculate delta time dT = T - TL
Then calculate the velocity "now" as V = VL + 0.5 * AL * dT^2 (where VL is the velocity at last update, AL the acceleration at last update).
Then calculate position "now" as P = PL + V * dT + E * Max(0.0, 1.0 - dT) (where PL is position at last update and E the error amount, see below).
The bold above are all vectors. Then you'd convert the X/Y/Z position vector back to Lat/Lon/Altitude.
When you get a position update, to prevent warping you can calculate the error amount E as the difference between the interpolated position as of the new update time, and the actual updated position at that time. In Max(0.0, 1.0 - dT) above, this will reduce the error to 0 over 1.0 seconds which I've found isn't noticeable as long as you're doing 1Hz+ updates and aren't doing tight turns on the ground. It lags behind turns and will be affected by higher update rates, so you can play with that 1.0 value until it looks right (smaller for higher Hz or to keep up better in tight turns). So:
1. Receive updated position PU
2. First get extrapolated position for "now" (PE) through the above
3. Calculate E = PE - PU
4. Now set the new "E/PL/VL/AL/TL" values
I didn't include the lag correction / clock "sync" I described above though, which may not be needed unless you're getting large variations in ping times with the other side.
Then you do the same for orientation using angular velocities and accelerations but it's the same concept as above (although it gets tricky going through +/- 90 degrees pitch).
Also be careful of update rates that are too high, because at slow speeds (like while parking) you can get underflow (no change to lat/lon when the change in position at an update is really small due to both small velocity and small delta time), meaning the object won't move.
Is this at all similar to what you're doing, or do you want me to elaborate? I don't really know any simpler interpolation that still keeps movement smooth. (You may also need to cheat with heavy braking on landing or taxi because the above assumes constant acceleration when really there are changes in acceleration rate which may cause jerky sliding on the client side. Maybe use a bigger error correction time if the brakes or reverse thrust is on).
hr = SimConnect_AddToDataDefinition(hSimConnect, POS_MSL_STRUCT_ID, "plane latitude", "degrees", SIMCONNECT_DATATYPE_FLOAT64);
If that's right, how are you interpolating exactly? I get perfectly smooth movement first converting lat/lon/altitude to orthogonal XYZ (the math is easier that way -- I use a simple spherical earth model and it works fine, and of course use the same units for position, velocity and acceleration e.g. meters and seconds), then you can use classical equations of motion and simple integration to calculate velocity and position.
So for example when you want to get the position "now," you have time T (time now) and time TL (time of last update) and first calculate delta time dT = T - TL
Then calculate the velocity "now" as V = VL + 0.5 * AL * dT^2 (where VL is the velocity at last update, AL the acceleration at last update).
Then calculate position "now" as P = PL + V * dT + E * Max(0.0, 1.0 - dT) (where PL is position at last update and E the error amount, see below).
The bold above are all vectors. Then you'd convert the X/Y/Z position vector back to Lat/Lon/Altitude.
When you get a position update, to prevent warping you can calculate the error amount E as the difference between the interpolated position as of the new update time, and the actual updated position at that time. In Max(0.0, 1.0 - dT) above, this will reduce the error to 0 over 1.0 seconds which I've found isn't noticeable as long as you're doing 1Hz+ updates and aren't doing tight turns on the ground. It lags behind turns and will be affected by higher update rates, so you can play with that 1.0 value until it looks right (smaller for higher Hz or to keep up better in tight turns). So:
1. Receive updated position PU
2. First get extrapolated position for "now" (PE) through the above
3. Calculate E = PE - PU
4. Now set the new "E/PL/VL/AL/TL" values
I didn't include the lag correction / clock "sync" I described above though, which may not be needed unless you're getting large variations in ping times with the other side.
Then you do the same for orientation using angular velocities and accelerations but it's the same concept as above (although it gets tricky going through +/- 90 degrees pitch).
Also be careful of update rates that are too high, because at slow speeds (like while parking) you can get underflow (no change to lat/lon when the change in position at an update is really small due to both small velocity and small delta time), meaning the object won't move.
Is this at all similar to what you're doing, or do you want me to elaborate? I don't really know any simpler interpolation that still keeps movement smooth. (You may also need to cheat with heavy braking on landing or taxi because the above assumes constant acceleration when really there are changes in acceleration rate which may cause jerky sliding on the client side. Maybe use a bigger error correction time if the brakes or reverse thrust is on).
It's been a very long time, but I finally got a lot more information and am taking another crack at this. So far, I've got it decently smooth, by introducing an artificial 500ms delay (The client shouldn't notice a thing). This accounts for any network quirks with sending data. Unfortunately, I have to use sim disabled, which may be causing the stuttering issues. basically, I simply set position every 20ms on the client sim based on the calculated velocity. I'm going to try the interpolation above w/o freezing and see how that works. RN freezing works, but it kinda stutters sometimes.