Aerosoft official retail partner for Microsoft Flight Simulator !! 
Click here for more information

Jump to content
Sign in to follow this  
B21

why does CumulusX need a slope file?

Recommended Posts

For ridge lift, as CumulusX is connecting to FSX via simconnect anyway, could it sample the terrain near the users aircraft and decide the slope for itself instead of the CCS2004 slope file?

With the wind speed and direction from the simconnect interface, CumulusX could optimise the samples needed for slope calculation function in that you would most likely sample the ground heights *upwind* of the users current position.

It seems like then it could inject ridge lift into any terrain you flew over.

Did I miss something ?

thanks,

Ian

Share this post


Link to post
Share on other sites

I like the idea, BUT, People may have different terrain than others, so in multiplayer and offline for that matter would not be the same for everyone. Also not sure as to how the settings within FSX terrain would affect the outcome too. Am I somewhat right on this?

sf4JC

Share this post


Link to post
Share on other sites
I like the idea, BUT, People may have different terrain than others, ...

sf4JC

Welll, first of all I think there's a technical point of *how* do you get the ground altitude for a point other than directly under the aircraft via simconnect - I've posted a question on the avsim forum as below:

simconnect post at avsim

But... how about this as an example implementation... a module in FSX (with *no* user interface) continuously samples the terrain height at six points extending 4.8km from the current position of the user aircraft in a straight line directly into the ambient wind. (E.g. at 0m, 300m, 600m, 1200m, 2400m, 4800m).

From just those sample points, plus the strength of the ambient wind, you calculate a lift factor (+ or -) and apply it to the user aircraft.

The fact that you could find ridge lift/sink wherever you fly with no pre-preparation or configuration should be quite a plus, and I would suspect the differences in mesh between users would not be too much of a problem. You could point to other issues such as the possibility of error due to the simple straight line analysis but I've thought about that and am not sure it's such a drama in practice, outweighed by the simplicity of use. Or you could sample more than a straight line, but I think the benefits would be limited.

Share this post


Link to post
Share on other sites

Hi Forster,

nice to meeting you here again. I had already this idea, but the limitation for the time being is, that you can only get information on AGL elevation at the user's aircraft easily.

In principle, it could be possible to create a "ghost" AI aircraft, which you can misuse as a probe to check ground elsewhere. However it is not absolutely sure, how the scenery engine deals with that. From FS9 you know, that correct sampling of elevation is a tricky thing that easily interferes with computer load, the delay time etc.

Another thing is that the preprocessed slope data base is awfully efficient during realtime gameplay, so that it doesn't cost any FPS.

Because I felt it a bit urgent to come to working solution in reasonable time I concentrated on what was certainly possible. A further opportunity with the slope data base (on longer term) is to make a much more realistic slope lift effect, eventually even with a reasonable wave simulation, that cannot be achieved by realtime calculations. I'm tossing already some formula around in my mind.

In the meantime I made some progress with the thermal lift. The last open thing before the next release (0.7) is the adoption of the cumulus layer altitude of the FSX weather system. Then we have mostly compatibility with CCS2004 4.0 There is still the issue with magnetic wind and direction and geographic wind direction. CCS2004 uses magnetic wind direction but translates it into geographic oriented leaning and slope direction dependency.

I decided to not support the his very last version 4.02, which had some drifting thermals and was never released publicly over Eric's Website. It turned out to tedious to resemble all the details to be truly compatible.

However I'm planning an CumulusX! native thermal mode which puts thermals under FSX original clouds. This will be drifting by nature.

Anyway, we could start a discussion on the pro's and con's of have an embedded approach of slope slift, and its impact on the simulator, e.g. in view of racing.

best regards,

Peter

Share this post


Link to post
Share on other sites

I can't see a substitute for the thermals/clouds that CumulusX! is providing, but I'm still interested to know if the ridge lift provision is still dependent upon a slope file - I'll see if I can mock something up over Christmas so we'll have concrete information about whether it works or is too inefficient. I would see two advantages:

