Board index FlightGear Development Weather

Some thoughts on simulating ridge lift

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

Some thoughts on simulating ridge lift

Postby Hooray » Wed Apr 01, 2009 8:35 am

Woot wrote:I'm also trying to think a way to generate thermal and ridge fields for multiplayer


At the moment, thermals are mostly based on custom AI models that aren't exposed via the multiplayer protocol.
Also, thermal modeling is still relatively crude overall and needs to be individually configured using static XML files, that are local and specific to each fgfs client.
So, various clients could use different "thermal scenarios" on multiplayer and would all get to see and experience different thermals, because the multiplayer system is not thermals/AI-aware.

Most of this can probably be better achieved by using a glider with a null/nasal FDM whose velocities and orientation can be directly written to the property tree.

Implementing ridge lift is a pretty neat idea because it would be multiplayer agnostic as it would logically occur on all clients with ridge lift support, in fact the phenomenon itself would also affect non-gliders (in the form of naturally-occurring turbulence).

Woot wrote:depending on real weather, thought this one will probably be a hard one

Depends on if are you aware of any raw data sources (=easy to parse/process) for gliding/soaring weather?

The ridge lift thing is probably very well possible to implement without too much work - here are some unsorted thoughts:

Modeling ridge/orographic lift requires a way to interactively query your aircraft's environment for certain properties that are characteristic/required for ridge lift to occur, that's mostly the terrain elevation in the direct vicinity of your aircraft in order to determine if the terrain beneath your aircraft is a "hill", "mountain" (or "ridge"), and then also the predominant winds and temperatures/moisture.

This terrain querying or sampling needs to take a segment/area of a certain size into account, not just your present position - so that you can compare the ground elevation for a whole area in order to determine if the terrain's curvature is typical for ridge lift to occur (and where it would logically need to occur).

If it is, you'll probably want to factor in the wind speed and relative AoA of the wind on the ridge, in order to compute the resulting vertical airspeed and vector to emulate rising/failling airmasses at the appropriate locations above the ridge.

Factoring in the wind is the most straightforward thing because the current weather system in FlightGear isn't location-specific, everything applies to your aircraft's current position - all the required data is to be found in the property tree under the "environment" branch, and can be easily accessed and manipulated using Nasal.

While all this would be ideally done in C++ space and could be exposed via a handful of properties by FlightGear (e.g. "/environment/aircraft-is-above-ridge", "/environment/ridge-left-intensity"), implementing this doesn't necessarily require C++ or recompilation, because Nasal scripting could very well be powerful enough:

In the FlightGear base package, you can find a Nasal module called "geo.nas" this provides basically most of the code (a terrain query API) that you need in order to implement support for ridge lift as a nasal module (script), so that you don't have to recompile FlightGear.

Given that gliders are not high performance aircraft, sampling the aircraft's underlying terrain at a rate of 0.5 to 3 hz should probably be sufficient for most situations, this could be implemented using Nasal based timers, so that the sampling code isn't run too frequently. Indeed, by emulating the concept of coroutines you could increasingly update the sampled area, so that not the whole area is sampled at once, but instead incrementally.

In fact, you could make the terrain area to be sampled runtime configurable using properties and listeners, so that you can manually tweak the sampling area's dimensions to determine suitable values while developing this ridge lift module.

Also, I am sure there must be some scientific papers on simulating ridge lift, so that one could try to reuse algorithms in order to emulate proper ridge lift behavior.

Similiarly one could approach the task of modeling thermals using Nasal for different landcover types, and weather situations.

I don't know however if it's currently possible to dynamically place 3D clouds in the appropriate areas using Nasal or the property tree, but that could probably be added easily if needed - as a crude workaround you could fall back to placing 3D objects in these spots using the same geo.nas module for thermal clouds.
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: How about a virtual gliding club?

Postby WooT » Wed Apr 01, 2009 10:11 am

I was just thinking very vaguely, your answers are impressive ! Nice to see someone with interest in this :)

