Board index FlightGear Development Weather

Some thoughts on simulating ridge lift

Everything related to weather simulation, visuals should be discussed in the shader subforum.

Re: Some thoughts on simulating ridge lift

Postby Hooray » Wed Apr 15, 2009 3:52 pm

This is pretty cool, now the only thing that's needed is for jsbsim and yasim to provide some way to use different lift for different sections of the airplane, which would improve realism dramatically! :-)

If you want to turn this into a separate subsystem (without using or depending on any AI part), you'll not only have to implement the SGSubsystem interface (i.e. provide your version of all needed methods that are marked "virtual"):
Code: Select all
class FGRidgeLift : public SGSubsystem {
....
};


In the beginning, you'll probably only need init and update.

Then your system can have its own update method, including its own pointers to frequently used properties (which you could make private in the class and initialize them during construction of the object (initializer list).

But you'll also need to register the new "ridgelift" subsystem during initialization so that it is actually used and invoked by FG, just check out $FG_SRC/Main/fg_init.cxx:
Code: Select all
// This is the top level init routine which calls all the other
// initialization routines.  If you are adding a subsystem to flight
// gear, its initialization call should located in this routine.
// Returns non-zero if a problem encountered.
bool fgInitSubsystems() { ....

// register ridgelift system:

globals->add_subsystem("ridgelift", new FGRidgeLift);


Also, subsystems are currently implemented using raw pointers, so ideally you also explicitly free the ridgelift system in the FGGlobals destructor ($FG_SRC/Main/globals.cxx).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Some thoughts on simulating ridge lift

Postby WooT » Wed Apr 15, 2009 7:22 pm

TY very much Hooray, I have it working now, it mixes good with thermals now.

I am still waiting for an answer from the guy who wrote that paper, sent him an email a week ago, but no news.
I don't think it would be a problem, really, but before asking for it to be included in FG, I would like to make sure there is no licencing issues with his algorithm.
WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 5:09 pm

Re: Some thoughts on simulating ridge lift

Postby Hooray » Thu Apr 16, 2009 7:09 pm

WooT wrote:If someone can find a way to make the cloud cap grow / shrink during the life cycle, it would be cool ! The best would be to call simgear to draw a nice 3d cloud, too. I didn't find how to do that, but I'm sure its possible.
Again, I don't find how to make simgear pop a 3d cloud here, but I'm sure someone skilled could do this.


I don't really know much about the latest 3D clouds in CVS, but you can probably get in touch with our forum moderator stuart who's apparently done most of the recent 3D clouds work according to the CVS logs.

Maybe he has some ideas about how to resize clouds dynamically and how to place them dynamically at configurable positions?

Having a way to make clouds move according to their surrounding air mass (i.e. windspeed at that altitude in FG), would be also pretty cool.
You could also try asking on the developer's mailing list.
Perhaps, there's a good way to make cloud attributes such as "size", "position" and "type" configurable by using the property tree?

And by the way: some time ago you wrote:
WooT wrote:But, I have really poor programation skills, and would not even think about making the core work...

Well, seems you underestimated your skills, cause you seem to have done exactly that meanwhile ;-)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Some thoughts on simulating ridge lift

Postby WooT » Sun Apr 19, 2009 5:54 pm

I have just received a mail from Ian Forster-Lewis , the author of the original ridge lift ground sampling algorithm, in which he agrees for inclusion of his work into FG, provided that his name and link is included in the code.

He also proposes a refinement of the way sink is calculated on the lee side, I will try to work it out with him.

So I have updated the files with proper GPL licensing, and tried to make some code corrections so that it fits better with the FG code style and habits.
Corrected an error which made lift work at reverse on negative longitudes. Ridge lift is now correctly handled by environment, and doesn't rely on AI anymore.
( I had to modify slightly the way thermals send their strength to environment, I included this in the zip )
I can use it without errors my side, but it would be interesting to have more input on this.

You can look at all this in:

www.bentha.net/fgfs/ridge-lift/ridge-li ... onment.zip

Hoping it finds some interest,
WooT
WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 5:09 pm

Re: Some thoughts on simulating ridge lift

Postby WooT » Mon Apr 20, 2009 3:38 pm

Ian posted an interesting reply to the flightgear devel list
and opened a page on the wiki about improving glider realism.
I thought it was time to open a new thread about this in the forum :

viewtopic.php?f=6&t=4706#p33902
WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 5:09 pm

Re: Some thoughts on simulating ridge lift

Postby Hooray » Tue Apr 21, 2009 9:56 pm

WooT wrote:He also proposes a refinement of the way sink is calculated on the lee side, I will try to work it out with him.


For approximating this, you might want to check out: http://www.auf.asn.au/groundschool/umod ... tml#eddies
In general, there's lots of comprehensive information about meteorology available at: http://www.auf.asn.au/meteorology/index.html

The mountainflying.com website also has some useful information: http://www.mountainflying.com/Pages/art ... lying.html

Image

In the light of the recent discussion on a virtual FlightGear gliding club at LOWI (Innsbruck, Austrian Alps), it would actually be pretty interesting to see if the current terrain sampling technique could possibly be also used eventually to implement support for realistic Foehn Winds, a phenomenon not just specific to Austria, but one that is often to be seen in alpine regions (Austria, Switzerlandand, France, South America) directly related to lee side sinks, and one that in fact causes heavy turbulence that severely affects all aircraft, not just gliders.

Image
Image
Image
Image


Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Some thoughts on simulating ridge lift

Postby B21 » Wed Apr 22, 2009 9:51 pm

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:
Image

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:
Image

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
B21
 
Posts: 12
Joined: Mon Apr 20, 2009 10:42 pm

Previous

Return to Weather

Who is online

Users browsing this forum: No registered users and 2 guests