Re: [Flightgear-devel] Cloud interface from Nasal
So when wrap=true the core code will wrap the edges, shift the layer with altitude and move it with the wind With wrap=false, we'll just move it with the wind. OK? Sounds good to me. One function I had on my TODO list was something to return the cloud position in lat/lon. However, it's a bit tricky due to the current limitations in the command interface. Do you see any need for it? Not really. As I said, the whole cloud configuration exists Nasal-internally, and part of it (determined by view ranges) is also written as visible models into the scenery. But even without any clouds in the scenery, the code would still know where every cloud is over time, when to move it to a new altitude, when to forget it and so on. I never read the coordinates from the scenery models. So as long as I have a handle 'move cloud X' I wouldn't need a function 'get me coordinates of cloud X' since I know these already. Provided there's no bug which would make the drift speed different on the C++ and Nasal level of course :-) Also, Is there value in having the core code handling the vertical movement of clouds due to terrain, as a precursor to removing the wrap feature completely ? Where there is stable function that should apply equally to the existing global cloud coverage as much as the local weather I'm keen to migrate it into the core code. In this particular case, I suspect that terrain sampling can be done much more efficiently in the C++ code. I agree, but I stress again that the 2 or so geodinfo() calls per frame to get the terrain interaction of clouds are not an issue for performance. 400+ setprop() calls per frame to get models visually moving are - so it will be the visual cloud drift which makes all the performance gain. I would not hard-code the cloud-terrain interaction for the simple reason that we don't yet know how to do it properly (or a least, I don't know it). We might be thinking of clouds as objects drifting in a wind field, but they are not - they are regions where water vapour condenses, and these may move with the air or may not. Take Lenticularis clouds which illustrate the point nicely - they remain static in strong winds. And that's the whole problem of terrain interaction - I may just be able to figure out how the windfield interacts with an obstacle, but that's not the whole story. Even getting the vertical movement of air isn't a clear-cut issue by the way. The airstream would simply part for a solitary obstacle (like Mt. Rainier) and flow around, but it would be deflected upward when reaching a mountain range. In upward moving air at a barrier, layered clouds simply seem to remain more or less where they are - the fill the valleys, and the mountain ranges stick out of the layer. Clouds intersecting with the terrain become fog banks. Convective clouds seem to be able to follow to some degree - but they can be dissolved in upward moving air. To some degree, the cloud seems to decouple from the air movement. Or they can pile up at a ridge, and dissolve in the downstream on the other side. Usually, nice and crisp Cumulus do not intersect with the terrain unless it's *very* steep (the most spectacular failure of my current implementation - Cumuli sticking halfway out of gentle sloped terrain). But - the terrain itself may also force the creation of clouds which would not otherwise be there. If you move clouds against terrain obstacles, they tend to do all sorts of messy and complicated things, and I haven't really figured out what set of rules actually gives you a credible distribution in the mountains - especially when you move things around and allow clouds to form and dissolve. That's why I'd keep that part open (or at least optionally open) - you can of course hard-code my current algorithm, but I have to say honestly that in many situations in the mountains I am not happy with the results I get. Cheers, * Thorsten -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud interface from Nasal
On Tue, Apr 26, 2011 at 10:42 AM, thorsten.i.renk wrote: Now, the placed 3D clouds are wrapped, just like the global clouds, so if you travel far enough (50km), you'll come across the same cloud again. For local weather, that probably isn't what we want. So, I'm thinking of adding a new wrap property on the cloud layer indicating whether the 3D clouds should be wrapped. Yes, that would be useful - currently in Local Weather the same cloud can (theoretically) be in the scenery for 110 km, so a wrapping every 50 km would be problematic. The question is, should this also affect other clouds movement, specifically changes to the layer altitude which current moves all the 3D clouds as well, and cloud movement due to wind? At least my code is taking care of all these issues, so from my perspective I'd like to have a switch to eliminate any wrapping and global shifts in layer altitude (since the implied infinity of the layer is contrary to the 'local' in 'Local Weather' :-) ). So when wrap=true the core code will wrap the edges, shift the layer with altitude and move it with the wind With wrap=false, we'll just move it with the wind. OK? Basically, I'm keeping an Nasal internal record of where the cloud is when it moves even now, since it's more efficient to compute position updates from the record and only write into the tree rather than read the position from the tree, recompute and write back. I also have, thanks to terrain presampling, a rough internal representation of how the terrain looks where. So I would know when to remove and respawn clouds even when I use your code to move them with the wind. You'll want to move the cloud rather than deleting and re-creating as the cloud shape will be different (the sprite distribution and texture coords are random). One function I had on my TODO list was something to return the cloud position in lat/lon. However, it's a bit tricky due to the current limitations in the command interface. Do you see any need for it? Also, Is there value in having the core code handling the vertical movement of clouds due to terrain, as a precursor to removing the wrap feature completely ? Where there is stable function that should apply equally to the existing global cloud coverage as much as the local weather I'm keen to migrate it into the core code. In this particular case, I suspect that terrain sampling can be done much more efficiently in the C++ code. The most important thing in your code for my purpose actually is the cloud movement, since that is presumably much more efficient than doing hundreds of setprop() calls per frame from Nasal. It makes sense to be able to switch that off, because I suspect it also causes some performance degradation when run by the core, but to my mind it makes sense to be able to switch that off separately from wrapping, since unlike the other two features it doesn't make any 'global' assumption for the layer. I'll re-read my code, but I'm pretty sure the perf implications are negligible for wind movement as we just move a single top level transform. P.S.: Since I'm keen on backward compatibility - is there any easy way to detect if the running binary has the new functionality? I know how to test for properties, but to call a function and decide based on the error it may or may not create is dangerous since the error message tends to alarm users... I haven't checked what the effect of make an unknown fgcommand() call is, but I'm not aware of any other method to check. Do we have a version property in the tree? It should be pretty trivial to add. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud interface from Nasal
One function I had on my TODO list was something to return the cloud position in lat/lon. However, it's a bit tricky due to the current limitations in the command interface. Do you see any need for it? Weather Radar? -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud interface from Nasal
On Tue, Apr 26, 2011 at 3:45 PM, Heiko Schulz wrote: One function I had on my TODO list was something to return the cloud position in lat/lon. However, it's a bit tricky due to the current limitations in the command interface. Do you see any need for it? Weather Radar? Good point. The information is easily available in C++, so I will make sure it is available there at least, along with some sensible method to iterate over the clouds. However, a Nasal (fgcommand) interface is a lot more tricky, and I'd like to avoid that if possible. -Stuart -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud interface from Nasal
I've just committed (thanks to Torsten) an update to the 3D clouds. As well as fixing a bug that caused the cloud density to be significantly less than it should have been, the global 3D clouds now move with the wind, which looks rather nice IMO. This update also adds a couple of new commands that can be called from Nasal using fgcommand() - add-cloud, move-cloud, del-cloud. This allows you to create individual clouds using the same technique and parameters as the global clouds. Those interested may want to look at the README.3DClouds. Please let me know if you notice any performance degradation. On my system I don't notice any difference, and the underlying shaders have not been changed, so I'm hopeful that any perf impact will be negligible. Now, the placed 3D clouds are wrapped, just like the global clouds, so if you travel far enough (50km), you'll come across the same cloud again. For local weather, that probably isn't what we want. So, I'm thinking of adding a new wrap property on the cloud layer indicating whether the 3D clouds should be wrapped. The question is, should this also affect other clouds movement, specifically changes to the layer altitude which current moves all the 3D clouds as well, and cloud movement due to wind? Discuss :) -Stuart -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud interface from Nasal
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
Re: [Flightgear-devel] Cloud interface from Nasal
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. What would it need, and what can it handle? It's relatively easy to pass a list of cloudlet coordinates to any system who wants it - but that means since O(5000) cloudlets can be in the scenery, that the radar should be able to handle that number - if it creates a dot per coordinate pair, then that could be a bit much to ask... On the other hand, it is in principle possible to create a meta-description of what is created inside the cloud-generating algorithm - but then I'd need to know what the weather radar likes to know in order to show something useful. 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
Re: [Flightgear-devel] Cloud interface from Nasal
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
Re: [Flightgear-devel] Cloud interface from Nasal
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
Re: [Flightgear-devel] Cloud interface from Nasal
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
Re: [Flightgear-devel] Cloud interface from Nasal
On Wed, Mar 30, 2011 at 12:56 PM, Thorsten Renk wrote: To follow up Stuart, here are some of my thoughts: Thanks. Comments below, significantly colored by what I've managed to implement in a couple of hours of hacking here :) snip I) Basic building blocks - texture sheets I assume the basic strategy is to use the rotation in the existing shaders in all cases, i.e. a texture sheet is brought into the scenery which always is rotated to be perpendicular to the view direction. 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. As it happens, I've already got this approach working, along with a Nasal interface and a dynamic (single level for the moment) quad tree. It's quite neat. What would be useful to specify then is 1) texture type 2) shader type and 3) a basic size, perhaps also 4) the amount of random size variation and 5) if a random rotation around the view axis can be done. I'm currently composing clouds by mixing different texture types, for instance a Cumulus cloud is a mixture of feathery textures, mature bulky Cumulus textures and dark diffuse bottom textures - other clouds use other mixtures, and by changing the mixture, one can nicely model the impact of the amount of turbulence in the air. That explains why control over texture type is useful. 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. I found that texture sheets can be reused: One texture sheet for instance is used for Altocumuli by using a very light shader and scaling each x,y,z with 0.25. The same sheet produces good stratiform clouds by scaling the z-axis only with 0.4 and using a darker shader to simulate thicker clouds. Thus, it pays off to specify shader (or shader parameters) independent of texture sheet. We could certainly add new parameters to the shader. I'd prefer to do that rather than generating a number of very similar shaders. Also, note that there is control over the shading of the cloud in the existing shader, so you can make the bottom of the cloud darker that the top irrespective of the texture. The basic size is needed to determine how large a cloud should be. To induce more variation, I always thought it would be useful to let textures randomly vary +- 30% in size, and for those textures which have to clear up-down distinction also to allow a random rotation around the axis perpendicular to the surface. Not essential, but maybe useful. I've already got support for random variation in texture size. I did think about allowing additional rotation but never implemented it - should be pretty straightforward. II) Basic placement I understand that the default clouds are currently built up from filled boxes. In Local Weather, I use a large variety of techniques to place clouds, e.g. stacked cylinders, randomized trapezoid grids, Markov-chains, two-level core-periphery clustering, Monte Carlo terrain interaction,... in fact, I'm inventing a new method every month or so. But I think it's most useful to keep the exotic stuff in Nasal, and a basic box interface would reduce the overhead of writing into the property tree significantly. I'm thinking of not tying the cloud placement and parameters into the the property tree at all. So while the Nasal interface would use a property hash to define the initial cloud position, the cloud position etc. isn't tied into the property tree. 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. Of course, this doesn't stop the client from using a property tree to keep track of position etc. but it does mean it's optional, 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. So the parameters which I think would be useful then