I had this idea of a server that would be aware of gliders positions, and that would host a modelisation of the thermal/ridge estate. Then, based on a network connection ( like atlas or mp use ), the server would send you the air speeds around you, at some Hz frequency. Or, it could send you a "chunk" of the air mass model, so that everyone has the same in a given region, and it could be updated less often.
Plenty of problems appear, like, does it generate and serve all the world airmasses ? This is very unlikely. Just a region ? Which region then ? Maybe a region around where some gliders are 'asking' information at a given time.
About ridge, I'm pretty sure it must be relatively easy to retrieve a normal map of an area from the terrain model, which could be converted and used as a "ridge lift probability map". It could also be used to determine if a slope is under sunlight, and thus if a thermal is likely to occur here in afternoon. Just thinking out loud.
Other big problem : I have some knowledge about gliders and aerology, as an ex glider pilot. I can host a server, at least for several monthes. I have some capacities to do basic scripting. But, I have really poor programation skills, and would not even think about making the core work...
Hopefully this idea can be discussed, and someone would be interested in coding it ? ( maybe in another thread ? so that we don't pirate this one ? )

BTW, I flied at LFLJ, very nice sloped runway ! Its quite hard to land properly on this :) The LOWZ - LOWI route is nice too. LOWZ looks like a nice little place to be, it just lacks a hangar and a club house :P
WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 5:09 pm

Re: How about a virtual gliding club?

Postby Hooray » Thu Apr 02, 2009 12:07 am

Woot wrote:I had this idea of a server that would be aware of gliders positions, and that would host a modelisation of the thermal/ridge estate. Then, based on a network connection ( like atlas or mp use ), the server would send you the air speeds around you, at some Hz frequency.

While that would surely be possible, it would require not only a separate server, but also a data source for thermal/updraft activity, if you don't want to compute everything on the server side based on some sort of weather simulation?

However, by just computing these locally, on the client side using identical scripts and settings, such a server would not be needed - as long as all participating clients make use of the same environmental settings. So this would simplify the design and implementation in the beginning.

Woot wrote:Or, it could send you a "chunk" of the air mass model, so that everyone has the same in a given region, and it could be updated less often.

At the moment, FlightGear doesn't really have any advanced "air mass model" that would allow you to easily create airmasses with certain characteristics (position, airspeed, behavior, temperature) in order to cause updraft-like behavior on a passing airplane.
I don't think that it's currently directly possible to apply updarft to only certain components of the aircraft (e.g. nose, left wing, right wing, tail) - this however would be very useful, because that's how glider pilots often detect updraft activity, i.e. by pitch up/down movements of the wings on one side, so that they get to sense where the thermal activity is to be found.

So, normally updrafts don't just magically result in changes of vertical airspeed, but initially they are confined to occuring only at a specific section of the airframe, which the glider pilot then uses to maneuver into it in order to make best use of it, similarly you try to maneuver out of falling air masses.

This would require a way in FlightGear to apply offsets to the current airplane's orientation (attitude) and velocities, and have the FDM respect these, instead of just overwriting them.

So that flying through an updraft with the left wing tip would actually result in a pitch up movement of the left wing, along with an increase in vertical speed that's consistent with the updraft occuring there.

Woot wrote:Plenty of problems appear, like, does it generate and serve all the world airmasses ? This is very unlikely. Just a region ? Which region then ? Maybe a region around where some gliders are 'asking' information at a given time.


I think it would be best and easiest to just compute these locally for each aircraft, and a certain area around it.
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 Hooray » Sat Apr 04, 2009 7:02 am

Well, turns out my idea wasn't all that bad -or revolutionary in the first place: exactly this approach has been implemented as a community addon for MS FS X, 1.5 years ago:

Abstract:By sampling the ground elevation of the terrain in a windward direction relative to the current position of the user aircraft, an appropriate value of applicable topographic lift can be calculated. The technique is highly efficient for flight simulator use as only the lift at the current location of the user aircraft needs to be calculated. With a small number of ground elevation sample points, highly detailed topographic lift can be simulated.



Here's a complete technical description, including a scientific paper, formulas, algorithms and source code:

Efficient simulation of topographic lift in Microsoft Flight Simulator (FSX)

So they are basically sampling the terrain along a vector of the wind for a handful positions to determine how the wind is interacting with the terrain:
Image

Then they calculated the slope between each sampled point:

Image

Topographic lift calculation formula

1. Ground elevations aligned into wind at 0m, 500m, 1000m, 3000m and -500m from the user aircraft.
These will be referred to as ground_elevation[0..4] (metres), and distance[0..4] (meters) respectively. (distance[0] will always be zero, as the zeroeth probe is the user aircraft).
2. The current wind speed, which we shall call wind_speed (meters per second)
3. The height of the user aircraft above the ground, aircraft_agl (meters).


