Board index FlightGear Development Weather

Clouds online

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

Re: Clouds online

Postby Tuxklok » Sat Mar 03, 2012 12:51 am

Thorsten wrote in Fri Mar 02, 2012 9:12 am:For multiple display views or shared cockpit, this wouldn't be an issue because they always have the same altitude profile. For two separate planes - how much does it matter if clouds are displaced by, say, 500 m?


I don't know...500m seems like a signifacant amount error in my opinion, whether it be vertically, laterally, or any combination thereof.
The Austria Scenery Project - more info
fg-scenery-tools - gitorious | videos
fgcomgui - Open source, cross platform, gui front end for fgcom. more info

More random musings and doings can be found on my personal site. (work in progress)
User avatar
Tuxklok
 
Posts: 1320
Joined: Tue Apr 21, 2009 7:04 pm
Location: Orlando, FL
Callsign: Tuxklok / N1292P
OS: GNU/Linux

let's embrace compromises and workarounds :-)

Postby Hooray » Sat Mar 03, 2012 1:00 am

Thorsten wrote:
Thorsten wrote:I think if you use METAR mode and have the same wind models, all you need to transfer is

(lat, lon, random_seed, timeofday+local_offset)

the rest of the info is taken from METAR
Now we're using the windspeed at local aircraft position to render cloud movement, so the actual cloud position you see depends on the altitude profile you have flown since the tile was generated - very bad. The question is - how bad is this in practice?

For multiple display views or shared cockpit, this wouldn't be an issue because they always have the same altitude profile. For two separate planes - how much does it matter if clouds are displaced by, say, 500 m?

Just a thought: what about using the altitude profile flown as another seed that would be propagated from the master to all slaves? Could this be algorithmically averaged/approximated over time and also transmitted to improve the precision?

Or let me put it differently: What about propagating a handful of well-known absolute positions (lat/lon/alt), using the initial seed data - and then having clients determine the smallest possible error, so that clients clients could compute a correction factor to come up with a suitable offset for a number of x clouds in a given sector? Would that be possible?

stuart wrote:T4T is of no relevance to this discussion, which concerns FG.


Bomber, just to clarify: Stuart's comment is almost certainly not to say that we are not interested in your input and feedback, but just having working multiplayer support as part of the local weather system, to create a largely consistent weather experience for players, would be a huge improvement for many users, regardless of the shortcomings and issues that you and your team may see related to combat use of the approach currently discussed here, for most of us, the issues described could be considered "minor".

I can obviously understand how your intended use of the weather system would be affected by such a "simplifcation" though.

But, seriously, it makes sense to learn to walk before you even try to run.
Like I previously mentioned in another thread: the perfect is the enemy of the good.

Just having a system like the one outlined by Thorsten would already be a huge addition, which doesn't mean that it needs to stay like that, I am sure your contributions would be appreciated - the development of the local weather system is largely happening in scripting space, so it doesn't require any C++ knowledge, or the ability to build FG from source.

Let me just warn you, that touching Thorsten's weather code can be a pretty daunting and humbling experience, even for someone who regularly builds FG from source and knows C++, and even hands out Nasal tips and tutorials ;-)

The code and design that Thorsten has come up with is really fairly complex, not so much syntactically - but mainly because of the problem at hand (weather simulation), and it involves some rather advanced concepts implemented in a fairly "unique" (not to say unorthodox) style.
So even if you should know already about objected oriented design and scripting languages, the LW system is a completely different beast.

Please don't just disregard all the workarounds and compromises that you hear about because they may not seem "perfect" or "ideal" from your point of view.

The people who bothered posting replies to this thread, in response to your question, are specialists in a number of domains (many of them being FG core developers) and the results of this discussion have been pretty fruitful actually.

So while you may not see a consistent weather environment for combat use very soon, at least the groundwork is being sketched out due to the questions that you have raised.

If you really want to contribute to this discussion in a constructive fashion, maybe come up with an idea on how to possibly improve the consistency of the environment (i.e. beyond 500m precision) across fgfs clients using Thorsten's distributed approach?
That's probably when you'll notice that the people who responded here, do have a pretty good understanding of the problem at hand, and that they're willing to compromise "to get things done".

