>> Since my basic Cu texture image is often 1024x512 (sometimes larger), >> sorting through the y-coordinate of the texture sheet isn't an option >> unless you use 4096x4096 sheets - which may not be so nice. (?) Well, I >> guess that depends on the texture cache which you seem to have anyway. > > The textures don't have to have the same x & y coordinate dimensions, so > you could have 1x2 texture sheet that was 1024x1024.
Right... but > To match the existing global 3D clouds, it would be easier for > each "cloudlet" (cluster of sprites representing a cloud puff) to > use a single texture sheet containing multiple sprite textures. So then I'd be creating a cloudlet from a sheet with 2 textures - one for the top, one for the bottom, and that would mean that every cloud looks the same :-) So I have to 'mix' the clouds by overlapping cloudlets drawing from different sheets myself if the sheet is too small to offer substantial variation, that's the constraint. >> If you provide control over cloudlet size as above, I think the main new >> parameter needed is the amount of rescaling in the vertical axis to >> squash >> cloudlets into startiform shapes. > > We've got that control already - you can define the size of sprites in > both x and y axis. Yes - before rotation. You have wScale and hScale as parameters in gl_Position = vec4(0.0, 0.0, 0.0, 1.0); gl_Position.xyz = gl_Vertex.x * u ; gl_Position.xyz += gl_Vertex.y * r * wScale; gl_Position.xyz += gl_Vertex.z * w * hScale; gl_Position.xyz += gl_Color.xyz; If you select hScale to be 0.5 and look at the texture sheet from the same altitude, you see a rectangle with the width 2 times the height. If you look at that texture from straight above, you see the same rectangle, just rotated to face you. The vertical squashing I mean is adding the line gl_Position.z = gl_Position.z * vScale; If wScale = hScale = 1 and vScale is 0.5, you see a rectangle with width 2 times height when level with the cloud, but you see a square when looking straight down - exactly the properties you need to build a layer efficiently. > In fact, I think we probably want this control on a per-layer basis. In > one > case (used by the global weather system at present), the FG code will > manage the clouds, repositioning them to create an illusion of complete > coverage. In the other, the Nasal code is responsible for moving and > deleting > clouds. You mean you simply move them? I've never thought about doing that..., but in hindsight, it seems fairly obvious to do when you want to create a continuous layer... Maybe that's the solution to my altitude differential wind problem... (?) > I had thought that converting accurately from lon/lat to cartesian > coordinates was quite expensive when using the earth model we have. It would be if I would use the earth model in computations - but since the distances involved are small, I compute everything in local Cartesian coordinates and don't bother about misplacing a cloud by a meter or so :-) > That's because when you are in the air you are generally moving in the > same airmass as the clouds themselves, so they appear static. Well, no, because I look of course for the relative movement of the terrain underneath seemlingly static clouds - that's where the effect is apparent of course. In an ASK-13 with 80 km/h in 40 km/h winds, you can see this very impressively, you fly between a seemingly static set of clouds, and the terrain just keeps rolling below you. But most planes are just too fast - when I fly an approach in the Bravo for instance, I have about 100 kt on final - in 30 kt (!) crosswinds, the angular deflection of my course is just 17 degrees. How fast I see the terrain moving is then dependent on the distance to my reference point - if I am close to the ground, the apparent movement (=how fast terrain pixels appear to move sideways) is large, at 30.000 ft it is negligible. Okay, one can just about spot that above ground if one as a point of reference such as the runway. But for most of the flight, say from 12.000 ft, when I have a GS of 280 kt, the angular deflection is a mere 6 degrees and I don't have a clear reference point - it makes no visual difference to switch cloud movement off. Under most conditions, winds are way smaller and you don't usually get 30 kt crosswinds in an approach (that'd not be a smart approach direction...) - thus you can't really see it. Works really best for gliders or single-prop planes like the Cessna-172 - even the SenecaII which I use often is a bit on the fast side. Cheers, * Thorsten ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