Here's a discussion about implementing this for MS FSX: http://www.forum.aerosoft.com/index.php?showtopic=24498
This discussion is interesting because it also shows restrictions in MS FSX, some of which are unknown to FlightGear due to its powerful property tree interface and the fact that many extensions can be programmed using scripting (the MS FSX plugin has to be programmed as a C++ plugin).

While it should be fairly straightforward to compute ridge lift using JUST scripting means, most of the functionality could also be exposed by hardcoded properties, especially due to having the C++ source code available
that's doing all the computations.

I didn't find any licensing statements, one should probably first get in touch with the author (possibly using the forum).

The formula to compute terrain offsets for any given lat/lon using a bearing and distance (as required for this approach), is available at http://www.movable-type.co.uk/scripts/latlong.html (online calculator here: http://williams.best.vwh.net/gccalc.htm)

It seems the most complicated thing really is feeding the appropriate vertical airspeed back into any of the existing FDMs, as far as I can see there doesn't seem to appear any existing way to apply offsets to either the velocities or the aircraft's attitude, so that needs some further thinking.

So for the moment the challenge is two-fold: 1) find a way to model and compute ridge lift (solved) and 2) find a way to make FDMs such as jsbsim or yasim aware of this lift so that the in-flight behavior is influenced appropriately.

Some other related links:
http://carrier.csi.cam.ac.uk/forsterlew ... /lift.html
http://carrier.csi.cam.ac.uk/forsterlew ... sim_probe/
http://luerkens.homepage.t-online.de/pe ... X_main.htm
http://luerkens.homepage.t-online.de/peter/
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 » Sat Apr 04, 2009 6:02 pm

maybe I am wrong, but it seems the current thermal in AI, plays with "wind-from-down" ?

it gives some updraft, but unfortunately, it must not be able to lift only one wing if you enter the thermal on its side, for instance. same for a hard "cut" ( how to say this in english...) between peripheral sink and center updraft: some pitch change should happen if you enter/exit the thermal straight forwards. Same too in turbulent areas behind a terrain edge.
WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 5:09 pm

Re: Some thoughts on simulating ridge lift

Postby HHS » Sat Apr 04, 2009 8:42 pm

Hi,

That's correct, te thermals plays with "wind from down" which is also used for turbulences, so much as I know ( please correct me if not!)
It is a lack of the fdm's (JSBSim and YASim) because the wings aren't "splitted" there, so any foces from below only affect the whole aircraft.

Maybe it could be possible to influence the "wind from down" by this slopes.

Another thing I would like to see, are "real" thermals simplified depending of ground, sun etc. like in real life...
Up, up and away
User avatar
HHS
 
Posts: 3625
Joined: Thu Jul 19, 2007 9:09 am
Version: GIT

Re: Some thoughts on simulating ridge lift

Postby Hooray » Sun Apr 05, 2009 5:31 am

Yes, /environment/wind-from-down-fps was also the first thing that I was looking at when we started talking about this idea, but like you said in its current form it only seems useful to apply vertical airspeed to the whole aircraft, not just to specific sections of it.

Which would however be required for realistic updraft/downdraft behavior in order to also change the aircraft attitude appropriately.

Ideally, there'd be a way to divide the aircraft fuselage into quadrants or sections, that are individually addressable using the property tree.

For example, by using the aicraft axis in order to define something like a "pie chart" based on the center of the aircraft with start/end zones (angles) for applicable vertical airspeeds.

Image

In the property tree, there could be a way to define new "vertical wind zones" by having each sector in the "pie chart" be based on an start/end azimuth from a point on the aircraft:

Code: Select all
/sim/environment/vertical-wind-zones/sector[0]/start-azimuth-deg=350
/sim/environment/vertical-wind-zones/sector[0]/end-azimuth-deg=60
/sim/environment/vertical-wind-zones/sector[0]/vertical-wind-speed-fps=3



The most significant limitation in this idea would be the fact that it applies the same vertical airspeed to the whole sector, which is also pretty simplistic - because normally, you may just have one part of the wing within an updraft or downdraft, while the rest isn't affected automatically.

In other words, if only the wingtip is subject to an updraft, not the whole wing should be exposed to the same lift.
But this could probably be solved by also specifying an interpolation table for each sector, so that the strength can be varied based on the distance to the center of the aircraft.

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 WooT » Fri Apr 10, 2009 8:30 am

ok, this is not ridge lift, but thermals

I have been working on refining the thermal modelisation.