Like I said previously, I do still see potential benefits in a server-based approach (especially regarding consistency), but Thorsten is the one who spent hundreds of hours designing the advanced weather system, you won't find anybody else here who's spent so much time thinking about all the problems involved in realistic weather simulation.

It is quite likely that his work will remain the foundation for weather simulation in FlightGear, even for years to come.

So, frankly, I really don't mind standing corrected when he tells me that my thinking is flawed, inefficient or simply not feasible - it's sort of pointless to argue with someone who's written so much code directly related to the problem at hand, and it would show an unhealthy amount of ignorance.
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: Clouds online

Postby Bomber » Sat Mar 03, 2012 5:30 pm

stuart wrote in Sat Mar 03, 2012 12:03 am:
Bomber wrote in Fri Mar 02, 2012 10:27 pm:Yes it does matter If the clouds are 500m different....that's the whole premise of the thread.

T4T server will have AI AAA gun positions, all aircraft need to experience the same AAA sky pattern.

T4T is of no relevance to this discussion, which concerns FG.

-Stuart


This is my thread, and I think i'm entitled to attempt to steer it into answering my original question..

Go start your own thread if you want..i have more than one cloud related effect to resolve

Simon.
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1933
Joined: Fri Dec 14, 2007 8:06 pm
OS: Windows XP and 10

Re: Clouds online

Postby Hooray » Sat Mar 03, 2012 5:49 pm

@Bomber: I could see you responding to Stuart like that, that's in fact the reason why I took the time to respond to you somewhat more carefully, I was hoping you would understand and appreciate that actually?

Like I said, the question that you have raised caused a fairly constructive exchange among fellow contributors, so we do appreciate it.

But obviously, your priorities and requirements are different. Yet, you are not currently in a position to implement them yourself.

So, it is only natural that we are trying to implement what's possible and useful from "our" (FG-centric) point of view, i.e. a "compromise" that already would be appreciated by most users.

This is not to say that your requirements are completely ignored, as could be seen by my attempt at coming up with suggestions to improve the consistency and decrease the error.

I am not sure if you fully understand the problem at hand or not. But I think, you said previously that your profession is in engineering or science, right? Then, it would seem like you could possibly contribute your own ideas here, rather than just embarking on a pointless battle with a forum moderator and FlightGear core developer, which isn't really going to help your case I'm afraid.

Honestly, if you actually took the time to fully understand the problem, you might realize something funny going on here at the moment:
Thorsten mentioned that his original system (entirely prototyped and implemented in scripting space, i.e. as an "inferior scripted addon" in your own terms) would have been suitable to implement support for ZERO MP inconsistencies, while the more efficient hard-coded C++ reimplementation of his scripted code (designed, implemented and provided by Stuart), would cause some new challenges, such as an offset of say 500m among clients.

Now, remember what Stuart previously pointed out:
stuart wrote:I expect it would be easier to modify the Advanced Weather package to provide a consistent cloud experience across MP than Basic Weather, but realistically you'd need to engage Thorten to do that, as realistically no-one else has enough familiarity with it.


The important information that he left out is that he's the one who implemented the hard coded C++ routines to render 3D clouds that are the "rendering work horses" of the local weather system.

So, you managed to attract the attention of the right people already (i.e. Thorsten and Stuart). It's not going to be particularly helpful to alienate them now by disagreeing with their decision making, which is based on much more experience and knowledge than anybody else's who responded to this thread, including yours I am afraid.

The "Bus factor" of the weather system, and the local/advanced weather system in particular is still pretty critical. Like I previously mentioned: it's not sufficient to know C++ and/or Nasal to fully understand what's going on there.
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: Clouds online

Postby Bomber » Sat Mar 03, 2012 9:56 pm

Oh i'm not disagreeing with what they've said on a technical level, just Stuarts comment that it has nothing to do with T4T when the question initially raised was clearly combat related.

I disagree also with Thorsten that 500m isn't a big deal..imagine you're dogfighting, you dive into a cloud only for the pilot chasing you that cloud is 500m away and for his front end you're not hiding in cloud at all... Clearly it's a big deal.

Thorsten and Stuart can take exception at my comments but in reality they are only a user expressing his requirements... These guys can code for their own requirements if they choose but I suspect they'll get a lot more personal satisfaction resolving a users requirement... I know I do.

