Board index FlightGear Development Effects and shaders

Revisiting clouds

An exciting "new" option in FlightGear, that includes reflections, lightmaps, the particle system etc.. A lot is yet to be discovered/implemented!

Re: Revisiting clouds

Postby Icecode GL » Mon Sep 17, 2018 8:31 pm

Noises are pseudorandom, they always return the same value for the same input. As long as all screens and all the instances connected to the network share the same weather parameters, the clouds will look the same in all of them.
Icecode GL
 
Posts: 525
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Revisiting clouds

Postby Thorsten » Tue Sep 18, 2018 4:17 am

I don't think noises are like that on graphics cards unfortunately - we have verified that the 3d Perlin noise used out for the terrain doesn't work out the same value for the same location on two different architectures, though the overall pattern is the same.
Thorsten
 
Posts: 10820
Joined: Mon Nov 02, 2009 8:33 am

Re: Revisiting clouds

Postby Icecode GL » Tue Sep 18, 2018 6:13 am

If there are precision issues, the random function could be modified to sample a previously generated random texture instead of the hash oneliner.

Does FG share clouds positions over multiplayer anyway? People could be using global/local weather, different scenarios etc.
Icecode GL
 
Posts: 525
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Revisiting clouds

Postby Thorsten » Tue Sep 18, 2018 6:18 am

Global weather works out like this (pseudo-random numbers on the CPU behave as you'd think they do), AW does not (the local instance does not have a dedicated pseudo-random generator, so it shares number sequences with whatever other Nasal code may be running)- since I'm not interested in MP or multiple monitors I don't have a test environment, I've sketched a while ago how to implement it there as well and offered to help anyone who wants to have a go, but so far no takers.

So the option is there conceptually, but it's not actually done.
Thorsten
 
Posts: 10820
Joined: Mon Nov 02, 2009 8:33 am

Re: Revisiting clouds

Postby erik » Tue Sep 18, 2018 7:08 am

Pseudo random would work well if you seed it with fixed, location specific, data like the lat and lon of the tile. This will work in all circumstances provided that the same pseudo random generator is used.

Erik
erik
 
Posts: 1520
Joined: Thu Nov 01, 2007 1:41 pm

Re: Revisiting clouds

Postby Icecode GL » Tue Sep 18, 2018 8:11 am

The pseudorandom generator is fed with the sample point world position.
Icecode GL
 
Posts: 525
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Revisiting clouds

Postby Thorsten » Tue Sep 18, 2018 11:47 am

Well, as I tried to explain earlier, actually this does not work as expected. We feed the world coordinate position into the 3d Perlin noise distributions painting the terrain, and we have observed that looking at a particular spot, what texture is actually painted there depends on the graphics card.

For the same graphics card, feeding the same number to the same generator always and unconditionally yields the same number - but for two different graphics cards, that number may not be the same.

The reason is presumably that GPUs not only operate with limited accuracy but also their drivers utilize all sorts of tricks to get answers fast and not necessarily accurate. They're made for creating visuals after all, not so much for solving maths. So IEEE accuracy standards is something you can't assume for a GPU.

(N.B.: I personally don't think that should keep us from anything - I'm just reporting my experiences since the topic came up)
Thorsten
 
Posts: 10820
Joined: Mon Nov 02, 2009 8:33 am

Re: Revisiting clouds

Postby erik » Tue Sep 18, 2018 12:18 pm

Do you think that implementing random ourselves might help here?
https://thebookofshaders.com/10/

I've seen this mentioned on one or two places as a source of randomness for shaders.

Erik
erik
 
Posts: 1520
Joined: Thu Nov 01, 2007 1:41 pm

Re: Revisiting clouds

Postby Thorsten » Tue Sep 18, 2018 12:19 pm

I have implemented my own GLSL random number generator... Maybe a different one has different properties - but I would not want to rely on GPUs doing math exactly. Generally they don't (I've seen the theme rather consistently over the years....)
Thorsten
 
Posts: 10820
Joined: Mon Nov 02, 2009 8:33 am

Re: Revisiting clouds

Postby erik » Tue Sep 18, 2018 12:20 pm

That's a pity, reliable pseudorandom numbers can be of great value.

Erik
erik
 
Posts: 1520
Joined: Thu Nov 01, 2007 1:41 pm

Re: Revisiting clouds

Postby Thorsten » Tue Sep 18, 2018 12:31 pm