This is a first attempt, with still a lot of limitations,
but it gives the thermal a much better shape and behavior yet.

These thermals lean in the the wind, the more wind, the more they lean.

They are surrounded by a global, gentle sink, which is unrealistic for now, but makes the flight a bit more challenging. I have set this to -1 fps, I will change this in a next version.

They are slightly conical, with a 0.8 factor at the base.

They are surrounded by a slight sink area, that we often feel when entering a thermal in real. When you come from outside, from the 'global sink' area, you gradually feel some sink, until sink reaches 0.25 times the max updraft that you will find at this altitude. probably unrealistic too, but its an approximation, again. Then updraft goes stronger, until you reach the thermal core.

The power of the maximum updraft you find depends on your height too. From ground level to 1/10 of the thermal height, you don't feel updraft at all, then, the higher you climb in it, the stronger the updraft. When reaching into the cloud, updraft slowly tends to zero. For simplification I made this happen at 1.1 times the ceiling alt. This could be refined, as in real, the updraft continues in the cloud, almost until reaching the cloud top, at an altitude which depends on the strength of the thermal. But we aren't supposed to be here with a glider, are we ?

A picture talks better maybe :
Image

If you set the strength to a negative number in the demo xml file, then you get a big sink. This one behaves differently. When coming from outside, you are feeling 'global sink', then gradually sink raises to its maximum until you reach the sink core. Again, if you come down close to the ground, or high close to the ceiling, the sink effect goes lower until it reaches zero.

Be careful when setting the demo file, so that either 2 thermals or a thermal and a sink don't overlap. This leads to strange results, due to the fact that for now, FG only takes the effect from the closest. When FG suddently takes the other one in account, you could get a abrupt break in lift/sink. I included a demo file whith no overlappings.


In the code, you will find that there is a life cycle ready to be used. I disabled it for now, because , so far I didn't find a way to make the thermal cap appearance change with time. So you could see a nice cumulus, go under it and find nothing at all.
Its easy to toggle it on again, by just commenting/uncommenting 2 lines.
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.

Basically, the life cycle makes this :
first the thermal is not born.
then it begins to appear, and grows both in intensity and altitude, until it reaches the ceiling after 5 minutes. Then, it stays active for 15 minutes. At this moment, it begins to die, from bottom to top, until nothing is left. It waits 5 more minutes, then starts again the cycle.
Some random offset is added so that all thermals live their lives at different moments.

All the time numbers are hard coded for now, as well as the proportion between lift/sink radius, the global sink, the height of the 'cloud', the conical factor ,so that the new thermal is compatible with all old thermal demo xml files.

You can get it all here : http://www.bentha.net/fgfs/thermal/new-thermals.zip.
( keep a copy of the original ones ! )
My code is probably very ugly and not efficient, I am not a coder, I really don't know how it should be made to be better, but at least this works ( for me ).
If someone is willing to make it cleaner/faster , it would be neat. All the global idea and math is here ready for use :)

What I am working on now, is a totally different approach.
So far in FG, we have thermals that one has to 'plot' in a xml file, each being a AI object.

I am working on a big 'thermal system' AI object, which is the modelisation of a big area of the atmosphere around its center. everything can be refined to a higher level or complexity and realism in this.
You would just define a x,y size of the big thing, and put it somewhere. Its not really consuming in cpu, as this is all parametrical, and only needs to compute the closest ones to the glider. Its probably more memory eating, though.
The thermal caps will be submodels of the 'thermal system', and they would move and animate to display the 'state' of the whole thing.
Again, I don't find how to make simgear pop a 3d cloud here, but I'm sure someone skilled could do this.
One of the nicest feature is that these thermals can move with the wind, climb slopes, die on edges, never appear on sea, lakes....appear more often on cities, and most of all, depend on the real weather. You can give it parameters, too, so that it produces more or less thermals, a lot of small, distant ones, or big fat weak ones, or anything. The life cycle can depend of temperature, time in the evening... The formulas to make something certainly not physically correct, but realistic enough to have a nice soaring feeling, are not that complex.
I'm almost sure I can introduce real hour time in the calculations, so that everyone feels the same scenario in multiplayer, or at least something close enough to do nice flights together.

Another thought, if we had two 'wind-from-down' properties in the tree, one tied to thermals, and one tied to the ridge lift thing, we could simply add the two ones to get the result of both phenomenas.