I learnt many years ago you can't make people do what they don't want to do.. But equally it's my task to debate and document a combat sims requirements for clouds in the hope that someone fancies taking on the challenge...be it Stuart, Thorsten or A N Other.

Regards

Simon.
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1933
Joined: Fri Dec 14, 2007 8:06 pm
OS: Windows XP and 10

Re: Clouds online

Postby stuart » Sat Mar 03, 2012 11:05 pm

@Simon: Sorry for being rude. What I was trying to get across was that my concern (and I strongly suspect Thorsten R's) is primarily with what is required for FlightGear. We're not T4T developers or users, so fulfilling T4T requirements isn't high on our list of priorities. (Plus, this is a FG forum)

Getting back on topic, while I haven't thought about it in detail, I strongly suspect that T4T needs a central server to control AI elements such as persistent AI-controlled airbases and aircraft as well as AA batteries. For example, it would allow you to handle an AA battery aiming at the lead aircraft in a formation. Unfortunately for T4T, I think Thorsten has convinced me that a P2P solution is adequate for FG.

@Hooray: Thanks for explaining.

-Stuart (feeling suitably sheepish)
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Clouds online

Postby Hooray » Sat Mar 03, 2012 11:15 pm

A combat sim, like T4T, will obviously require much more shared state than just weather/environmental stuff - I think, we have already provided a bunch of related pointers to customize fgms accordingly.
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: Clouds online

Postby Bomber » Sun Mar 04, 2012 12:07 am

No problems Stuart, I understand your priorities are not the same as mine, and that its vanilla FG. But a combat sim using FG such as T4T that aims to have an online presence will need a server for AI gun batteries, supply and demand convoys and many other things one of which will be synchronised clouds..

Hopefully someone might be interested in giving it a go..but it doesn't have to be the normal suspects.

Simon
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1933
Joined: Fri Dec 14, 2007 8:06 pm
OS: Windows XP and 10

Re: Clouds online

Postby Hooray » Sun Mar 04, 2012 12:58 am

Like I mentioned previously, many of these requirements will be far easier dealt with once the ongoing DIS/HLA work is materializing a little more.

Anything related to the multiplayer system is likely to become obsolete then. I already sent you a number of pointers regarding this. The wiki contains lots of more info, too.

Personally, I am not too eager to work on the MP system for these very reasons, and I guess that applies to most other users knowing C++ and networking basics.
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: Clouds online

Postby Thorsten » Mon Mar 05, 2012 2:22 pm

Yes it does matter If the clouds are 500m different....that's the whole premise of the thread.

T4T server will have AI AAA gun positions, all aircraft need to experience the same AAA sky pattern.


I don't know...500m seems like a signifacant amount error in my opinion, whether it be vertically, laterally, or any combination thereof.


A typical fully-developed Cu cloud has a size of ~2500 m, that means the cloud position would be different by 20% of its size. I seriously doubt you would be able to spot any difference of that order without specifically looking for it, especially looking from different positions. You'd be surprised at how difficult it is to gauge positions accurately without good reference.



Just a thought: what about using the altitude profile flown as another seed that would be propagated from the master to all slaves? Could this be algorithmically averaged/approximated over time and also transmitted to improve the precision?


The problem is more general.

A) Currently, Stuart's cloud rendering scheme uses the winds at aircraft position to move a whole layer.
B) My previous scheme had assigned all clouds in a tile a given velocity.
C) Nature moves each cloud with approximately the wind at its position.

Scheme C) has the problem at it's very slow - you can't compute wind at 10.000 positions every frame and transform each cloud with that value without losing framerate really heavily.

Scheme B) has the disadvantage that wind felt by the aircraft may not be exactly wind indicated by the cloud (especially at tile edges) - but I had the argument that this doesn't matter because gauging relative motion to clouds accurately is close to impossible, and anyway clouds don't need to move with the wind exactly, a cloud continuously forms and decays, think of a Lenticularis which is static in the wind, or a Cb tower which isn't torn apart by windshear between low and high altitude winds.

Scheme A) is fastest because all cloud movement is just a single coordinate transformation - and nearby clouds for which you can see motion always move with the wind as felt by the aircraft. But that creates synchronization issues.