(a) you no longer need a slope file *outside* of FSX, although I recognise the pre-processing of this file provides an efficiency opportunity.

(B) the ridge lift utility would be easy to package with missions.

I do have a basic question about the CCS2004 slo files though - do they simply contain the gradient at every point on the map? If so what's the basic formula for ridge lift in CumulusX! - do you simply look at the gradient at the spot below the aircraft? If so wouldn't that mean a small hill on top of a large plain would give the same lift as the top part of a high ridge with the same slope ?

The concept I'm aiming for is to sample height of the ground *upwind* of the user aircraft, e.g. from A to B on the map below:

gradient2.gif

From that I can derive the land upwind of the users aircraft :

grad_falls.gif

And given the AGL height of the aircraft choose a suitable lift factor, and you could discount the lift if there is more high ground *upwind* of the aircraft even though it's on a local upslope. The neat twist (I think) is to only sample the land upwind of the glider...

Ian

Share this post


Link to post
Share on other sites

Hi Ian,

sorry for name-misconception. By incidance I found out myself, too, today.

To answer your question:

You may look in the CumulusX! topic also, there are some remarks about the differences (and confusion) in existing slope files. Basically the they contain the slope orientation (geographic declination) and the steepness angle (inclination), altogether the gradient. Each is parameter coded in 16 steps using hex-cyphers from 0-F, orientation first. A confusion is, that while scanning CCS2004 is calculating the slope steepness as something like :

inclination = atan(3y/x), being y the difference in elevation and x the base, leading to angles which are 3 times bigger for flattish slopes as can be expected geometrically.

Hower, all externally coded slope files, namely from Kris Feldman have apparently a correct calculation of the inclination. I personally prefer the second, altough ridge "racing" is much more fun with the first (e.g. with Andrew Torrance files).

CCS is calculating the slope lift basically as

lift = windspeed * cos (wind_angle_mag - slope_orientation) * sin(slope_steepness_angle) * 1.176 (all in equal units)

In sink it is only 50% of that value, which make lee-side conditions not too bad.

CumulusX! calculates in native mode

lift = windspeed * cos (wind_angle_true - slope orientation) * sin(slope_steepness_angle)

which makes terrible sink in lee-side conditions.

In compatibility mode it is the same as in CCS, with exception of the wind angle wich is always true. There is a decay behvaiour with increasing AGL altitude, which is linear in CCS, but with a decay rate, depending on the initial lift, the same again in CumulusX! in compatibility mode.

In native mode it is exponential, depending on the ground elevation (see pictures below).

Both programs only sample the patch immediately beneath the aircraft, which is one of the shortcomings. Nevertheless, one could put anything the slope database file which considers the environment, too. However If you are _very_ close to ground you will finally end up with somehting like this.

In addition, I plan a second layer of slope-data files containing fourier coefficients, with which eventually you can simulate wave lift, too (and also ridge lift at higher distance to ground). Perhaps we could team-up here and create a set of tools?

What could be also an enhancement would be a tool to read out the mesh-bgls from MSFS directly, and preferably offline. This would allow to create the slope-database in background matching the exisiting scenery. Up to now I have not found an opportunity to do this except with the already mentioned prob-AI aircraft, which I expect sluggish and prone to errors.

regards,

Peter

post-176-1197494179.gif

Share this post


Link to post
Share on other sites

Thanks Peter - that's a *really* helpful reply. I was very interested to see how you increase the ridge lift near the ground so thanks for the pictures which present the situation clearly. Flying the long ridges of the Appalachians (~2000' high) on a decent ridge day its difficult to get down to ridgetop because the lift (and turbulence) is too strong, but at 2000' above the ridge the lift drops pretty much to zero - you seem to model a world where the lift goes a lot higher.

I need to try an AI object (not a aircraft though..) with OnGround=1 to see how it performs. I'm sure you're right and it's going to suck for some reason but I need to try it and see. After that I guess I'm back to the pre-processed file...

