> I've got a patch to do this that I'll submit shortly. the parameter is > <height-map-texture>, and it defaults to false. > > I'm also taking the opportunity to change some of the defaults, so that > the > max-[cloud|sprite]-[width|height]-m> parameters default to 1.5x the min > equivalent. > > I suspect it won't make much difference to your clouds, as I expect > you'll > want to explicitly set all the parameters, but it should mean the > defaults > make more sense.
Thanks. I have to take a look at the max-cloud-height-m - currently I'm only setting min-cloud-height-m for the following reason: It seems to me that the cloud *center* gets placed at (alt-ft + layer_altitude), such that (0.5 * cloud-height-m) is below the specified altitude and (0.5 * cloud-height-m) is above. For small sized clouds, that's not an issue, because the layer comes out right anyway. Now, at least convective layers in flat terrain have a relatively sharp altitude for the cloudbase - even if cloud tops can vary by a large margin, it simply doesn't do to have a cloudbase 500 m lower than for the surrounding clouds (for a cloud top, that's quite okay). It took my 30 minutes yesterday to find out that this was the trouble with my developing Cb clouds - so I fixed cloud-height-m to not have random variation and stacked the cloudlets using my routines such that the cloudbase is constant but the top of the layer may vary. Basically, in the current setup using random cloud-height-m between min and max values, it's impossible to get a well-defined cloud base altitude, because I can't know the random value for the height up front. I don't know if it makes sense to alter it though - for other layers, it may be useful to place the center at given altitude... I also came across a second issue (sorry, they just keep coming...) Large cloudlets tend to vanish from view at the edges of the view field. I suspect I understand why: You must generate the texture sheet somehow in the scenery with some orientation and size. The shader code then grabs it, resizes it using wScale and hScale to what you need and rotates it. Now, if wScale > 1, it may easily occur that the true coordiantes (i.e. before rotation and scaling) are outside the field of view, while the apparent coordinates (i.e. after rotation and scaling by the shader) are in the field of view - but if the true coordinates are outside, the shader code is never called at all, and so the object suddenly vanishes. Basically, the base texture must be generated so large that wScale < 1 is guaranteed to get rid of the problem (I had some models at 4 times design size, to be resized by the shader with a factor 0.25 to get rid of the problem). I suspect you should be able to generate the base texture with max-sprite-width/height-m rather than a constant and then scale down a bit. The trouble is that if the base scale is too large, the shader code needs to run for a lot of objects which are not inside the visual field, so wScale <<1 (~O(0.01) is also something one'd like to avoid. Anyway, that's my diagnosis of what I'm seeing... I hope there's a way to fix that, for Cb clouds I can't simply go to small enough textures such that these problems don't occur... Cheers, * Thorsten ------------------------------------------------------------------------------ FREE DOWNLOAD - uberSVN with Social Coding for Subversion. Subversion made easy with a complete admin console. Easy to use, easy to manage, easy to install, easy to extend. Get a Free download of the new open ALM Subversion platform now. http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