Suppose we manage to spawn exactly the same weather tile for two players. In scheme B), since cloud motion is a tile property, they would continue to evolve the same way. But in scheme A), if one player flies at 5000 ft where the wind is 10 kt and the other at 15.000 ft in 20 kt winds, the clouds will drift apart with 10 kt even if you manage to create them synchronized. So you can't cast this into a mere synchronization problem at tile creation. But if you want to enforce synchronization later, the problem goes beyond a mere exchange of information - it becomes one of control (and consistency) Nature moves clouds in a windfield C), and at least you must detatch that from aircraft position as in scheme A). My original scheme B) would have been suitable for MP synchronization (this is part of the reason I introduced it that way). But since Stuart's cloud rendering system doesn't recognize 'tile-index' as a valid concept, there is no easy way to get it back and to move clouds by tile again.

And thus, wind is going to be a problem if you require high precision and wind drift of clouds.

This is my thread, and I think i'm entitled to attempt to steer it into answering my original question...Go start your own thread if you want..i have more than one cloud related effect to resolve


No, this is a thread you started, that doesn't mean you own the thread or get the right to restrict what I say here - that is a moderator's call to make.

Likewise, your original question was about what Flightear does with clouds in MP, not about T4T, not about AAA positions. We're actually discussing your original question, but not your intention.

Thorsten and Stuart can take exception at my comments but in reality they are only a user expressing his requirements... These guys can code for their own requirements if they choose but I suspect they'll get a lot more personal satisfaction resolving a users requirement... I know I do.


I frankly don't. I like solving interesting problems.

Hopefully someone might be interested in giving it a go..but it doesn't have to be the normal suspects.


I think you're simply not realizing how difficult cloud motion in a non-constant wind field actually is (the same would hold for rocket contrails, AAA, smoke trails of burning aircraft) especially if you have to exactly synchronize it across a large area. The task alone is sufficient to consume all your framerate.

You can't simply 'have a go' with it. I know it seems terribly easy at first - but when you *really* think about it, it becomes quite a different beast.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Clouds online

Postby Tuxklok » Mon Mar 05, 2012 4:55 pm

Thorsten wrote in Mon Mar 05, 2012 2:22 pm:
I don't know...500m seems like a signifacant amount error in my opinion, whether it be vertically, laterally, or any combination thereof.


A typical fully-developed Cu cloud has a size of ~2500 m, that means the cloud position would be different by 20% of its size. I seriously doubt you would be able to spot any difference of that order without specifically looking for it, especially looking from different positions. You'd be surprised at how difficult it is to gauge positions accurately without good reference


No doubt in many cases it would very unnoticeable unless really looking for it. However what about a group flying in cloudy conditions trying to stay VFR and avoid clouds, flying through the gaps? With a half kilometer error that would lead to some aircraft missing clouds by a wide margin, while others are flying right through them..or seeing others flying right through them while they are missing them by a wide margin. Or if near an airport, a half kilometer laterally or vertically might be the difference between being able to land at that airport or being below minimums or not having visibility.

Thats the cases I'm thinking about...

cheers
The Austria Scenery Project - more info
fg-scenery-tools - gitorious | videos
fgcomgui - Open source, cross platform, gui front end for fgcom. more info

More random musings and doings can be found on my personal site. (work in progress)
User avatar
Tuxklok
 
Posts: 1320
Joined: Tue Apr 21, 2009 7:04 pm
Location: Orlando, FL
Callsign: Tuxklok / N1292P
OS: GNU/Linux

Re: Clouds online

Postby Thorsten » Mon Mar 05, 2012 8:19 pm

No doubt in many cases it would very unnoticeable unless really looking for it. However what about a group flying in cloudy conditions trying to stay VFR and avoid clouds, flying through the gaps? With a half kilometer error that would lead to some aircraft missing clouds by a wide margin, while others are flying right through them..or seeing others flying right through them while they are missing them by a wide margin. Or if near an airport, a half kilometer laterally or vertically might be the difference between being able to land at that airport or being below minimums or not having visibility.


They can't be off vertically, the problem is horizontal motion only.

Thing is, whatever scheme I can come up with, you're always going to say it's not tolerable.

