A local weather system (v1.4 available)

[erik]

Looking at this I have the feeling that the use of ac3d models for a cloudlets might me a reason for the slow loading of the clouds. It might be a better idea to store the various types of cloudlets (name, relative offset to the base and texture type) in an XML file and use that to generate them on the fly.

If that is possible from Nasal, it would be good if someone could explain to me how. If that is possible from C++ only, I'd need someone to help me by implementing a suitable interface. It's well possible that this is the cause, but I don't really see much I can do about it.

I would be highly surprised if it could be done from Nasal, but then again; I've been surprised about Nasal before.

In theory it should be possible to adjust the fog density based on the view direction, but I'm not sure if that will give the desired result.

It's certainly better than what I use now, and it isn't difficult to get the trigonometry right to set the right amount of fog as a function of angle, given altitude and haze layer thickness. How would one go about setting that?

I would have to look into that since I don't think there's a property for fog density at the moment. But I'm busy with other work at the moment so it might take a few days.

Erik

[erik]

I just remembered the z/Z key to increase and decrease the visibility. It doesn't use a property but an internal-command.
This command sets /environment/visibility-m and calls fgDefaultWeatherValue("visibility-m", new_visibility);

Digging some deeper this function sets the visibility-m property for all instances of '/environment/config/boundary' and '/environment/config/aloft'

After this the "environment" is reinitialized.

I'm not yet sure how this all affects the visibility of the fog in the scenery though.

Erik

[ot-666]

Hello Thorsten

I just tried your new version after my GIT pull from yesterday with binaries from fred (01.08.2010) and figured that it sends my system
(win7 64bit / 8gb ram / i7-860 / ati hd5850 ccc10.4 / FGFS GIT 64bit) down to 5 – 8 fps.

The last version at least gave me around 12 – 20 frames with the most of the weather systems and was still flyable.
My investigation shows that the normal fgfs 3d clouds produce a gpu load of just 25% (Innsbruck custom scenerywith around 30 – 50 fps), but as soon I enable your weather the gpu load drops to 0%.

The clear clouds button in your weather dialog not only clears the clouds but give me a black fgfs window and 2 sec later a fgfs crash.

The clouds look very nice but seem to be not working with ATI. Maybe this info is useful in any way to get it back working for ati.

(I only wonder why fgfs only uses 25% of the gpu anyway? Maybe more of the nice shader stuff is dropped on the cpu since I use a ATI.)

Best regards, Oliver

[Thorsten]

The last version at least gave me around 12 – 20 frames with the most of the weather systems and was still flyable.

Switch dynamics off and you are back to what you had previously (actually even a bit faster). Moving clouds around burns a lot of framerate.

The clear clouds button in your weather dialog not only clears the clouds but give me a black fgfs window and 2 sec later a fgfs crash.

*is puzzled* I know what most likely causes the crash (all weather stations are deleted in the interpolation loop while the loop is still running, then the interpolation loop computes a NAN for the visibility for lack of data, writes that NAN into the property tree as visibility and the screen blacks out).

I just don't know how it can happen - I had this back in v0.5, added a fix to the code to prevent this from happening, and haven't had it ever since. Other people also have reported 'Clear clouds' working properly. In what state was the system before that happened, i.e. what menu and menu options did you choose to generate clouds, was it the first try to delete or did you try other things before? Any errors in the console? Is the problem reproducable? I am still tracking bugs which arise due to the complexity of the task scheduling - basically, dependent on options, there are at least three distinct sequences in which events can potentially take place, and some of them generate unexpected problems.

but as soon I enable your weather the gpu load drops to 0%

While they look fairly similar, I think internally the standard 3d clouds and my 3d clouds are rather different bits of technology.

The clouds look very nice but seem to be not working with ATI. Maybe this info is useful in any way to get it back working for ati.

I really think what burns your framerate is moving the clouds - which is not done by the graphics card. So please have a try with the dynamics switch.

[Thorsten]

Adding some Cirrocumulus sheets (deformed 2 dim layers to give them some 3d appearance) from my collection of high resolution sky pictures. These add some sights which are plainly impossible to get with 3d cloudlets (the amount of CPU time is prohibitive... and the structure and size distribution of cloudlets is almost impossible to mock up by hand - one would need a few hundred distinct models and O(5000) cloudlets which is about a factor 20 more than we realistically can have).

If it works, the effect is very nice and impressive:



However, this persistent bug when the view goes through two sheets under a certain angle is rather annoying:



I wonder in what subsystem it actually resides - would it be down on the OSG level? Right now, I'm trying to avoid it by optimizing placement such that the situation is unlikely to occur, but it's actually the most restricting bug I have ever seen for weather purposes. Whole families of cloud illusion generating algorithms which are fine in theory don't actually work because they generate the above situation.

