Re: [Flightgear-devel] Weather issues for 2.6
We are still looking into this one. At first glance there doesn't seem to be any good reason for the wind not being honoured. The overcast is a problem of interpreting different implementations between Global and Local weather. Now you are back operational we will try to come up with a suggestion in the next couple of days Seems you are currently referencing /environment/sea/wind-from-east-fps for the actual shader work(?) which seem to be tied to the global weather boundary layer. Problem is, I can't set that directly, but I wrote a hack yesterday to write into /environment/config/boundary/entry[0]/wind-from-heading-deg , and that does the trick quite nicely (see http://www.flightgear.org/forums/viewtopic.php?f=19t=9446p=144955#p144955 for screenshots) But I'd much prefer a different interface - writing into global weather config isn't something I should be doing - so this was just a test for me to see how it looks like. A couple of observations: * I've been unable to work out what triggers the color of the water. In some cases I had overcast and reduced lighting set and got green water, in others it went grey (I haven't looked into the shader code though). * I have an implementation of gusty winds which I tried. My code actually provided the mean wind (i.e. before the gust correction) to /environment/config/boundary/entry[0]/ , but set the actual wind felt by the aircraft after gusts. Nevertheless, each gust triggered a redraw of the wave pattern, so that's something we'd perhaps rather avoid. It seems a change in wind triggers new parameters being passed to the shader and a redrawing, but it doesn't actually take the wind parameters (?) - something is confusing me. Anyway, an interface should be robust against gusts and ask for an average rather than the actual per-frame winds. * The wake effect of the carrier is also something that is drawn before the cloud - you can see it through an overcast layer, which makes the carrier unusually easy to find in bad weather. We had some problems with adapting the ground haze shader to the new, universal fog scheme. At the moment, our results are unacceptable for release. We are not clear at this stage if we can do it at all, and we are unlikely to come up with a tested and tuned solution by the 17th. We will continue to work on it in the next few days to come up with a better informed decision on the way ahead. Okay. Is there something I should still be doing? I'll try to rebase my haze shader branch with the recent developments to see if I can keep it alive. Maybe it's better to try to insert this into the 2.8 release, as it is quite a substantial and capricious piece of work... Some improvements to the wake of Vinson are likely to have cost some framerate. These can be reverted by selecting a lower quality setting so it should be possible to compare like-with-like. Yes, I did that. Switching all water shaders off got me from 15 up to 20 fps - it used to be around 35, so there's still a chunk missing. Could AI traffic cost that much? * Thorsten -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Weather issues for 2.6
I've just placed a patch into the forum fixing the altitudes, providing a new GUI which makes Local Weather Config obsolete and ports Cb towers also to the new rendering system. I haven't tested it excessively yesterday, but most of it was written and tested before my computer died, so it should be fine. You should be able to set the render bin for the effect if you are using one. Alternatively, it may be that we can get more performance from the clouds such that we won't need to put them in a separate render-bin. Hm, this seems to be more subtle then. I adapted rain-layer.eff from cloud.eff and as a consequence I see that in both files render-bin bin-number10/bin-number bin-nameDepthSortedBin/bin-name /render-bin occurs. So that is in fact not the problem?! But then what it - why are the rain layers always sorted in front of the clouds? * Thorsten -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Weather issues for 2.6
Thorsten, ... snip ... 9) Water shader (very impressive!!!) doesn't react to wind/overcast in Local Weather. Vivian, Emilian - at some point we discussed an interface of how to pass the situation to the shader. Technically it's really easy for me to write in any form you like - just tell me where you want to pick up that info. We are still looking into this one. At first glance there doesn't seem to be any good reason for the wind not being honoured. The overcast is a problem of interpreting different implementations between Global and Local weather. Now you are back operational we will try to come up with a suggestion in the next couple of days 10) Skydome scattering shader - is now basically broken in overcast situations when visibility is low, because the clouds fade rapidly but the shader doesn't react, so more blue sky is seen when visibility goes down. In October, I had a near-seamless solution to that involving the ground haze shader, a modified skydome shader, and modified cloud distance fading behaviour which did the trick both for local and global weather (which was also posted in the forum as very experimental feature). Is anyone (Vivian, Emilian?) still working on that - or should this better go into the next release? We had some problems with adapting the ground haze shader to the new, universal fog scheme. At the moment, our results are unacceptable for release. We are not clear at this stage if we can do it at all, and we are unlikely to come up with a tested and tuned solution by the 17th. We will continue to work on it in the next few days to come up with a better informed decision on the way ahead. All in all, the performance requirements of the current version are weird. I took my Carrier-Ops flight from Vinson to Nimitz in the F-14b which used to have good framerate (no terrain) and I ended up with 14 fps. Not really improved a lot by switching water shader off... I then wanted to know how far down it'd go in really detailed scenery and used the Lightning to blast around Hawaii to Maui - with similar cloud coverage I ended up with twice the framerate and a comfortable 24-30 fps. With the Concorde on the runway in Seattle, I had a whopping 3 fps (never seen anything this low...), but the AAr with the F-16 around Las Vegas gave me 34-40 fps (again in similar clouds). Doesn't agree at all with my previous experience. Some improvements to the wake of Vinson are likely to have cost some framerate. These can be reverted by selecting a lower quality setting so it should be possible to compare like-with-like. Vivian -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weather issues for 2.6
Thanks to Hooray who helped me setting up the CMake environment and the guys at Infocare who finally managed to fix heat management of my computer, I am now back on the devel tree. I've done a few tests yesterday and identified a list of weather-related issues which I think should be addressed (unfortunately, I can't do all myself). (all refers to GIT as pulled yesterday afternoon and FG, SG and FGData in sync) 1) Local Weather places clouds at the wrong altitude. (I will fix that). 2) The GUI is not consistent with the system (I will fix that) 3) High-altitude single-layer non-rotated clouds get shaded when the ground gets shaded (I verified that they are subject to /rendering/scene/saturation, but I believe I can undo this dependency in the model xml wrapper - I'll try to deal with it) 4) Clouds now appear to be loaded in discrete lumps when they come into visual range rather than gradually be faded in via transparency which looks a bit ugly from high altitude - Stuart, is this intentional and a performance-related issue? I have verified that the corresponding tile is already loaded, so it's not something my part of the system does. 5) Changing the cloud density slider with LW clouds in the scene still erases all clouds for me. Imho, would be a net option to have. Stuart, what are your plans? 6) External rain textures are visible through clouds from above, looking very silly. As far as I understand, since rain textures are true models with 2d billboard animation whereas clouds are sprites with shader rotation, the issue here is the render-bin again (?). I see three possibilities - either we write a 2d rotation shader like the cloud shader and use it for the rain textures and the infrastructure to go with it, then rain is just like clouds and it should be fine. Or there is a way to assign a render-bin somehow to the model as it is loaded. Or external rain textures go away for the moment. 7) Similar problem with non-rotated high-altitude clouds - they are always drawn in front of any other clouds, which looks silly when you see them through a low overcast layer. Most of the time it's not so bad though, since clouds on clouds is low contrast. So again, either they get a non-rotating cloud shader and the infrastructure (difficult, since they're really on curved sheets modelled to follow the cloud structure) or they can be assigned to a bin which does the sorting right. Or they stay as they are. 8) Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which always renders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? 9) Water shader (very impressive!!!) doesn't react to wind/overcast in Local Weather. Vivian, Emilian - at some point we discussed an interface of how to pass the situation to the shader. Technically it's really easy for me to write in any form you like - just tell me where you want to pick up that info. 10) Skydome scattering shader - is now basically broken in overcast situations when visibility is low, because the clouds fade rapidly but the shader doesn't react, so more blue sky is seen when visibility goes down. In October, I had a near-seamless solution to that involving the ground haze shader, a modified skydome shader, and modified cloud distance fading behaviour which did the trick both for local and global weather (which was also posted in the forum as very experimental feature). Is anyone (Vivian, Emilian?) still working on that - or should this better go into the next release? All in all, the performance requirements of the current version are weird. I took my Carrier-Ops flight from Vinson to Nimitz in the F-14b which used to have good framerate (no terrain) and I ended up with 14 fps. Not really improved a lot by switching water shader off... I then wanted to know how far down it'd go in really detailed scenery and used the Lightning to blast around Hawaii to Maui - with similar cloud coverage I ended up with twice the framerate and a comfortable 24-30 fps. With the Concorde on the runway in Seattle, I had a whopping 3 fps (never seen anything this low...), but the AAr with the F-16 around Las Vegas gave me 34-40 fps (again in similar clouds). Doesn't agree at all with my previous experience. Cheers, * Thorsten -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This
Re: [Flightgear-devel] Weather issues for 2.6
On Wed, Dec 14, 2011 at 10:35 AM, Thorsten R. wrote: Thanks to Hooray who helped me setting up the CMake environment and the guys at Infocare who finally managed to fix heat management of my computer, I am now back on the devel tree. I've done a few tests yesterday and identified a list of weather-related issues which I think should be addressed (unfortunately, I can't do all myself). Glad you're computer has been sorted. 4) Clouds now appear to be loaded in discrete lumps when they come into visual range rather than gradually be faded in via transparency which looks a bit ugly from high altitude - Stuart, is this intentional and a performance-related issue? Neither. I think it's a bug due to the way in which LoD is handled - basically the LoD is cutting in before the transparency fading. The LoD is static, while the transparency can be set by the user. I need to make the LoD dynamic, 5) Changing the cloud density slider with LW clouds in the scene still erases all clouds for me. Imho, would be a net option to have. Stuart, what are your plans? No plans to fix this at present, The underlying problem is that changing the cloud density causes the clouds to be regenerated from the weather conditions. Unfortunately changing that will require quite some re-architecting. I'll bear it in mind in my performance work to see if I can make it easier. 6) External rain textures are visible through clouds from above, looking very silly. As far as I understand, since rain textures are true models with 2d billboard animation whereas clouds are sprites with shader rotation, the issue here is the render-bin again (?). I see three possibilities - either we write a 2d rotation shader like the cloud shader and use it for the rain textures and the infrastructure to go with it, then rain is just like clouds and it should be fine. Or there is a way to assign a render-bin somehow to the model as it is loaded. Or external rain textures go away for the moment. You should be able to set the render bin for the effect if you are using one. Alternatively, it may be that we can get more performance from the clouds such that we won't need to put them in a separate render-bin. -Stuart -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