I still don't see the advantage of using a slope file instead of a similar file simply containing ground altitude - I know you would need to read several points from the 'ground altitude' file instead of the one from the slope file, but you'd expect them to be in close proximity so there'd not be any more disk io. Plus I don't know how frequently you read the file but surely the lift doesn't need to be calculated more than once a second. I don't see how it would be possible to pre-process the slope file to take into account a more detailed profile unless that was done for a specific wind direction. But I reckon even with only 5 ground height samples upwind the lift could be better modelled.

If my 'live sample' technique does fail, I'll come back and discuss the pre-process technique in case I can help there - I certainly wouldn't want to duplicate effort and do something inconsistent.

Regarding the fourier transform for wave modelling I confess ignorance, but then also I've never been a great wave pilot in real life either. Sounds a fun project. In the meantime it is very easy to stick some wave lift in a mission, so we're not suffering too much.

Thanks Peter.

Ian

Share this post


Link to post
Share on other sites

Well,

reagarding the lift decay the right hand side picture has to be read like this:

For an initia lift of 5 m/s read the ground elevation from the bar on the right hand side. Look for the appropriate colour in the image. For 200 ft ground elevation (~600 m) its almost the same for the 0m-line, because the decay is held constant below 500m elevation.

Then you see that the lift decays from 4.5 m/s to 1.5 m/s in 600m AGL. The resulting clim is only around 0.7 m/s and the lift is not usable anymore in 1000m /3000ft. By incidance it is actually close to reality.

Regarding the in-line lift slope calculation I'm very interested in your results, in particular performance wise.

regards,

Peter

Share this post


Link to post
Share on other sites

LOL Peter thanks a lot - I think I've got it now after re-reading your post many times. I'm suspecting the axes of the chart are X = "user aircraft height above the ridge (i.e. AGL meters)", Y = lift(m/s), and the different lines are for different heights of the ground (ground elevation) immediately below the user aircraft (meters). Re-reading your post a few times you could call me stupid and point out thats exactly what you wrote... I guess the bit I didn't get straight away was the use of 'ground elevation' as a factor for lift, i.e. a given slope will produce more lift at 10000' than at 5000' and that lift will extend higher, which I'm sure is a good heuristic. Not understanding the 'ground elevation' box meant I was looking way too far up the chart for a 2000' ridge ...

My intention is to use an AI 'truck' for the ground sampling probe unless something better comes along, and I'll replace the visual model with a big green pointer so I'll be able to see where the ground is being sampled from the cockpit. I'll try sampling once every two seconds. How often do you update the lift affecting the user aircraft ? I know this is a basic question but do you adjust the lift on the user aircraft by updating 'Ambient Wind Y' or is there some other technique.