About the the problem of dividing the updraft in sectors around the plane, what if the plane could 'ask' for updraft at the tips of its wings, and then find a momentum based on the wing lenght / lift ?
I'm not sure it would be very realistic.
I would say that we need an FDM which takes vertical component of the wind in account, depending on the distance from the COG. Wings could be cut in a number of smaller wings, maybe. And the horizontal tab should use its own vertical component. In fact, each part of the wings should.
Maybe we could ask Andy what he thinks ? That would be for sure a nice improvement to FG.
WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 5:09 pm

Re: Some thoughts on simulating ridge lift

Postby WooT » Fri Apr 10, 2009 10:34 am

I have just read the paper about ridge lift more carefully , and see a potential issue.

I have used in my thermal thing, if (globals->get_scenery()->get_elevation_m(SGGeod::fromGeodM(pos, 20000), alt, 0))
to get the elevation of the thermal foot.

I have read in several places that this is fairly heavy on the cpu, so I trigger it only every 10 sec.
The method described for calculating ridge lift, uses 5 ground scans every second, could someone say if this is too heavy ? or is it reasonable ?

I'm interested in this, not only for the ridge lift code, but also for my thermals once they move.

Anyways, I'm willing to give a try to the ridge thing too, it seems to be quite doable, even if in a first time it only returns wind-from-down for the whole aircraft, that would be really neat to have ridge flights with friends in the alps :)
WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 5:09 pm

Re: Some thoughts on simulating ridge lift

Postby HHS » Fri Apr 10, 2009 12:27 pm

Hi WooT,

That sounds great!
But it sounds like a a good improvement, and soaring is something which is very underdeveloped in FGFS.
So for more help, it would be good to go on the mailing-list as well, then the most interested developers don't read the forum. So maybe it can be even included into CVS- the place for developement in FGFS!
Up, up and away
User avatar
HHS
 
Posts: 3625
Joined: Thu Jul 19, 2007 9:09 am
Version: GIT

Re: Some thoughts on simulating ridge lift

Postby Hooray » Fri Apr 10, 2009 2:05 pm

Hi,

I haven't yet read everything, indeed lots to catch up with!
However, here are just some quick comments:

The method described for calculating ridge lift, uses 5 ground scans every second, could someone say if this is too heavy ? or is it reasonable ?


