On Thu, Mar 31, 2011 at 8:42 AM, Thorsten Renk wrote: > Mixing is actually not a problem at all - I can just create 2 overlapping > cloudlets from 2 different texture sheets and place a third with dark > diffuse bottoms below - that doesn't need to be hard-coded as long as I > can ask for a texture sheet for each of the building blocks. > > 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. >> We could certainly add new parameters to the shader. I'd prefer to do >> that rather than generating a number of very similar shaders. > > Yes (in fact, if I would know how to do it from Nasal, I would have done > it with a single shader and parameters rather than designing 4 different > ones...). > > 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. >> which may be important if we have >> to track >> thousands of cloudlets, or the Nasal code just wants to create the cloud >> and then forget about it. > > Then we need to agree who gets to delete clouds. Right now, I keep some > memory of clouds until the tile is deleted even after removing them from > the scene, i.e. when you fly for 40 km and then turn by 180 degrees and > fly back, you get to see the same (modulo some evolution) clouds you had > when you left. (That's actually important if you pass a weathershed with > METAR on, see bad weather ahead and decide to turn back - without the > memory function, bad weather would appear no matter where you fly from th > eturning point till a new METAR report is received.). But that requires > that I keep track of what is in the scenery, what is still internally > represented within Nasal but deleted from the scenery and what has been > completely erased. > > So maybe there should then be a global switch to tell the system either 'I > want to create clouds, and I will monitor and delete them myself' or 'I > just want to create clouds and forget about them, you can delete them > yourself when I'm out of range'. Exactly what I was thinking myself :) 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. > >> I'm thinking the base API will be the lon/lat/alt of an individual >> cloudlet, possibly >> with an additional x/y offset to save lots of costly calculations when >> creating a >> series of cloudlets next to each other . > > Doesn't need an offset if you ask me - that is a natural part of how to > implement a placement call from Nasal, and that's not a speed bottleneck > at all. I had thought that converting accurately from lon/lat to cartesian coordinates was quite expensive when using the earth model we have. >> Certainly we could include horizontal movement on a per-layer basis, so >> you >> would add a series of clouds to a layer, which would move together. > > After some additional thought, movement *really* adds a can of worms. > > If you group weather into tiles (which, as in the case of terrain, I think > has to be done if it changes in space), then for a static observer the > windspeed determines the frequency of respanwing. So in theory, > high-altitude clouds moving at 50 kt would have to be respawned much more > frequently than low altitude clouds moving at 10 kt. > > Since for you each layer is translation invariant (i.e. will look the same > in space till new METAR comes in, you will not see its boundary) that's > not and issue - for me, that's a dramatic problem, because I'd have to > slice each tile vertically into layers, and generate new tiles for every > layer - which is a mess if clouds are also allowed to move in altitude. It > also would shear Cb towers apart... so then you'd need to prevent that... There's nothing to stop you from just putting all your low-level (or indeed high-level) clouds in a single layer. > It's also, quite possible, a waste of time, because usually I have to look > really, *really* hard to see cloud movement from the air, and it's just > not worth the trouble of doing it super-realistic. 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. > So I guess I would then propose to move all clouds with one globally > definable direction/speed and maybe make a movement of individual layers > optional. Seems pretty sensible. If the layers have a defined altitude, determining the speed of movement is pretty straightforward from the /environment stack. -Stuart ------------------------------------------------------------------------------ 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