Let me say this more generally - you only realize the value of IEEE standards when you no longer have them :mrgreen:
Thorsten
 
Posts: 10820
Joined: Mon Nov 02, 2009 8:33 am

Re: Revisiting clouds

Postby erik » Tue Sep 18, 2018 4:13 pm

After reading up on it a bit is looks like PC hardware should be IEEE compatible. OpenGL-ES is not. So lets pretend it is IEEE compatible and put the blame on improper drivers when somebody complains.

Erik
erik
 
Posts: 1520
Joined: Thu Nov 01, 2007 1:41 pm

Re: Revisiting clouds

Postby Icecode GL » Tue Sep 18, 2018 8:52 pm

I recently made a quick 1 hour flight in poor weather conditions and I had the opportunity to see some cloud formations from above for myself. To my surprise they are much "fluffier" and compact than I expected them to be. I think we can agree a continuous weather model really benefits this kind of clouds.

Image
(Sorry for the poor quality, I didn't plan on sharing it)

Perhaps it's too soon, since the very framework that allows this approach to work isn't even pushed upstream, but I'd like Thorsten to eventually enumerate all the things he wants to be able to control and how, so we can actually see if this technique is feasible/better/worse than the current one. In my opinion it has a lot of potential, but we'll see. I'd definitely want to explore this further.

I also want to note that both approaches aren't mutually exclusive, i.e. you can still have cirrus clouds or isolated clouds as billboarded textures. Special care has to be taken to avoid different looking clouds and non-uniform lighting though.
Icecode GL
 
Posts: 525
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Revisiting clouds

Postby Mihajlo » Tue Sep 18, 2018 10:24 pm

Yes, I've noticed that too. Even stratiform clouds usually have that fluffy,wrinkled look, or it can be more regular like a plowed soil with furrows because even they can have some vertical development although it's usually smaller than in convective clouds. In an unstable atmosphere for example you can even have considerable localized development in a layer, but it's also possible that a lower cloud layer (Cumulus for example) is protruding a higher layer. This is called a cloud forest.
Current stratiform clouds in FG are very flat compared to most situations I've seen in reality. Even in very stable weather a stratiform cloud is usually not entirely flat, but is uneven and has small bumps (protuberances). This is all variable and the size of these protuberances depends on atmospheric instability and other factors (like the height of inversion layer for example).
I understand that it's not easy to create good looking clouds that run fast and that current approach has limitations, which is likely one of the reasons stratiform clouds look like this. I'm hoping that with volumetric clouds this could improve like you say.
Here are some of my pictures showing this:
https://ibb.co/k3SxWe
https://ibb.co/niNsxK
https://ibb.co/nrPpcK
https://ibb.co/hiKY4z
https://ibb.co/bPJSge
Mihajlo
 
Posts: 53
Joined: Tue Aug 28, 2018 5:47 pm

Re: Revisiting clouds

Postby Thorsten » Wed Sep 19, 2018 10:39 am

I think we can agree a continuous weather model really benefits this kind of clouds.


(Trying to keep terminology clear: Please do not refer to this as a 'weather model' - it's just a way to render a cloud layer, clouds are only a small part of weather modeling).

For stratiform clouds, sub-dividing them into single 'blobs' as we currently do is definitely not particularly good - in fact, for those a meta-description 'draw me something roughly in that area' would work perfectly fine.

We had some nice complicated high undulatus patterns here yesterday which are probably on the other end of the scale - I (sort of) have a function to generate them, but it's complicated and I'd want this offline, noise really can't do this fast enough and they divide into single blobs naturally.

So generally I was thinking a descriptive texture by layer. The texture gives us four channels - so we use red to bias the noise function to 'force' clouds in certain spots, green to encode the difference in altitude to the layer altitude, which gives us two more channel to encode shape and density parameters.

If we want to generate a layer, we just color the red channel uniformly, if we want to have single clouds we write into certain spots only. The smallest clouds we need to define solidly are perhaps 50 m, so a 4096x4096 texture sheet could give us a 200x200 km area covered.

So rather than place a quad in the scene, the cloud generating function would simply write a red spot into the texture.

(Of course the texture somehow needs to move with the airplane, or a set of tiles of such textures needs to be instanced and deleted,... but I believe that can be made to work).
Thorsten
 
Posts: 10820
Joined: Mon Nov 02, 2009 8:33 am

PreviousNext

Return to Effects and shaders

Who is online

Users browsing this forum: No registered users and 1 guest