I can only say that according to my observations, sampling the terrain in FlightGear at a rate of 5 hz or even more, really is no problem at all from a performance point of view (I'm not sure where you read about these queries being possibly too heavy, but keep in mind that the ridge lift paper is in general about MS FSX):

Back when we started talking about this, I mentioned geo.nas (the script with the terrain query API for nasal) and when I later found that ridge lift paper, I explicitly checked for any performance issues involved in doing these queries at that rate from Nasal.
And I really couldn't find it to affect simulator performance in general, or framerates in particular.

In fact, you could even try for yourself by running the queries at a runtime configurable rate (be aware though, that this is obviously limited to the update rate of the nasal interpreter itself):
Code: Select all
var control_property = "/terrain-query-test/sampling-rate-hz";
var update_rate_hz  = 1;
var pos = nil;
setprop(control_property, update_rate_hz);

var show_sampling_rate = func {print("sampling rate is now:"~getprop(control_property)~"hz\n");}
setlistener(control_property,show_sampling_rate);

var show_latlon = func(p) print("lat:"~p.lat()~"/lon:"~p.lon()~"\n");

var sample_terrain = func {
  update_rate_hz=1/getprop(control_property);
  pos = geo.aircraft_position();
  show_latlon(pos); 
  settimer(sample_terrain,update_rate_hz);
}

print("terrain-query.nas loaded\n");
show_sampling_rate();
sample_terrain();
print("You can control the test by modifying "~control_property~" using the property browser\n");


So, just turn on the fps display and you'll see that even doing these queries at 10-20 hz (hardly necessary) doesn't pose a problem at all. I addition, the console I/O is most likely to be the bottleneck in such an example, too.

Also, keep in mind that this is all in scripting space, and you've been working in C++ space, which is even faster because there's less indirection happening, and no console I/O just calculations in the background.

So, I really wouldn't worry about querying the terrain at a reasonable rate like 5 hz - in particular because this is really not about querying an area of terrain, but just a handful of points in the direct vicinity of the aircraft.
Thus, it seems already very efficient as an approach in itself.

Also, you could simply make the update rate property-based so that it can be configured by users easily.

Besides, I have to agree with HHS: if you're interested in possibly seeing your code committed to CVS so that it may become part of future FlightGear versions, you are generally well advised to post your patches to the developer's mailing list, where developers are most likely to become aware of them.
In fact, even doing that is no guarantee that your code actually ends up in FlightGear, but your safest bet is still the developer's mailing list ;-)
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 Hooray » Fri Apr 10, 2009 5:57 pm

Just for your info: I took the same script, wrapped the sampling function into a different nasal thread with an infinite loop, so that it can be run at a higher update rate than the interpreter itself (the maximum confirmed rate I was getting inside the main loop was framerate bound), and FlightGear only started to be visibly affected (i.e. 1/3 cut in framerate and laggy scenery) when the sampling rate was 35 khz, i.e. 35000 iterations per second - that should be good enough :lol:
Putting in 5 sampling calls to geo.aircraft_position() still provided approximately 7 khz.
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 AndersG » Fri Apr 10, 2009 7:48 pm

Hooray wrote:Just for your info: I took the same script, wrapped the sampling function into a different nasal thread with an infinite loop, so that it can be run at a higher update rate than the interpreter itself (the maximum confirmed rate I was getting inside the main loop was framerate bound), and FlightGear only started to be visibly affected (i.e. 1/3 cut in framerate and laggy scenery) when the sampling rate was 35 khz, i.e. 35000 iterations per second - that should be good enough :lol:
Putting in 5 sampling calls to geo.aircraft_position() still provided approximately 7 khz.


You called geo.aircraft_position() from another Nasal thread? I'm amazed the whole thing didn't crash.. AFAIK there is not synchronization (and hence no safety) when calling FlightGear functions from independent Nasal threads (in particular anything that invokes FlightGear internals or accesses the property tree would seem extremely hazardous).

If you have heavy but independent computations to do putting it in a Nasal thread could be a good thing to do to utilize additional processors/cores (something FG in itself isn't good at currently) - but you'll need to make your own threadsafe communication channel(s) between the main thread and the computation thread(s).

Cheers,

Anders
Callsign: SE-AG
Aircraft (uhm...): Submarine Scout, Zeppelin NT, ZF Navy free balloon, Nordstern, Hindenburg, Short Empire flying-boat, ZNP-K, North Sea class, MTB T21 class, U.S.S. Monitor, MFI-9B, Type UB I submarine, Gokstad ship, Renault FT.
AndersG
 
Posts: 2524
Joined: Wed Nov 29, 2006 10:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Re: Some thoughts on simulating ridge lift

Postby WooT » Sat Apr 11, 2009 9:30 am

I have ridge lift working !

I followed the paper from the FSX guys and made it into a AI object.

It WORKS, and , even, it works GOOD !
I am just taking a pause in a long flight in the valley at LOWI, getting a nice +5 fps updraft with a 10 kts wind :)
It behaves really nicely, the closer you are to the hill, the higher the lift, until some point when it drops because of friction, it reaches a maximum above the hill top, then drops hard behind the edge. awesome :)

Now we really need to contact the author on the forum, about licensing.
I wrote the code entirely, just used their adjustment formulas and the basic sampling idea, so I presume it should be no harm ? I'll email them anyway.

I sent you a PM with the link to the code if you are interested. I think its better not to publish it until we get the answer from the author.

Again, my code is probably not nice, but I'll post about this on the dev list.

I don't feel any performance drop with 5 ground scans / second.
WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 5:09 pm

Re: Some thoughts on simulating ridge lift

Postby AndersG » Sat Apr 11, 2009 9:44 am

WooT wrote:I have ridge lift working !
Now we really need to contact the author on the forum, about licensing.
I wrote the code entirely, just used their adjustment formulas and the basic sampling idea, so I presume it should be no harm ? I'll email them anyway.


AFAIK the only snag (since you wrote your own implementation) would be if they have patented the technique - at least in those countries that have software patents.

Cheers,

Anders
Callsign: SE-AG
Aircraft (uhm...): Submarine Scout, Zeppelin NT, ZF Navy free balloon, Nordstern, Hindenburg, Short Empire flying-boat, ZNP-K, North Sea class, MTB T21 class, U.S.S. Monitor, MFI-9B, Type UB I submarine, Gokstad ship, Renault FT.
AndersG
 
Posts: 2524
Joined: Wed Nov 29, 2006 10:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Next

Return to Weather

Who is online

Users browsing this forum: No registered users and 2 guests