Hi I just found this thread for the first time... damn I should have patented the technique! Actually my ridgelift stuff was designed to be of value to sim pilots everywhere and I'm just as happy for it to be in FG as FSX. Woot should be congratulated in making progress with the FG implementation because it's very easy to get arctangents and signs and slopes mixed up so the formula has a bug in it.
I understand the
viewtopic.php?f=6&t=4706#p33902 thread is "improving glider realism" of which ridgelift (this thread) is one part so I'll keep any posts relevant.
Here's a few comments on the implementation of the ridgelift technique in FSX:
1) The *main* feature of the technique is it only samples the terrain around the user aircraft and this makes it very efficient. That sounds obvious but other attempts have assumed you need to map the entire region the plane is flying in to calculate the ridgelift at every point. In fact the terrain samples are further optimised by sampling directly upwind and downwind. You can get decent results with *two* terrain samples, i.e. a single slope immediately beneath the aircraft, but for my implementation I chose five sample points and derive four slopes, each with some physical rationale:
2) Slope0 and Slope1 are both immediately upwind, and tell you the steepness of the ridge the glider is sitting above and whether it's convex (not so good) or concave (better).
3) Slope2 looks further upwind to see if there's high ground upwind that should *reduce* the local ridgelift.
4) Slope4 looks a short distance *downwind* to see if the ridge continues upwards behind you which would strengthen the local ridgelift. All told, with the wind from left to right (and exaggerating elevation) you end up with a lift/sink profile like this:
5) FSX has no API to directly sample the ground elevation at a given lat/long. My workaround was to use the AI subsystem to fly four aircraft in formation with the user aircraft (at 10,000 meters) and query each AI object for the ground elevation beneath it. If you slew up to 10,000 meters in FSX you will find those AI aircraft up there although I used a graphic model of a purple pallet under a parachute because it was the lowest poly 'aircraft' in the standard FSX install...
6) in FSX I used a cycle of updating the position of the AI 'probes' (hence sim_probe) once per second, with *negligible* impact on CPU or graphics. I *should* have done the professional thing that was mentioned here with FG to see how many samples I *could* have done before FSX started to choke but the AI subsystem in FSX is non-trivial and that would have been quite a lot of coding.
7) there is quite a lot of opportunity in tweaking the various factors that combine the effect of the various slopes, and the effect of altitude but after a lot of testing in FSX the version I produced was pretty reasonable and the need to have a consistent stable version for general use was paramount.
8) The analysis that earlier recognises ridgelift is globally multiplayer consistent (given same terrain and wind) is 100% accurate and important. This requirement has also led me to be reluctant to change the ridgelift calculation now that many pilots are using it and comparing flights - this also meant it was fairly important to get the calculation pretty reasonable before shipping the 'prod' version.
9) (I have 500 hours of real ridge flying experience around the Mifflin ridges in the USA) For high-speed ridge flying, I am confident you *don't* need differential lift effects on different parts of the aircraft, assuming there is some turbulence. In real ridge flying, at 110 knots you are concentrating on not pulling the wings off during surges and trying to avoid your head going through the canopy - it is unrealistic to expect to simulate anything like this at this stage and this stuff really does swamp any left wing / right wing subtlety to the ridge updraft. Thermals might be a bit more subtle but there's so much other basic thermal stuff that needs implementing, e.g. multiplayer consistency.
10) As Woot mentions, for FG there is at least the possibility of improving the part of the ridgelift calculation that decides how *high* the ridgelift should extend above the terrain. The fact is the situation is asymmetric upwind and downwind of the ridge.
11) It *may* be possible to improve the accuracy of the ridge lift by using more sample points, e.g. *perpendicular* to the wind direction. I'm aware this might hint to the formula that you are approaching a 'gap' in a ridge and diminish the lift as you approach to account for the 'spill-around'. *But* all this theory is great but I've experimented with it and it's very hard to make a difference that the pilot can detect. It would still be super-efficient though.
Overall, the way the ridgelift calculation works is like having a comb running over the terrain aligned with the wind, and the lift factor updates with every little bump and lump in the landscape you fly over. This gives it the nice feature of being continuously variable and never exactly repeated, and you can sense the organic detail as you fly in the sim. If you fly the same terrain but with a different wind direction, the lift will be newly calculated but the calculation remains highly efficient which is ideal for the sim.
B21