Thorsten wrote > > > Yes, in fact, my basic strategy was to use the existing default 3D cloud > > code almost untouched from the perspective of creating a set of sprites > > that are built up into a cloudlet. So, you can define (amongst other > > things) > > > > - the texture sheet to use, > > - the number of sprites, > > - min/max width and height of each sprite, > > - the width and height of the distorted sphere to place the sprites on. > > - shading of the bottom of the cloudlet > > - lat/lon/alt of the cloudlet. > > > > I'm sure you are very familiar with the capabilities and limitations of > > that approach, but it would be worth having a look at the > README.3dclouds > > so see the API available. Note that I'm just considering expositng the > > bottom level cloudlet, so building them up onto multi-part clouds and > > boxes of clouds will be done externally. > > Sounds good to me - that is basically the functionality I was describing > at the level of the box where you can specify how many cloudlets you place > - in your terminology, replace 'box' by 'distorted sphere' and 'cloudlet' > by 'sprite', but no matter, these are details. > > > > > 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. However, there is control over the > > uv coordinates of each sprite, where the x-axis is random, but the > y-axis is > > controlled by the vertical location of the sprite. So you can create a > > cloudlet with a mixture of textures, and have a fair bit of control of > > those textures. > > 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. > > > 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. > > > Instead I'm thinking of the creatCloud() call returning some correlator > > that can be used by the Nasal client to reposition or delete > > the cloudlet. > > That's even better, because that gets rid of all the time constraints in > writing properties into the tree, so the Nasal cloud object can just store > the identifier returned upon creation, and then use that to reference the > cloud in the future. > > > 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'. > > > 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. > > > 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... > > 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. > > Basically I see two solutions: > > 1) (implemented in Local Weather) - all clouds in a tile move visually > with the same speed, regardless of what the actual windfield at their > altitude/position may be. In practice, I've seen offsets of ~5 kt and 30 > degrees between actual windspeed at a position and cloud movement, more at > high altitudes (where you can't gauge any movement anyway). Difficult to > see, so possibly okay. > > 2) (possibly more elegant, I just came up with it later after I > implemented all) - all clouds everywhere move with the current windspeed > at your position. Then the clouds in your vicinity (where it matters) will > appear to have the right movement, whereas faraway clouds will not move > with the right windspeed - which you have no way of knowing, because you > aren't actually there. > > Maybe 2) would be best to implement - the local wind at your current > position is available in /environment/ anyway. Well, maybe boundary layer > effects should not enter 2) - so you would need to get the wind from some > other interface where the boundary layer is taken out, but that's easily > done. > > 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. > > > I wonder if the terrain elevation code would be any faster in the C- > code. > > Is the movement of clouds to follow terrain a straightforward model? e.g > > you could mark a layer as following the terrain, and then apply some > > algorithm > > to determine cloud vertical movement as it travels? > > For a description of what it does, see appendix A of > > http://www.phy.duke.edu/~trenk/files/README.local_weather.html > > Basically, given the general terrain sampling data and the current > altitude of the cloud above ground, the algorithm determines at what > altitude the cloud should be. > > In my view, it's not worth hard-coding that, because the target altitude > computation itself takes less than half a percent of the effort to > actually move the cloud there. > > The reason is that this can really be a slow task - you really need to > inspect clouds only every 30-60 seconds, have a look at the terrain > underneath, and see if you need to reassess the lifetime of the cloud (say > when it drifted over water) or if you need to adjust the altitude. As long > as I can pass the actual work of animating how the cloud changes altitude > to a fast bit of code, everything is fine. > > It's also something I'd like to keep in Nasal because I think this would > need some more tuning, development and modelling for layered clouds (I'm > not always happy with their behaviour...). > > > In the plib days where we just had Cu clouds, they were faded in and out > > to represent the Cus forming and dissipating. > > I have a more complex model in mind where you start with feathery whisps, > and as you progress in the lifecycle call functions like 'split' (create > an additional cloudlet nearby) or 'evolve' (remove the feathry cloudlet, > replace it by a bulky one) to be closer to what you see in nature. In > principle, I have almost all the code in place to do it, but it would be > so much nicer if one could fade things in and out instead of just > loading/unloading them. > > It also shouldn't be random, since one important constaint is that > thermals need to move/evolve in sync with their cap clouds - so the cloud > state really needs to be determined by the same bit of code that > administers the thermals or other effect volumes. > > > Well, we'll get that for free by using the default cloud code :) > > Yes, in case I've never told you, I'm very much a fan of your shader > code... >
Which reminds me, a long time ago (in the cutover from PLIB to OSG) we lost the ability to detect clouds using the Weather Radar. It would be very nice to restore that function. The code still exists, it's just the 3d clouds are no longer accessible. Vivian ------------------------------------------------------------------------------ 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