We can do an excat solution of clouds moving in the actual windfield. The framerate drops to 3 fps as a result, but you're guaranteed to never encounter any cloud mismatches in the scene. We have to protect towering clouds agains windshear then (so say we get half the framerate if we have Cb clouds because the keeping clouds stable due to their own strong convection needs to be accounted for, and that's a calculational challenge...). But who'd want to do air combat at 2 fps?

We can refrain from moving clouds in the wind at all - problem solved. But that will be inacceptable because you might be on a bombing run and may want to wait for the target to become visible.

We can do exact motion of clouds in a windfield that is constant everywhere. But then that's not really realistic and will be inacceptable to anyone doing real weather.

We can do cloud motion by tile, which is a compromise between fast rendering and position-dependent schemes - but then wind at cloud and aircraft position will not match up (and surely, if I had asked if you're fine between mismatches in wind between cloud and aircraft, you'd tell me that's not really good either).

We can enforce matching winds between clouds and aircraft per tile - then everything moves in sync at reasonable speed - but then the wind changes discontinuously at the tile boundaries, and we don't want these sudden gusts either.

Or we can do fast rendering of motion which is locally accurate - but then we can't synchronize it.

Please pick your favourite option from the menu (and make a guess why Advanced Weather has four different wind models in the first place...)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Clouds online

Postby sgofferj » Mon Mar 05, 2012 8:53 pm

With a client/server approach, everything would be in sync... Plus it would remove some calculation load from the clients, giving the possibility to render even more complex weather structures.
FG 3.1 GIT / Opensuse 12.3 / Phenom II X4 / GForce GTX560
Stefan's little Flightgear corner | The Finnish Weather Center | Wolves in Finland

Working on: EFTP
COM: IAX2:home.gofferje.net/stefan (MO-FR 0700-2000 UTC, SA+SU 0900-2000 UTC)
sgofferj
 
Posts: 789
Joined: Mon Dec 05, 2011 5:13 pm
Location: EFTP
Callsign: OH-SW
Version: 3.1 GIT
OS: Opensuse

Re: Clouds online

Postby Hooray » Mon Mar 05, 2012 11:12 pm

Yes, you are re-iterating points that were made already previously.

The issue however is that Thorsten's weather system has an aircraft-centric focus and view that cannot be directly mapped to a client/server system.

Creating a client/server isn't complicated, but we would lose all the advantages of the current weather system - many parts would need to be reimplemented (i.e. designed from scratch), which simply isn't going to happen. We have exactly ONE person who entirely understands the system.

On the other hand, adding p2p communications to allow clients to exchange and synchronize some info, wouldn't be overly complicated.

Today, I already started playing around with Anders' multiplayer channels and it's actually pretty straightforward to serialize and deserialize Nasal variables (even hashes or vectors) to share some data.

At the moment, that's simply the most promising (and less complex) method.
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: Clouds online

Postby ckruetze » Mon Mar 05, 2012 11:54 pm

I can understand both sides here. But making everyone happy isn't possible right now.

So how about a compromise?

How about splitting it up into three tires? Presentation (rendering), Calculation and a transport layer in between.

The presentation of weather (not only rendering but also presenting it to the aircrafts eg wind speeds) shouldn't care at all where the calculations is done. But it should be possible to present any kind of clouds, rain, wind or whatever the weather guys can create now and in the future.


For now the calculations stay where they are.


The compromise would be the transport layer in between the two.

The simplest thing for it would be just to pass the calculations from the two layers - yes, that might be a little overhead for a client that doesn't care about multiplayer stuff.

An advanced version could pass some of the information between the clients for a shared version of the weather system. (Pull wind speed for tile X from client A, wind speed for tile Y from client B, the seed to randomize the clouds from client C and so on)

If there is a clear separation it should be possible to centralize the calculations to a server. The "easy" way is to run flightgear as the server. (Tell all the players to pull everything from client A). From there, who knows, maybe someone some day will improve it and add more complex stuff to the client or even split the weather part out into its own program.


I guess to summarize my post, making everybody happy right now isn't possible, but what could be possible is creating something that is extensible in the future.

Just my attempt to find a compromise
ckruetze
 
Posts: 33
Joined: Sat Jun 11, 2011 1:06 pm

PreviousNext

Return to Weather

Who is online

Users browsing this forum: No registered users and 0 guests