[Thorsten]

Yet another progress report - I'm currently trying to trace some rather elusive bugs which lead to the tile type information being lost - if that happens, weather generation terminates

I was able to catch the problem and prevent it from doing any harm, but I'm still trying to understand what the cause is and fix that. At this point, I suspect improper timing of different tasks, leading to overlapping events. I have tried to re-structure the flow of events a bit, hopefully that fixes the issue, but I need to conduct further long-range flight tests... so, new clouds and cloud configurations, but no genuinely new features yet before the old code is really performing well.

[Thorsten]

I have just successfully tested a scheme to buffer clouds which are out of visual range when a tile is spawned in a Nasal array instead of writing them into the scenery. This should ease the workload when generating a new tile as well as during flight and when unloading a tile. The reason is that Nasal arrays are processed way faster than property tree information or scenery. I've observed that when a tile is spawned, more than half of the cloud count ends up in the buffer, and although this is gradually written into the scenery, the buffer seems to hold on average 30% of the clouds currently generated. I have yet to test the actual performance gain aside from creating or deleting tiles. In principle, that gain can be kept, or be used to extend the range at which new tiles are loaded (if they are sufficiently far away, they will end up in the buffer anyway) and thus to get rid of situations where one observes empty sky ahead before a tile is created.

Another useful addition: terrain presampling now checks the framerate and sacrifices accuracy for speed if the framerate is running low.

[Avionyx]

Sounds great Thorsten and thanks for the updates, sorry I haven't been following this as closesly recently, work has been very busy, but its wonderful to pop in here and see all the wonderful work you are doing!

Alex

[Thorsten]

The new cloud management scheme exceeds my wildest expectations. It seems it almost doubles the available framerate.

I have test-flown the F-14b over Las Vegas with clouds generated out to 45 km distance (the layered cloud sheets are sometimes visible up to 70 km), with framerates between 30 and 40 fps (dynamics off). With agressive buffering of rear clouds, the viewing distance could be extended even further - the problem becomes now that terrain sampling doesn't work if the terrain is not yet loaded.

I'm usually not given to exaggerations - but this seems really a major breakthrough...

[Hooray]

the problem becomes now that terrain sampling doesn't work if the terrain is not yet loaded.

To me, that seems to make sense actually. For a Nasal based solution, I would suggest to (yet again) overload the geodinfo() API and provide support for an optional parameter to tell FlightGear to load tiles that are not yet loaded, i.e. "on demand" - just for querying the terrain.

On the other hand, I have personally not yet again looked into improving the Nasal interface, mostly due to the ongoing work to provide a C++ based terrain sampling mechanism, which would seem to supersede the Nasal based approach.

PS: You may want to check your PM box, I suppose it's full(?): I sent you a PM a couple of days ago, the forum is set up to allow you to keep only 50 PMs in your inbox, you cannot receive new PMs, until you delete some of the old ones - I noticed that myself some time ago, messages are then put "on hold".

[Thorsten]

Well, it's sort of an exotic problem if the cloud visibility range can be extended to 70 or even 100 km... even 45 km makes for a very stunning visual experience - I tried it in the Caribbean approaching the islands, and they appear beautifully dotted with clouds form 20.000 ft.

My PM box isn't full - if you mean your question if I could repost your GIT instructions, that's here. If it's about something else, then there appears to be a bug.

[Thorsten]

Here's a visual comparison what it means to have clouds out to 45 km - TNCM seen from airliner altitude (I took both shots from 27.000 ft, about 19 miles out from TNCM, visibility is about 55 km).

Standard 3d cloud layer, extending 20 km (as far as it gets) - uniform cloud density in the layer, we get 94 fps:



Cold sector tile, 3d cloud visibility extending 45 km (the Cirrocumulus in the upper left is probably as far as 70 or 80 km out) - Cumulus clouds can be seen as far as Anguilla, clouds trace the landmass of the islands, clouds get darker bottom shading, we get 86 fps:



For high altitude flights, the visibility range makes a huge difference.

Anyway - I'll have to conduct a few more tests in order to deliver a moderately bug-free product, then write some additional documentation, but I expect to release this by next week.

[Johan G]

Stunning comparison

[ot-666]

Way more realistic... and the + in framerate is a big progress.

Cheers, Oliver

[Thorsten]

Since it didn't do anything weird for the last 3 days, I put the latest version online.

The main novel features in comparison with v0.81 are:

* significant improvement in performance due to new cloud buffering scheme
* run-time configurable cloud view ranges up to 45 km
* run-time configurable tile creation range and dynamical cloud range
* improvements in texture quality and some new cloud types