This is basically an answer to Vivian who asked me why my Cumulus layers look like stacks of cardboard rather than smooth volumetric objects like Stuart's 3d clouds - I thought that maybe some others are also interested in some background info, and maybe someone even has a new idea.
Basically, 3d cloud rendering works between 2 limits: Billboard: Here a single cloud photograph is projected into the scenery. Looks like an actual cloud from large distance, looks highly artifical from close up, all the structure information of the cloud is encoded in the texture. Volumetric: Many small-sized 'particles' are brought into the scenery, the sum of which forms the cloud. Here the cloud structure is encoded in the distribution function of 'particles' which is *much* harder to get right, as a result these clouds look good from up close, but not really from far away. Usually one uses a mixture between the two, say Stuart's default setting uses 20 texture sheets O(200 m) in a 500 m cloud - that's not really volumetric, but not really billboard either. First issue: Cloud size distribution. It's not enough to generate one realistic looking cloud and randomly distribute copies of it across the sky - the repetition of clouds of the same size and shape looks very artificial. A real image of an afternoon Cu layer shows that the sky contains small-sized whisps O(100 m) up to well-developed towering cloud masses O(5000 m) (and may even contain Cb O(20 km)). The underlying reason is that Cu layers are a turbulent phenomenon, and turbulence mixes all size scales in the problem. Thus, to get realistic layers, one need to reproduce the size variation. Second issue: Volume grows like L^3. If my basic 500 m cloud looks good with 20 sprites O(200 m), and I want to use the same technique to render 5 km cloud masses, I need 10^3 * 20, i.e. 20.000 sprites _per cloud_ (1.280.000 sprites for a Cb tower) to get the same effect. Short of waiting for a next-to-next generation GPU, that's simply out of the question. A technique that produces very nice small-scale clouds simply doesn't scale to large clouds. The only way out is: As cloud sizes grow, so must sprite sizes such that #sprites/cloud is approximately a constant. That inevitably means loss of detail. Third issue: Shape distribution. Cumulus clouds have different shape, often correlated with size. Small clouds are feathery whisps, large clouds have well-defined cauliflower-like tops with sharp boundaries between opaque cloud and sky. If that is to be right, the texture mixture needs to be changed with the texture size. As the clouds become more opaque, largely transparent feathered textures need to be changed against largely opaque cauliflower-textures. Taking issues #2 and #3 together, a large Cu cloud of 3 km size can only reasonably be built from O(10-50) sprites with O(1000 m) sprite size with rather opaque textures. Inevitably, that tends to look like a stack of cardboard, because... that's largely what it is. For small clouds, the fact that the textures and resulting clouds are rather transparent and have no well defined boundaries hides the fact very well that one is looking at a stack of sprites. For large opaque clouds, that illusion unfortunately works not so well. The obvious solution is to move towards a volumetric rendering limit, i.e. get the same opacity by using more sprites which are individually less opaque - but that limit runs into severe performance problems with a third power, see above. Ultimately, it's the inability of the GPU to render millions of sprites which prevents large clouds from looking as spectacular as small clouds from close up, given the techniques we're using. I haven't seen any definite answer to that problem anywhere - maybe there is something I'm overlooking, but as far as I've been able to work out these are generic reasons why large clouds can't look as good as small ones. * Thorsten ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