I *hope* to write a simconnect program (I've never written one but I have a PhD in Computer Science...) that at least gives a reasonable assessment of performance and accuracy of the technique (or even if it works at all). *If* it works maybe we'll work out a way of incorporating the code into CumulusX! as a user-selectable fallback mode where the slope file doesn't exist. I'm expecting to use Visual C++ (free version) and end up with a function along the lines of

get_lift()
which return the lift to apply to the users aircraft in m/s. Internally, this will call
get_plane_pos()
which returns LAT (the user aircraft lat), LONG, AGL.
get_wind()
returns WIND_SPEED and WIND_DIRECTION
get_samples(LAT, LONG, WIND_DIRECTION)
returns six ground elevation samples A,B,C,D,E,F
calc_lift(AGL, WIND_SPEED, A,B,C,D,E,F)

returns lift in m/s

Share this post


Link to post
Share on other sites

Hey guys, just wanted to say THANKS! It's awsome to see 2 great minds at work together, shooting ideas back and forth and growing from it. It adds to what a great community we have here. So again, THANK YOU!

forsterlewis, when you get it written, will you also do some testing on different levels of terrain mesh complexity in your simulation? or Do you think it's too early to ask this question? I'm kinda interested in how a contest could be run with both a person with limited graphics capabilities and someone with unlimited graphics settings. I realize that this is way in the future as far as the developement process, and again probably too early to say. Just want to maybe hear your thoughts on this. Would your addition be for mostly offline use, multiplayer, or both?

sf4JC

Share this post


Link to post
Share on other sites

Hi Ian,

Your confusion is was not that unlikely, because I made the pictures primarily for my own purposes, rather than for publication, and there is little explanation in the pictures themselves.

I think it's a very good proposal to use probing as a fallback. That includes both approaches in one solution, and you can easily set the conditions for various purposes, in particular racing.

As a matter of fact, I'm doing lift calculation every visual frame. Actually lift itself is not needed that fast. Possible 2-5 per second is enough, but I wouldn't do much slower, because with transition to lee-side, close above the ridge things happen quite fast in reality.

The repitition rate is more a side effect of the workaround for the missing vertical wind functionality.

I'm using VB.NET express (also free). There is a working sample "Managed Data Request" in the SDK SP1a, that gave me jumpstart in VB.NET programming. In fact, the first I'm working with a Windows programming environment at all. I have not a clear idea in this moment how it works to integrate C++-code or modules in a VB.NET program, but let's see.

best regards,

Peter

Share this post


Link to post
Share on other sites

hi sf4jc - thanks for the thanks but I've still got a bit of coding to do. FWIW I did install the msoft programming stuff (Visual C++) and have compiled my first simconnect app as of half an hour ago, although what the *&%! is going on in the msoft visual programming tool is still a bit of a mystery - what happened to the good old command-line compile ?? But using one of the sample programs provided by msoft with the fsx sdk I've got an object (a whale!) planted at Seattle-Tacoma. I haven't asked it what altitude it's at yet though. Simconnect is quite a remarkable facility - you can make FSX do all sorts of things - but there's a steep learning curve in the beginning.

There's a big "if" as to whether this technique is going to work at all - it could turn out placing an object on the landscape and asking it's altitude is a big CPU eater, but now I've got the whale sitting on the runway I think I'll find out soon. If FSX hasn't fully rendered that bit of the mesh we're guessing whether it would know the altitude of the object at all, but I'm hoping the proximity to the user aircraft means the mesh is fully loaded.

*If* the technique works, we can see what results we get with the default mesh versus another - I'm guessing the slopes aren't that different but we'll see. Note that we're not talking about the instantaneous value of the slope immediately under the plane as today - I can be sampling a distance away (1-2km?) so if you're on any kind of a slope it should show up with any mesh.

The technique would have the effect of injecting 'accurate' ridge lift into any terrain regardless of wind direction or strength, as CumulusX! does today, but this wouldn't need the slope file. And it's equally applicable for free-flight, missions, or multi-player (as is CumulusX today with the right slope file).

But... we have to find out if it works!

Watch this space (or whale).

Ian

Share this post


Link to post
Share on other sites
I'm using VB.NET express

well hey, I've done a whole 30 minutes on this so far so I'll swap to VB.net express...

I think I'll get the basic timing test complete with the C++ code so we know if this seems to work or not, and then write a proper 'sampler' routine in VB.

cheers - Ian

p.s. if you haven't flown them already, try my Austrian Soaring missions - that's where all my FSX soaring development effort has gone in past year or so.

clicky here

Share this post


Link to post
Share on other sites

I'm making progress.

I can plant an object (now a barrel) anywhere in the scenery around the user aircraft, and I can read back its altitude. I've also been moving it around and the reported altitude changes as expected. For the barrel the process seems quite efficient, and I think I have everything I need now to sample the profile upwind of the user aircraft so ridge lift coud be calculated.

I have a bizarre temporary snag though - Peter maybe you can help. The call to get the lat/long/alt of the *user* aircraft is taking 8 seconds to return the values. I'm using SimConnect_RequestDataOnSimObject(...) for object id SIMCONNECT_OBJECT_ID_USER. The call eventually returns the right values but I have no idea what it's spending all the time doing. The same call with the object id of the barrel returns lat/long/alt in milliseconds.

thanks

Ian

Share this post


Link to post
Share on other sites
taking 8 seconds to return the values.

.... fixed. ...

The keyboard key I was using to trigger the 'request data' call ('V') was also by default mapped to the 'capture screenshot' in FSX, and processing was delayed while that completed ....

Iang

Share this post


Link to post
Share on other sites

Good to hear,

I was already speculating about firewall issues and the like. Btw, a while ago I experimented with the barrel, too. If you place it in airborne it will actually drop down!

Interestingly, you can only get these Aircraft-related information, if the object has a minimum visual model. There is the a "test water droplet", which has not. If you use this, you will get exceptions only if you request for altitude, speed and so on.

regards,

Peter

Share this post


Link to post
Share on other sites

Ah thanks Peter - I noticed the water droplet but chose the barrel because I wanted to be able to see where it was... lucky I didn't choose the droplet for my first try. Most of the things I'm finding out are lessons you learn writing any simconnect application, I think. Now I'm past the 'V' key glitch I should be able to make good progress, because I have the 'get_user_pos()', 'get_probe_alt()' and 'move_probe()' procedures all working so now it's *just* a case of stringing them together...

Ian

Share this post


Link to post
Share on other sites

making good progress, although the AI barrel seems to have disappeared in SP2 so I've moved on to the 'Food_pallet' which looks like a large purple igloo.

the aircraft now has a line of five purple igloos running ahead of reading back the ground elevation (the spacing is set very short, just for testing):

probes.jpg

I've not been able to detect any framerate impact.

There's not much else to do - at the moment the direction of the probes is fixed at northeast - I need to read the ambient wind and probe *into* the wind but that's pretty much it.

Peter - how do you generate lift? Do you set 'ambient wind Y' or is it something else ? I'd like to add that final step to my utility to see what the ridge flying is like and then we can work out how/if the technique should be incorporated into CumulusX!

Thanks

Ian

Share this post


Link to post
Share on other sites
There's not much else to do - at the moment the direction of the probes is fixed at northeast - I need to read the ambient wind and probe *into* the wind but that's pretty much it.

Peter - how do you generate lift? Do you set 'ambient wind Y' or is it something else ? I'd like to add that final step to my utility to see what the ridge flying is like and then we can work out how/if the technique should be incorporated into CumulusX!

Writing ambient wind Y is possible, different from the docs, but it is not effective. My solution is to prevent FSX from updating the aircraft Y coordinate at all and handle all vertical movement simulation entirely in CumulusX!. There are some extra tricks to get it halfway smooth. It is however important to have a very quick loop for the Y coordinate update.

If it comes to integration into CumulusX!, you can expect a global structure currently named "AircraftPosition" with a definition of:

Structure defAircraftPosition

Public latitude As Double ' deg

Public longitude As Double ' deg

Public altitude As Double ' m

Public verticalspeed As Double ' m/s

Public absolutetime As Double ' sec

Public wind_direction As Double ' deg true

Public wind_velocity As Double ' m/s

Public altitude_agl As Double ' m

Public freezealtitude As Double ' 0/1

Public airspeed_true As Double ' m

End Structure

best regards,

Peter

Share this post


Link to post
Share on other sites
prevent FSX from updating the aircraft Y coordinate at all

Holy moly! I read a couple of your other posts elsewhere - did the 'planting a thermal around the user aircraft' technique not work?

I'll plod on to finally confirm this ground sampling technique definitely works but I didn't realise passing the lift to the aircraft was going to be so complicated.

Cheers - Ian

Share this post


Link to post
Share on other sites

Well, it works, but the thermals are fairly limited. A crucial limitation is, that they always fade in over 10 seconds, but turn off abruptly when you remove them. Once created you cannot modify any parameter. Altogether it does not allow to mimic a reasonable lift behaviour over time.

In addition, you cannot control appearance of clouds which is determined solely by entries airobjectvisuals.xml.

The overall result is that planted thermals are inappropiate to make slope lift, in particular, and fairly limited for as thermals. That's why I skipped the FSX thermals as a source of lift entirely. Still I use the "CreateThermal" call for producing the clouds, but with a lift parameter of zero.

regards,

Peter

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

×
×
  • Create New...