float height = min_height + sg_random() * (max_height - min_height) - min_sprite_height;
> 1) If there is a lot of variability between the > min-sprite-[height|width] and max-sprite-[height|width] > the cloud will go outside its bounds. So we aren't completely limiting > the cloud width/height. Is there any benefit to limiting a cloud exactly into height/width? Of course, when you place the sprite centers onto a given altitude, you have to shift a layer by half the sprite height upward to get the lower layer edge to given altitude... I don't mind either way, as long as I understand what controls what. > 2) I think the z scaling parameter needs to be included in the height > calculation. Possibly as a multiplier > in on the "- min_sprite_height" term? Yes, that should be float height = min_height + sg_random() * (max_height - min_height) - z_scale * min_sprite_height; then. I've been thinking that maybe it'd be a good idea to pass 'cloud_height' to the shader in addition to 'top_shade' as optional parameters and decouple sprite distribution from shading somewhat. The reasons are: * I create e.g. Cb clouds as a stack of layers of different diameter and texture http://www.phy.duke.edu/~trenk/files/clouds-tropical02.jpg Now, the current shader code assumes that the cloud top is always white, but 'the cloud' for the shader would be just the lowest layer of 'the Cb cloud' in the scene, so while the shader thinks the cloud ends at 5000 ft, it actually extends all the way up to 35.000 ft in the scene. If the shader colors the top of each layer in white, one gets a zebra-coloured cloud - maybe not so useful :-) (as actually visible in the pic - though de-emphasized since I compensated by using grey textures for the lower layers). * Another thing discussed in the Forum is inter-cloud shading - suppose there is a thin 8/8 layer above Cumulus clouds - then the tops of the Cu clouds wouldn't actually be white in the first place. While I can't really do light ray intersection tests to determine the shading on a per-cloud basis, I have the light propagation info of the gross layer structure available and could use it to shade cloud tops in that situation as well. * I still have problems with antishading when cloud_height is about 1.4* max_sprite_height - it only goes away for cloud_height >> max_sprite_height. Since the old setup with a hard-coded value of cloud_height in the shader essentially works, I'm hoping that the ability to actually pass an optional value to the shader would help. But maybe there is a better way to address the issues... Cheers, * Thorsten ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
