Re: [Flightgear-devel] Default 3d clouds in Local Weather
Hi Stuart, after some testing of the new scheme, I have two minor and one major comment. Minor stuff first: * how is the cloud density slider supposed to influence the clouds generated by add-cloud? Heiko claims that he gets to see an effect, I tried to reproduce that but all that happened is that all clouds vanished as soon as I moved the slider, never to reappear. * same thing actually with switching shaders off and on again (I sometimes do that to see how the scene would look in a different rendering scheme) - while the global weather clouds reappear, the manually added ones are gone never to reappear for me. Is this behaviour expected/consistent/as it should be? Now the big thing: it seems I can't use the shading options under most conditions. The only thing that seems to matter is what I pass as middle-factor, and that determines the color of the whole cloud from top to bottom. I have some idea why this might be the case: It's not clear to me how a vertex shader could paint a single sprite with 4 vertices consistently with a top, middle and bottom color. All it can do is paint the upper two vertices in one color, and the lower in a different color, and the rest is interpolation. A fragment shader could probably do it, but that's not where the shading code is. So, it seems to me that there's the implicit assumption in the scheme that cloud_height is at least 2-3 times sprite_height, so that there are enough vertices in between such that 3 colors can be achieved. But building clouds that way is a luxury we can't afford too often. You have to start all design considerations from 8/8 layers which need to run with decent performance, otherwise you'll never be able to do overcast. You can't start with a design working well for 1/8 coverage and expect that it will stay that way for 8/8. Currently I'm doing overcast layers with single elements (still a few sprites per element to avoid too flat-looking layers) of ~ 2000 m size, scaled using z-scaling of 0.25 in the vertical axis to 500 m. To cover a 40x40 km area, one needs some overlap, i.e. about 32x32 ~ 1000 basic elements do nicely. The value of z-scaling is a bit pushing it - it can't be much smaller without creating ugly artefacts, i.e. the thinnest layer I can achieve in 3d is 500 m. A 200 m thick layer isn't conceptually possible in this scheme. This setup already gets the first people up and complaining about low framerates, so there is basically no margin to throw in more basic elements - just maybe a factor 2, but that's it. The virtue of z-scaling is that I can do a 500 m thick layer with 2000 m size elements in the (x,y) plane. Without z-scaling, I'd have to cover everything with 500 m x 500 m x 500 m elements, that'd be a factor 16 (!) more for the same layer - not doable. If you now impose the requirement that I need a sprite size 3 times smaller than cloud size to get the lighting to work properly, we end up for the same layer with ~166 m sized elements in the vertical axis. Since z-scaling can't be smaller than 0.25, these elements are then 660 m sized in x and y direction and one needs a factor 27 (!) more of them to do the same layer. I am fairly sure this would drive every GPU we have into single digit framerates. So that's the reason why layered clouds will almost always end up with sprite-size ~ cloud-size - the third power in numbers needed to fill large layer volumes is killing you otherwise. And since we can't do it otherwise, the shading system must be capable of dealing with sprite-size = cloud-size. It's nice to have the option to render situations with 1/8 coverage in really detailed lighting, but we can't base the design of the system on that situation. I hope that's enough explanation to convince everyone that I'm not being mean here and just do stupid design that doesn't work with the shading, but that there are real issues here. I actually feel bad firing off one issue after the other... I am happy with the performance of the system in most situations otherwise. Cheers, * Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Thu, Oct 13, 2011 at 9:23 AM, Thorsten Renk wrote: Hi Stuart, after some testing of the new scheme, I have two minor and one major comment. Minor stuff first: * how is the cloud density slider supposed to influence the clouds generated by add-cloud? Heiko claims that he gets to see an effect, I tried to reproduce that but all that happened is that all clouds vanished as soon as I moved the slider, never to reappear. The cloud density is used as a multiplier on the number of sprites that are generated for a specific cloud instance: int n_sprites = num_sprites * sprite_density * (0.5f + sg_random()); I've repro'd the problem where manually placed clouds disappear when this is changed. I suspect the problem is that it is clearing all the clouds and then causing the global clouds to be re-generated. I'll investigate further. * same thing actually with switching shaders off and on again (I sometimes do that to see how the scene would look in a different rendering scheme) - while the global weather clouds reappear, the manually added ones are gone never to reappear for me. Is this behaviour expected/consistent/as it should be? Probably a similar problem - I'll take a look. Now the big thing: it seems I can't use the shading options under most conditions. The only thing that seems to matter is what I pass as middle-factor, and that determines the color of the whole cloud from top to bottom. Yup - that's a bug. Should now be fixed in the shader code so that the top/middle/bottom shade all have an effect. I have some idea why this might be the case: It's not clear to me how a vertex shader could paint a single sprite with 4 vertices consistently with a top, middle and bottom color. All it can do is paint the upper two vertices in one color, and the lower in a different color, and the rest is interpolation. A fragment shader could probably do it, but that's not where the shading code is. So, it seems to me that there's the implicit assumption in the scheme that cloud_height is at least 2-3 times sprite_height, so that there are enough vertices in between such that 3 colors can be achieved. You are correct. If you are just using a single texture for the cloud then only the top,bottom and shade light factors are really relevant - the middle shade is less relevant. However, you can still use it to determine the shade if the texture isn't exactly the same size as the cloud. But building clouds that way is a luxury we can't afford too often. You have to start all design considerations from 8/8 layers which need to run with decent performance, otherwise you'll never be able to do overcast. You can't start with a design working well for 1/8 coverage and expect that it will stay that way for 8/8. LOL. What you say is absolutely correct - I must admit to having completely forgotten this in my enthusiasm for creating greater control over the shading. Looks like it isn't as useful as I had hoped :) However, I hope it will allow you to create towering CBs as composite clouds, with better control over the shade of the top/bottom of each slice. I hope that's enough explanation to convince everyone that I'm not being mean here and just do stupid design that doesn't work with the shading, but that there are real issues here. I actually feel bad firing off one issue after the other... I am happy with the performance of the system in most situations otherwise. No problem. Please keep on pointing out the bugs/issues. I've been trying to stay on top of them and iteratively making the cloud system more useful, but I haven't done as much testing as I would like so it's very useful to have these things pointed out to me. -Stuart -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Hi Stuart, This should now be fixed, and the clouds should be white once more. Thorsten R. - regarding the 3000ft altitude offset problem, can you check that you haven't got an altitude set for the layer itself? Offsets as such are okay. I used to have some models with internal coordinates (0,0) at the center of the cloud, some at the bottom, with your rendering engine I can't specify offsets in the *.ac modelw any more, so they go into the code. They should be just something that is measured once and then stays. I've just done a quick check after a pull, and it seems that the curved layer problem is indeed gone :-) I'll have a look at offsets later today, but if they're just different - don't worry. Thanks for the hard work. Side remark: we now seem to have a speed limit: Whenever I exceed ~ 1600 kt with the ufo I get callsign Previous waypoint Cruise Departure airport 0xb85b380 Leg 5 target_speed 1004.05 speedFraction 0.00287666 Currecnt speed 1004 Segmentation fault So I just have to fly very slowly. Don't know where that is coming from... Cheers, * Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
2011/10/10 thorsten.i.r...@jyu.fi callsign Previous waypoint Cruise Departure airport 0xb85b380 Leg 5 target_speed 1004.05 speedFraction 0.00287666 Currecnt speed 1004 Segmentation fault I got same segfault when stay solid in UFO. May be its Durk's traffic? -- --- WBR, Vadym. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Hi All, On 10 Oct 2011, at 10:55, Vadym Kukhtin wrote: 2011/10/10 thorsten.i.r...@jyu.fi callsign Previous waypoint Cruise Departure airport 0xb85b380 Leg 5 target_speed 1004.05 speedFraction 0.00287666 Currecnt speed 1004 Segmentation fault I got same segfault when stay solid in UFO. May be its Durk's traffic? Yikes, that's very likely As part of last weekend's session, I've been chasing a few cases of AITraffic's speed getting out of the ordinary. To facilitate finding the offending code, I added a new function assertSpeed, which raises a segfault signal when speed exceeds beyond what may be reasonably expected in the AI system. That way I could inspect the calling stack from within gdb. Unfortunately, it looks like I forgot to comment this out before pushing to gitorious. Sorry about that. I'll fix that tonight. In the mean time, either just comment out all occurrences of assertSpeed in src/AIModel/AIAircraft.cxx or find the occurrences of raise() and comment these out. They should also be limited to AIAircraft.cxx off the top of my head. cheers, Durk -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Side remark: we now seem to have a speed limit: Whenever I exceed ~ 1600 kt with the ufo I get Okay, the speed limit on the intergalactic highway has been liftted. Make sure to have your towel ready and count to 42. :-) Cheers, Durk -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Thanks for the reports. I suspect something has gone wrong with my merge. Unfortunately I wont be able to look at it until tonight. Sorry for breaking the build. -Stuart On 7 Oct 2011, at 23:35, syd adams adams@gmail.com wrote: Me too , with ATIMobility Radeon HD 4250 On Fri, Oct 7, 2011 at 11:55 AM, emili...@gmail.com wrote: On Friday 07 October 2011 19:38:54 Durk Talsma wrote: On 07 Oct 2011, at 19:01, Frederic Bouvier wrote: Me too on the black clouds now ... nvidia graphics card + latest git. It's the same for me Me Too: (two Nvidia 9800GT cards + latest git). Me (1, 2, 3 , 4.. ok that's 5)... Me5 Nvidia 8600 GT, linux, latest git -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Sat, Oct 8, 2011 at 7:56 AM, Stuart Buchanan stuar...@gmail.com wrote: Thanks for the reports. I suspect something has gone wrong with my merge. Unfortunately I wont be able to look at it until tonight. Sorry for breaking the build. -Stuart I've identified what's gone wrong - the simgear code changes aren't yet in simgear/next in gitorious, but the co-requisite changes have been made to fgdata. I'm checking with Torsten D. to determine if they are sitting in his local repository and just need to be pushed up. If we can't resolve this in the next couple of hours, I'll revert the fgdata changes so at least the clouds will be white again! Apologies for the mess. -Stuart -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Sat, Oct 8, 2011 at 6:53 PM, I wrote: On Sat, Oct 8, 2011 at 7:56 AM, Stuart Buchanan I wrote: Thanks for the reports. I suspect something has gone wrong with my merge. Unfortunately I wont be able to look at it until tonight. Sorry for breaking the build. -Stuart I've identified what's gone wrong - the simgear code changes aren't yet in simgear/next in gitorious, but the co-requisite changes have been made to fgdata. I'm checking with Torsten D. to determine if they are sitting in his local repository and just need to be pushed up. If we can't resolve this in the next couple of hours, I'll revert the fgdata changes so at least the clouds will be white again! Apologies for the mess. -Stuart This should now be fixed, and the clouds should be white once more. Thorsten R. - regarding the 3000ft altitude offset problem, can you check that you haven't got an altitude set for the layer itself? (FYI I've found a bug with METAR clouds levels which I'm investigating, though I don't think it's related to the latest changes) -Stuart -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Torsten has kindly committed my recent merge requests. So, not only should the curved field be fixed, but there are also many more shading parameters available for the top/middle/bottom/shaded part of the cloud. See README.3Dclouds for details. Thanks, I'll pull this right away! * Thorsten -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
So, not only should the curved field be fixed, but there are also many more shading parameters available for the top/middle/bottom/shaded part of the cloud. See README.3Dclouds for details. Somehow, that didn't work out for me. * clouds are now black (see also http://flightgear.org/forums/viewtopic.php?f=5t=7358start=435#p139537 in the Forum - I'm not the only one with that problem - the common theme might be an NVIDIA GPU here (?)). I've temporarily fixed that by setting top_factor and middle_factor to 1.0 - it seems the shader itself is working fine, it just doesn't get the right values. * cloud placement altitudes are offset to what they were previously. I had measured out an offset value for each cloud type which places that cloud at exactly the right altitude, that's now 3000 ft different from what it was - something can't be right here... * the problem that clouds move upward as I increase distance is still there :-( On my machine, currently the weather system only produces crap *sigh* - rain works randomly, rain and haze are offset from clouds, clouds appear at unpredictable altitudes... Maybe we should revert to the previous state till that is sorted out - or am I a small minority experiencing such problems? * Thorsten -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Fri, Oct 7, 2011 at 11:33 AM, thorsten.i.r...@jyu.fi wrote: Somehow, that didn't work out for me. * clouds are now black (see also http://flightgear.org/forums/viewtopic.php?f=5t=7358start=435#p139537 in the Forum - I'm not the only one with that problem - the common theme might be an NVIDIA GPU here (?)). I've temporarily fixed that by setting top_factor and middle_factor to 1.0 - it seems the shader itself is working fine, it just doesn't get the right values. * cloud placement altitudes are offset to what they were previously. I had measured out an offset value for each cloud type which places that cloud at exactly the right altitude, that's now 3000 ft different from what it was - something can't be right here... * the problem that clouds move upward as I increase distance is still there :-( On my machine, currently the weather system only produces crap *sigh* - rain works randomly, rain and haze are offset from clouds, clouds appear at unpredictable altitudes... Maybe we should revert to the previous state till that is sorted out - or am I a small minority experiencing such problems? * Thorsten Me too on the black clouds now ... nvidia graphics card + latest git. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On 07 Oct 2011, at 19:01, Frederic Bouvier wrote: Me too on the black clouds now ... nvidia graphics card + latest git. It's the same for me Me Too: (two Nvidia 9800GT cards + latest git). -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Friday 07 October 2011 19:38:54 Durk Talsma wrote: On 07 Oct 2011, at 19:01, Frederic Bouvier wrote: Me too on the black clouds now ... nvidia graphics card + latest git. It's the same for me Me Too: (two Nvidia 9800GT cards + latest git). Me (1, 2, 3 , 4.. ok that's 5)... Me5 Nvidia 8600 GT, linux, latest git -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Me too , with ATIMobility Radeon HD 4250 On Fri, Oct 7, 2011 at 11:55 AM, emili...@gmail.com wrote: On Friday 07 October 2011 19:38:54 Durk Talsma wrote: On 07 Oct 2011, at 19:01, Frederic Bouvier wrote: Me too on the black clouds now ... nvidia graphics card + latest git. It's the same for me Me Too: (two Nvidia 9800GT cards + latest git). Me (1, 2, 3 , 4.. ok that's 5)... Me5 Nvidia 8600 GT, linux, latest git -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Wed, Oct 5, 2011 at 10:36 PM, I wrote: Yes - I've managed to repro the problem. My previous fix was insufficient. I've got another fix, that I think solves the problem, but unfortunately I've got a bunch of simgear merge requests stacked up on gitorious right now, so it may be some time before the fix is committed in git. Torsten has kindly committed my recent merge requests. So, not only should the curved field be fixed, but there are also many more shading parameters available for the top/middle/bottom/shaded part of the cloud. See README.3Dclouds for details. Enjoy! -Stuart -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Mon, Oct 3, 2011 at 1:03 PM, Thorsten Renk wrote: What's the status of the flat layer on curved Earth problem by the way? This should have been fixed since September 12th in git. https://gitorious.org/fg/simgear/commit/d2dfb81a0907276f36cf7582c4274fa1784972d6 Are you still seeing the problem? Unfortunately yes. I've pulled and compiled just today, I'm seeing the new replay system, so I guess there's no chance of me mixing up the binaries. snip Could you perform this test and let me know if you observe something different? Yes - I've managed to repro the problem. My previous fix was insufficient. I've got another fix, that I think solves the problem, but unfortunately I've got a bunch of simgear merge requests stacked up on gitorious right now, so it may be some time before the fix is committed in git. -Stuart -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
I see. So what do I do when I want to change the wind and want the clouds to follow the new setting? Simply do a setprop for the layer height setting it to the same value it was? For the moment, Yes. At some point in the future we should fix it so that we're picking up the wind from the appropriate aloft layer. Okay, no hurry with that, I have no infrastructure for creating tiles for a set altitude anyway yet, so it may not be needed for a while... What's the status of the flat layer on curved Earth problem by the way? Cheers, * Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Mon, Oct 3, 2011 at 11:08 AM, Thorsten Renk wrote: What's the status of the flat layer on curved Earth problem by the way? This should have been fixed since September 12th in git. https://gitorious.org/fg/simgear/commit/d2dfb81a0907276f36cf7582c4274fa1784972d6 Are you still seeing the problem? -Stuart -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
What's the status of the flat layer on curved Earth problem by the way? This should have been fixed since September 12th in git. https://gitorious.org/fg/simgear/commit/d2dfb81a0907276f36cf7582c4274fa1784972d6 Are you still seeing the problem? Unfortunately yes. I've pulled and compiled just today, I'm seeing the new replay system, so I guess there's no chance of me mixing up the binaries. Do the following test (this is what I'm seeing): * with the ufo, select any non-scenery intensive area (say, TNCM) * set hardcoded_clouds_flag = 0 in local_weather.nas * get any weather tile in 'repeat tile' mode * fly to the cloudbase, then level off and get going with 6000 kt into any given direction, keeping your altitude constant = after 250 km or so, you are still about at the same cloud base as originally * repeat the exercise with hardcoded_clouds_flag = 1 = after 250 km or so, you are well below cloud base, you can observe as you go that every subsequent tile is drawn above the last The increase even appears to be non-linear in distance, getting worse as you are further and further away from your origin, in agreement with the expected 1- d^2 expansion of the cosine as you follow the sphere. Could you perform this test and let me know if you observe something different? I have a customized version of FGData, but since the patch is supposed to simgear, which I use unmodified from the devel version, I can't see that this is an issue here... Thanks, * Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Hi Stuart, (Apologies if I've missed this already) Are you planning put this into git? Should actually be in now - you might have to activate it though, because I haven't changed the gui and some menu options cause errors with the new rendering system because they are not implemented or obsolete. Find var hardcoded_clouds_flag = 0; in Nasal/local_weather/local_weather.nas and change it to var hardcoded_clouds_flag = 1; All the parameters for the layers are in cloud_definitions.nas I've had another look. The property is /environment/wind-speed.kt However, the layer only gets updated when the layer height (/environment/clouds/layer[n]/elevation-ft) is subsequently updated. A similar thing happens with the wind direction. I see. So what do I do when I want to change the wind and want the clouds to follow the new setting? Simply do a setprop for the layer height setting it to the same value it was? Cheers, * Thorsten -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On 1 Oct 2011, at 11:25, Thorsten Renk wrote: I see. So what do I do when I want to change the wind and want the clouds to follow the new setting? Simply do a setprop for the layer height setting it to the same value it was? For the moment, Yes. At some point in the future we should fix it so that we're picking up the wind from the appropriate aloft layer. -Stuart -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Mon, Sep 12, 2011 at 3:55 PM, Thorsten Renk wrote: 3) Antishading If you can provide the parameters of a cloud that is exhibiting the problem, that would be most useful. Okay, I've decided over the weekend that I'll make my current code available this week, because there's so much new stuff in which is not related to the transition to the new rendering system (some new textures, the detailed cloud-terrain interaction model, ...) that it may even be interesting for a 2.4 user. (Apologies if I've missed this already) Are you planning put this into git? So the new routines will be off by default, but editing a simple flag in the code will switch them on and then you can study the problems in situ. 4) Fading in poor visibility Making it a function of visibility should be the way forward. I think that's what the gl_Fog.density is supposed to represent, so it may simply be a question of modifying the function further. Perhaps it shouldn't be exp()? Okay, I'll try to come up with a function which works for that. I guess exp(-d/d0) is the correct parametric form, just d0 should be changed to a function d0(visibility-m), but I should be able to find a solution if we agree that this is what we want to modify. 5) Specify top and bottom shade I'm thinking that we need a top, middle and bottom shade, as the current model shades only from the middle of the cloud downwards. I see - then let's do it like this. I've got a merge request for simgear in the merge queue to add parameters for min/max bottom/middle/top/shade flighting factors. Also, I remember I asked this already, but you weren't quite sure then and the answer you guessed turned out not to be correct: What property determines the speed at which a given layer drifts? It gets set correctly when I initialize Local Weather with constant winds, but I'm not sure if it gets updated when I allow interpolated winds. I've been thinking of doing Lenticularis clouds by simply assigning them to a different, unmoving layer - I think that'd be pretty cool. I've had another look. The property is /environment/wind-speed.kt However, the layer only gets updated when the layer height (/environment/clouds/layer[n]/elevation-ft) is subsequently updated. A similar thing happens with the wind direction. -Stuart -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Sun, 2011-09-11 at 23:18 +0100, Stuart Buchanan wrote: On Sun, Sep 11, 2011 at 7:47 AM, Thorsten Renk wrote: I'd really like the 3D cloud infrastructure to be used for all the clouds, so if there are features missing we should address them. Would it be possible to modify the 3D clouds so that they can be used for the rain texture as well? For example, I could provide a sprite distribution on the surface of a cylinder rather than a sphere if that would help. Just a short answer to this part: All these objects (rain textures, Cirrus clouds,...) do not use the 3d cloud infrastructure because they are not 3d clouds. Thanks for the explanation. Doesn't look like there's much benefit from hacking the 3D clouds system to do something it's not intended to. So... that leaves fixing the underlying problem. The problem definitely seems to be that any other objects in the scenery with an alpha layer are rendered after the clouds, so are rendered in front of them, irrespective of the viewpoint and their relative positions. By removing the alpha layer from the texture of the stratosphere-tower in Las Vegas, I was able to work around the problem. Unfortunately, fixing this is going to require someone with more knowledge of OSG than I have. The problem is that the 3D clouds are in an earlier rendering bin from the scenery models with transparent textures, which means that the clouds are rendered first in their entirety, and then the scenery models, with no consideration of the relative position (i.e. depth) compare with the clouds. This was done for perf reasons. Putting the clouds in the same rendering bin (i.e. TRANSPARENT_BIN) halves the framerate on my system. I'm not sure there is a fix for this that doesn't massively impact performance, unless we add some of these objects to the CLOUDS_BIN and then depth-sort them within the cloud code itself which depth-sorts slowly across multiple frames to avoid exactly the performance hit from depth sorting the entire TRANSPARENT_BIN in each frame. Tim/Matthias - care to comment? I've once applied a patch someone came up with that fixed a number of alpha blending problems but unfortunately can't find where it applied. In the mean time I found this: http://www.palomino3d.com/pal_com/openscenegraph/ Blending Blending in OSG is similar to OpenGL, with the addition of using OSG's transparent bin (essentially another rendering pass) for transparent primitives. // Enable blending, select transparent bin. stateSet-setMode( GL_BLEND, osg::StateAttribute::ON ); stateSet-setRenderingHint( osg::StateSet::TRANSPARENT_BIN ); // Enable depth test so that an opaque polygon will occlude a transparent one behind it. stateSet-setMode( GL_DEPTH_TEST, osg::StateAttribute::ON ); // Conversely, disable writing to depth buffer so that // a transparent polygon will allow polygons behind it to shine thru. // OSG renders transparent polygons after opaque ones. osg::Depth* depth = new osg::Depth; depth-setWriteMask( false ); stateSet-setAttributeAndModes( depth, osg::StateAttribute::ON ); // Disable conflicting modes. stateSet-setMode( GL_LIGHTING, osg::StateAttribute::OFF ); Erik -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Sun, 2011-09-11 at 23:18 +0100, Stuart Buchanan wrote: Unfortunately, fixing this is going to require someone with more knowledge of OSG than I have. The problem is that the 3D clouds are in an earlier rendering bin from the scenery models with transparent textures, which means that the clouds are rendered first in their entirety, and then the scenery models, with no consideration of the relative position (i.e. depth) compare with the clouds. This was done for perf reasons. Putting the clouds in the same rendering bin (i.e. TRANSPARENT_BIN) halves the framerate on my system. Oh wait, I missed this part. Sorry. Erik -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
3) Antishading If you can provide the parameters of a cloud that is exhibiting the problem, that would be most useful. Okay, I've decided over the weekend that I'll make my current code available this week, because there's so much new stuff in which is not related to the transition to the new rendering system (some new textures, the detailed cloud-terrain interaction model, ...) that it may even be interesting for a 2.4 user. So the new routines will be off by default, but editing a simple flag in the code will switch them on and then you can study the problems in situ. 4) Fading in poor visibility Making it a function of visibility should be the way forward. I think that's what the gl_Fog.density is supposed to represent, so it may simply be a question of modifying the function further. Perhaps it shouldn't be exp()? Okay, I'll try to come up with a function which works for that. I guess exp(-d/d0) is the correct parametric form, just d0 should be changed to a function d0(visibility-m), but I should be able to find a solution if we agree that this is what we want to modify. 5) Specify top and bottom shade I'm thinking that we need a top, middle and bottom shade, as the current model shades only from the middle of the cloud downwards. I see - then let's do it like this. Also, I remember I asked this already, but you weren't quite sure then and the answer you guessed turned out not to be correct: What property determines the speed at which a given layer drifts? It gets set correctly when I initialize Local Weather with constant winds, but I'm not sure if it gets updated when I allow interpolated winds. I've been thinking of doing Lenticularis clouds by simply assigning them to a different, unmoving layer - I think that'd be pretty cool. Thanks, * Thorsten -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Hi, On Monday, September 12, 2011 00:18:47 Stuart Buchanan wrote: The problem definitely seems to be that any other objects in the scenery with an alpha layer are rendered after the clouds, so are rendered in front of them, irrespective of the viewpoint and their relative positions. By removing the alpha layer from the texture of the stratosphere-tower in Las Vegas, I was able to work around the problem. Unfortunately, fixing this is going to require someone with more knowledge of OSG than I have. The problem is that the 3D clouds are in an earlier rendering bin from the scenery models with transparent textures, which means that the clouds are rendered first in their entirety, and then the scenery models, with no consideration of the relative position (i.e. depth) compare with the clouds. This was done for perf reasons. Putting the clouds in the same rendering bin (i.e. TRANSPARENT_BIN) halves the framerate on my system. I'm not sure there is a fix for this that doesn't massively impact performance, unless we add some of these objects to the CLOUDS_BIN and then depth-sort them within the cloud code itself which depth-sorts slowly across multiple frames to avoid exactly the performance hit from depth sorting the entire TRANSPARENT_BIN in each frame. Tim/Matthias - care to comment? I will try. Catching up on this longer discussion somehow. So, I may have overseen something now ... Also catching up on what we have currently implemented. Ok, having *everything* rendered connectly - where I really mean correctly - would require everything that is somehow translucent to be sorted. But could it help to reorder the bins somehow? That is assign render bin numbers to some parts of the scene? First draw the opaque scene, then the scenery objects that are translucent. Then the clouds and the ai aircraft. The last would be probably the own aircraft. There are already such games played with the runway lights I think. From that, what is the reason that the CLOUD_BIN number is 9. That means rendered *before* the translucent scenery objects? Ok, digging myself: Given the explanation in RenderConstants.hxx - that sounds somehow familiar to me - shows that this number is a compromise anyway. To me the argument means that the good old cloud layers are just too huge to do some sensible depth sorting with them. So move them out of the way and sort them by hand. But at the same time these are translucent and should happen about the same time other translucent object are drawn. Problably, drawing before translucent scenetry objects because the sky happens to be mostly before scenery objects. Which might become false once you are above this layer ... So, thinking about that: Merge the the huge cloud layers with the rest of the clouds. May be by splitting them into smaller chunks that interact more nicely with the other clouds. You will touch that for the curved layers anyway ... Then try to put the clouds into a bin 10. Then we get probably problems with the own aircraft or may be ai aircraft models with translucent parts. But I am sure we find an apropriate renderbin number for these parts of the scene. ... did you know, these render bins could also be nested? A closer look into the effect implementations regarding render bins might also be helpful. I am not sure if we break something else with effects with this kind of games ... And yes render bins are powerful but complicated. :) Hope this helps? Mathias -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Hi Stuart, I'd really like the 3D cloud infrastructure to be used for all the clouds, so if there are features missing we should address them. Would it be possible to modify the 3D clouds so that they can be used for the rain texture as well? For example, I could provide a sprite distribution on the surface of a cylinder rather than a sphere if that would help. Just a short answer to this part: All these objects (rain textures, Cirrus clouds,...) do not use the 3d cloud infrastructure because they are not 3d clouds. Cirrus and Cirrocumulus clouds are textures projected on a non-rotated but cruved surface (a bit like a saddle) - I see no straightforward way to get that with a shader, and I've never made any attempt work to render them as true 3d objects. (Technically, the reason is that they show fine detail with large variation, so cloudlets need to be large, and a preferred direction for the feathers - so whenever you rotate them, it shows immediately). Also in the literature, I haven't seen anyone who claimed to have generated true, rotating 3d Cirrus clouds). Cirrostratus and the larger Cirrocumulus don't have that problem, as they don't show preferred direction and have less fine detail - for those I needed z-scaling. Rain doesn't use a 3d but a 2d cylinder billboard rotation - I suppose that can be adapted to use with the shader easily enough by passing a parameter that tells which rotation is to be used if we want to do that. * Thorsten -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Sun, Sep 11, 2011 at 7:47 AM, Thorsten Renk wrote: I'd really like the 3D cloud infrastructure to be used for all the clouds, so if there are features missing we should address them. Would it be possible to modify the 3D clouds so that they can be used for the rain texture as well? For example, I could provide a sprite distribution on the surface of a cylinder rather than a sphere if that would help. Just a short answer to this part: All these objects (rain textures, Cirrus clouds,...) do not use the 3d cloud infrastructure because they are not 3d clouds. Thanks for the explanation. Doesn't look like there's much benefit from hacking the 3D clouds system to do something it's not intended to. So... that leaves fixing the underlying problem. The problem definitely seems to be that any other objects in the scenery with an alpha layer are rendered after the clouds, so are rendered in front of them, irrespective of the viewpoint and their relative positions. By removing the alpha layer from the texture of the stratosphere-tower in Las Vegas, I was able to work around the problem. Unfortunately, fixing this is going to require someone with more knowledge of OSG than I have. The problem is that the 3D clouds are in an earlier rendering bin from the scenery models with transparent textures, which means that the clouds are rendered first in their entirety, and then the scenery models, with no consideration of the relative position (i.e. depth) compare with the clouds. This was done for perf reasons. Putting the clouds in the same rendering bin (i.e. TRANSPARENT_BIN) halves the framerate on my system. I'm not sure there is a fix for this that doesn't massively impact performance, unless we add some of these objects to the CLOUDS_BIN and then depth-sort them within the cloud code itself which depth-sorts slowly across multiple frames to avoid exactly the performance hit from depth sorting the entire TRANSPARENT_BIN in each frame. Tim/Matthias - care to comment? Thorsten - FYI I've committed an update the README.3DClouds which documents the recent changes (z-scaling, changed defaults etc.) I've also got a merge request in to fix the flat field cloud placement bug. -Stuart -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Sat, Sep 3, 2011 at 8:15 AM, Thorsten Renk wrote: 1) placement in flat layer instead of curved OK. I'll get the fix for this committed as soon as I get the chance. 2) clouds don't obscure some objects (newly discovered) This may be a problem related to the rendering order of objects with alpha layers. The clouds are in a different RenderBin from other objects. I'll take a look and see what's different about the Vegas tower - the fix may be simply to remove the alpha layer from the texture. The stratus and rain layer textures are going to be much more difficult to resolve. For the stratus layer, I thought by putting in the z-scaling parameter you would be able to use the 3D clouds modeling? I'd really like the 3D cloud infrastructure to be used for all the clouds, so if there are features missing we should address them. Would it be possible to modify the 3D clouds so that they can be used for the rain texture as well? For example, I could provide a sprite distribution on the surface of a cylinder rather than a sphere if that would help. That would allow us to work around the rendering bin problem. 3) Antishading For some reason, I still get antishading in many situations even when I make cloud size larger than texture size. Looks odd in many cases and prevents me from adjusting the shade parameters. You mentioned finding a bug? I thought I had seen a bug, but in fact I was getting confused between the sun and the full moon - at very wide angles of view they both look like white points ;) If it's of any help, I can pack my current devel version of everything and you can see for yourself what happens (with the understanding that only specific settings in the gui are meaningful). If you can provide the parameters of a cloud that is exhibiting the problem, that would be most useful. Apart from the issues above, there are some things to discuss and think about: 4) Fading in poor visibility I'm now in the shader down to 0.1 for the fading factor in fogFactor = exp( -gl_Fog.density * fogCoord * 0.1); This looks too crisp in slightly hazy conditions, but I was basically forced to the setting by rainy conditions with ~2-4 km visibility. What happened otherwise was that clouds in that amount of haze faded so much that blue sky became visible above where the overcast cloud layer should have been drawn, which looks really bad. Maybe there shouldn't be a fixed number intended to fit all but a function of visibility? Or a parameter to be passed on - although you mentioned that passing too many parameters to the shader may lead to different problems... Making it a function of visibility should be the way forward. I think that's what the gl_Fog.density is supposed to represent, so it may simply be a question of modifying the function further. Perhaps it shouldn't be exp()? Given the number of parameters being passed into other shaders, I'm less worried about the 3D cloud shader than I was. There's also the possibility of creating a second, more complex shader for use with high quality settings in the Rendering Options dialog. 5) Specify top and bottom shade I mentioned that previously - it's not in any sense a 'must', but I think it would allow for very cool visual effects if the system had the possibility to shade clouds in a different way if there's a layer above (or even do some simple ray intersection tests when drawing a tile for greater realism). Again - would require to pass more parameters. I'm thinking that we need a top, middle and bottom shade, as the current model shades only from the middle of the cloud downwards. I think that's pretty much it. There's still lots of parameter tuning to be done on my side, and vertical motion of clouds still needs to be done, but basically it's functional (see the screenshots I'm already producing) - I haven't encountered any other problems so far. So we're clearly getting somewhere :-) Excellent! -Stuart -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Hi Stuart, Thorsten R. - please feel to provide a prioritized list of fixes/enhancements you need. A summary list of current issues ordered by priority (leaving out what your recent commit addressed - I still need to pull that): 1) placement in flat layer instead of curved That is currently blockig a lot of things. For instance, I need to adjust parameters to get the relative placement between new and old elements right (the effect reducing visibility in larger clouds should be where the cloud actually is, rain textures should connect with cloud textures), or I need to verify that vertical motion driven by terrain interaction works correctly - neither of which I can really do without having accurate vertical placement - I'll have to redo it after the fix anyway. 2) clouds don't obscure some objects (newly discovered) For some reason, some objects can be seen through even a very thick layer of new clouds (which otherwise obscures the terrain). Examples are one tower in downton Las Vegas (the rest of the buildings are just fine...), villages in Corsica, or, most problematic, all old cloud models. Since some elements aren't addressed in your system (the static cirrus models, rain layer textures) because they require different/no rotation in the shader, they'll remain models. But that means that I see Cirrus clouds *through* a thick layer of Nimbus from the ground, or, visually worst, I see the ring of rain layer textures from above a Nimbus layer. 3) Antishading For some reason, I still get antishading in many situations even when I make cloud size larger than texture size. Looks odd in many cases and prevents me from adjusting the shade parameters. You mentioned finding a bug? If it's of any help, I can pack my current devel version of everything and you can see for yourself what happens (with the understanding that only specific settings in the gui are meaningful). Apart from the issues above, there are some things to discuss and think about: 4) Fading in poor visibility I'm now in the shader down to 0.1 for the fading factor in fogFactor = exp( -gl_Fog.density * fogCoord * 0.1); This looks too crisp in slightly hazy conditions, but I was basically forced to the setting by rainy conditions with ~2-4 km visibility. What happened otherwise was that clouds in that amount of haze faded so much that blue sky became visible above where the overcast cloud layer should have been drawn, which looks really bad. Maybe there shouldn't be a fixed number intended to fit all but a function of visibility? Or a parameter to be passed on - although you mentioned that passing too many parameters to the shader may lead to different problems... 5) Specify top and bottom shade I mentioned that previously - it's not in any sense a 'must', but I think it would allow for very cool visual effects if the system had the possibility to shade clouds in a different way if there's a layer above (or even do some simple ray intersection tests when drawing a tile for greater realism). Again - would require to pass more parameters. I think that's pretty much it. There's still lots of parameter tuning to be done on my side, and vertical motion of clouds still needs to be done, but basically it's functional (see the screenshots I'm already producing) - I haven't encountered any other problems so far. So we're clearly getting somewhere :-) * Thorsten -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Tue, Aug 16, 2011 at 8:17 AM, wrote: ... and yet another issue: On a first long-range test yesterday, I observed that the cloud base of my convective layer was continuously rising. At takeoff the clouds were exactly as specified, later still plausible given terrain, but by the time the cloudbase had reached my curise altitude of 20.000 ft, I was reasonably certain that this had nothing to do with realistic terrain interaction and must be a bug. Yes, it's a bug in the cloud positioning code which is placing the clouds in a completely flat layer rather than curved. Fixing this may be a bit tricky. -Stuart -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
... and yet another issue: On a first long-range test yesterday, I observed that the cloud base of my convective layer was continuously rising. At takeoff the clouds were exactly as specified, later still plausible given terrain, but by the time the cloudbase had reached my curise altitude of 20.000 ft, I was reasonably certain that this had nothing to do with realistic terrain interaction and must be a bug. Convective cloud altitude determination is quite a complex procedure, and I spent 30 minutes to go through all of it. In the end, I verified that the raw list of alt-ft property values passed to fgcommand(add-cloud, p); is what it should be (in the 8000 ft range) by printing the whole set of 500 values to the console and that /environment/clouds/layer[0]/elevation-ft is set to zero (so that I can compute the absolute altitude of clouds in my routines) while clouds are drawn at 20.000 ft (I have a screenshot of that if needed). My only remaining theory is that /environment/clouds/layer[0]/elevation-ft describes a layer in Cartesian geometry which is attached to the sphere at my startup point. As I fly long distances, the spherical Earth curves away below the flat, uncurved layer, and thus there is an ever-increasing mismatch between zero altitude in (lat,lon,alt) coordinates on the sphere and zero altitude on the layer. This would at least be consistent with what I'm seeing. If so, there probably needs to be a routine which matches Cartesian and spherical geometry periodically... if not, I simply don't know what is wrong. * Thorsten -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Fri, Aug 12, 2011 at 10:52 AM, Thorsten Renk wrote: Yes, the sprite is selected from the sheet randomly on the x-axis and based on it's height in the cloud on the y-axis for precisely this reason. The behaviour isn't switchable at present though it could be. For the relatively small texture sheets I used in the default 3D clouds, I simply duplicated the textures, so you'd have a 2x6 or 3x9 sheet. Given that cloud performance is effectively limited by sprite resolution and coverage rather than texture sheet size, that might be OK. Otherwise I can add a switch fairly easily. Let me know if you want me to do so. If it's not too much trouble, I think the switch would be nice. Duplicating textures in this case (since a single image has about 1000x400 pixels) would mean going to a 2048x1024 sheet (possibly doesn't work) or then quadrupling it with several permutations on 2048x2048 - which seems a waste of good disk space. I've got a patch to do this that I'll submit shortly. the parameter is height-map-texture, and it defaults to false. I'm also taking the opportunity to change some of the defaults, so that the max-[cloud|sprite]-[width|height]-m parameters default to 1.5x the min equivalent. I suspect it won't make much difference to your clouds, as I expect you'll want to explicitly set all the parameters, but it should mean the defaults make more sense. I've done my first 'real' flight (i.e. not using the ufo) with the new system (and after compiling against OSG 3.01) yesterday - just a short hop from KLSV to KINS with the F-16 - framerate never dropped below 40 fps even with a fairly dense layer and 45 km visibility, in sparse clouds climbed above 70 fps. Pretty awsome... I don't really know how much of this is due to the new OSG version and how much due to the different cloud/terrain interaction system, but the combination is rather powerful. Even without splitting a sky generation across several frames, the delay building a new tile is actually less than the texture loading delay when I turn my head in the F-16 too much... Fantastic. I look forward to seeing the final results. -Stuart -- FREE DOWNLOAD - uberSVN with Social Coding for Subversion. Subversion made easy with a complete admin console. Easy to use, easy to manage, easy to install, easy to extend. Get a Free download of the new open ALM Subversion platform now. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
I've got a patch to do this that I'll submit shortly. the parameter is height-map-texture, and it defaults to false. I'm also taking the opportunity to change some of the defaults, so that the max-[cloud|sprite]-[width|height]-m parameters default to 1.5x the min equivalent. I suspect it won't make much difference to your clouds, as I expect you'll want to explicitly set all the parameters, but it should mean the defaults make more sense. Thanks. I have to take a look at the max-cloud-height-m - currently I'm only setting min-cloud-height-m for the following reason: It seems to me that the cloud *center* gets placed at (alt-ft + layer_altitude), such that (0.5 * cloud-height-m) is below the specified altitude and (0.5 * cloud-height-m) is above. For small sized clouds, that's not an issue, because the layer comes out right anyway. Now, at least convective layers in flat terrain have a relatively sharp altitude for the cloudbase - even if cloud tops can vary by a large margin, it simply doesn't do to have a cloudbase 500 m lower than for the surrounding clouds (for a cloud top, that's quite okay). It took my 30 minutes yesterday to find out that this was the trouble with my developing Cb clouds - so I fixed cloud-height-m to not have random variation and stacked the cloudlets using my routines such that the cloudbase is constant but the top of the layer may vary. Basically, in the current setup using random cloud-height-m between min and max values, it's impossible to get a well-defined cloud base altitude, because I can't know the random value for the height up front. I don't know if it makes sense to alter it though - for other layers, it may be useful to place the center at given altitude... I also came across a second issue (sorry, they just keep coming...) Large cloudlets tend to vanish from view at the edges of the view field. I suspect I understand why: You must generate the texture sheet somehow in the scenery with some orientation and size. The shader code then grabs it, resizes it using wScale and hScale to what you need and rotates it. Now, if wScale 1, it may easily occur that the true coordiantes (i.e. before rotation and scaling) are outside the field of view, while the apparent coordinates (i.e. after rotation and scaling by the shader) are in the field of view - but if the true coordinates are outside, the shader code is never called at all, and so the object suddenly vanishes. Basically, the base texture must be generated so large that wScale 1 is guaranteed to get rid of the problem (I had some models at 4 times design size, to be resized by the shader with a factor 0.25 to get rid of the problem). I suspect you should be able to generate the base texture with max-sprite-width/height-m rather than a constant and then scale down a bit. The trouble is that if the base scale is too large, the shader code needs to run for a lot of objects which are not inside the visual field, so wScale 1 (~O(0.01) is also something one'd like to avoid. Anyway, that's my diagnosis of what I'm seeing... I hope there's a way to fix that, for Cb clouds I can't simply go to small enough textures such that these problems don't occur... Cheers, * Thorsten -- FREE DOWNLOAD - uberSVN with Social Coding for Subversion. Subversion made easy with a complete admin console. Easy to use, easy to manage, easy to install, easy to extend. Get a Free download of the new open ALM Subversion platform now. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Sat, Aug 13, 2011 at 12:02 PM, Thorsten Renk wrote: Thanks. I have to take a look at the max-cloud-height-m - currently I'm only setting min-cloud-height-m for the following reason: It seems to me that the cloud *center* gets placed at (alt-ft + layer_altitude), such that (0.5 * cloud-height-m) is below the specified altitude and (0.5 * cloud-height-m) is above. For small sized clouds, that's not an issue, because the layer comes out right anyway. Now, at least convective layers in flat terrain have a relatively sharp altitude for the cloudbase - even if cloud tops can vary by a large margin, it simply doesn't do to have a cloudbase 500 m lower than for the surrounding clouds (for a cloud top, that's quite okay). It took my 30 minutes yesterday to find out that this was the trouble with my developing Cb clouds - so I fixed cloud-height-m to not have random variation and stacked the cloudlets using my routines such that the cloudbase is constant but the top of the layer may vary. Basically, in the current setup using random cloud-height-m between min and max values, it's impossible to get a well-defined cloud base altitude, because I can't know the random value for the height up front. I don't know if it makes sense to alter it though - for other layers, it may be useful to place the center at given altitude... I'm sure I can solve this with a bit of coding. :) I can see that it makes more sense to have the altitude define the base of the cloud rather than the centre. I'll change the code to do that. For layers with a more variable cloudbase, that variability can be defined in the cloud layer. I also came across a second issue (sorry, they just keep coming...) FYI, I just spotted what looks like another bug in the bottom-shade. Large cloudlets tend to vanish from view at the edges of the view field. I suspect I understand why: I'll take a look at this too. I suspect that the problem is simply the bounding box defined for the cloud. -Stuart -- FREE DOWNLOAD - uberSVN with Social Coding for Subversion. Subversion made easy with a complete admin console. Easy to use, easy to manage, easy to install, easy to extend. Get a Free download of the new open ALM Subversion platform now. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
That should be 1 second for most systems, so that's great. Does that just cover the elevation queries or generating the full model? That should be 1 sec for everything (I don't have any measurement for how fast generating the cloud models is, but it is *very* fast. If so, then I wonder if we can look at hiding the stop/start function from the end user. I think that would help the UI, and hopefully allow us to move towards my holy grail of a single (simple) UI for both global and local weather. Yes, the new terrain interaction is more than 50 times faster than the old one - that should allow to regernate a sky whenever someone presses 'apply'. I'd prefer not to make it configurable. We've seen some problems on older system where we exceed the number of registers available to the shaders for input, so I'd like to avoid adding any more if possible. Agreed. Let's just find the nicest value to insert. Yes, the sprite is selected from the sheet randomly on the x-axis and based on it's height in the cloud on the y-axis for precisely this reason. The behaviour isn't switchable at present though it could be. For the relatively small texture sheets I used in the default 3D clouds, I simply duplicated the textures, so you'd have a 2x6 or 3x9 sheet. Given that cloud performance is effectively limited by sprite resolution and coverage rather than texture sheet size, that might be OK. Otherwise I can add a switch fairly easily. Let me know if you want me to do so. If it's not too much trouble, I think the switch would be nice. Duplicating textures in this case (since a single image has about 1000x400 pixels) would mean going to a 2048x1024 sheet (possibly doesn't work) or then quadrupling it with several permutations on 2048x2048 - which seems a waste of good disk space. I've done my first 'real' flight (i.e. not using the ufo) with the new system (and after compiling against OSG 3.01) yesterday - just a short hop from KLSV to KINS with the F-16 - framerate never dropped below 40 fps even with a fairly dense layer and 45 km visibility, in sparse clouds climbed above 70 fps. Pretty awsome... I don't really know how much of this is due to the new OSG version and how much due to the different cloud/terrain interaction system, but the combination is rather powerful. Even without splitting a sky generation across several frames, the delay building a new tile is actually less than the texture loading delay when I turn my head in the F-16 too much... * Thorsten -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Some progress and minor issues: I am in the process of redoing textures and cloud definitions for Cu layers (the toughest nut), about halfway through converting all available cloud types. I have implemented tested tile management functionality (automatic building and removing clouds) and it seems to be working fine. The new geodinfo() works great - many thanks for that! - it speeds up the system considerably. Not to the point that all could be done in a single frame without generating a noticeable delay, so I'll have to write some routines to split it over maybe 10-20 frames (much better than 30 seconds though). I've noticed that 3dcloud.vert contains the line fogFactor = exp( -gl_Fog.density * fogCoord * 0.5); which tends to fade distant clouds to transparent dependent on visibility range. I find the visual impression better if the 0.5 is changed to a lower value, say 0.3 or even 0.2. Is there a reason to keep it at 0.5, or could we lower it? Also, at one point Stuart told me that the y-position of a texture on the texture sheet is correlated with the position the sprite gets in the cloud - is this something I should be aware of? For some cloud types, this may be useful, but for others it makes no sense. In particular the Congestus type images are much broader than high, so they are arranged in a 1x3 pattern on the sheet, but I don't really want the same texture to always form the cloud top. In any case - I take the opportunity to say thanks for all the help - I think the system is moving a big step forward right now. Cheers, * Thorsten -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Thu, Aug 11, 2011 at 9:29 AM, Thorsten Renk wrote: Some progress and minor issues: I am in the process of redoing textures and cloud definitions for Cu layers (the toughest nut), about halfway through converting all available cloud types. I have implemented tested tile management functionality (automatic building and removing clouds) and it seems to be working fine. The new geodinfo() works great - many thanks for that! - it speeds up the system considerably. Not to the point that all could be done in a single frame without generating a noticeable delay, so I'll have to write some routines to split it over maybe 10-20 frames (much better than 30 seconds though). That should be 1 second for most systems, so that's great. Does that just cover the elevation queries or generating the full model? If so, then I wonder if we can look at hiding the stop/start function from the end user. I think that would help the UI, and hopefully allow us to move towards my holy grail of a single (simple) UI for both global and local weather. I've noticed that 3dcloud.vert contains the line fogFactor = exp( -gl_Fog.density * fogCoord * 0.5); which tends to fade distant clouds to transparent dependent on visibility range. I find the visual impression better if the 0.5 is changed to a lower value, say 0.3 or even 0.2. Is there a reason to keep it at 0.5, or could we lower it? I suspect the 0.5 factor was copied straight from the 3D forest shader I wrote. I'll have a look and see what impact changing it has. I'd prefer not to make it configurable. We've seen some problems on older system where we exceed the number of registers available to the shaders for input, so I'd like to avoid adding any more if possible. Also, at one point Stuart told me that the y-position of a texture on the texture sheet is correlated with the position the sprite gets in the cloud - is this something I should be aware of? For some cloud types, this may be useful, but for others it makes no sense. In particular the Congestus type images are much broader than high, so they are arranged in a 1x3 pattern on the sheet, but I don't really want the same texture to always form the cloud top. Yes, the sprite is selected from the sheet randomly on the x-axis and based on it's height in the cloud on the y-axis for precisely this reason. The behaviour isn't switchable at present though it could be. For the relatively small texture sheets I used in the default 3D clouds, I simply duplicated the textures, so you'd have a 2x6 or 3x9 sheet. Given that cloud performance is effectively limited by sprite resolution and coverage rather than texture sheet size, that might be OK. Otherwise I can add a switch fairly easily. Let me know if you want me to do so. In any case - I take the opportunity to say thanks for all the help - I think the system is moving a big step forward right now. No problem. Great to help. -Stuart -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Instead there are two shadings taking place:
1) Shading based on distance of the sprite to the sun. Effectively
we compare a vector from the center of the cloud to the sprite location
with the light normal.
2) Shading based on the vertical placement of the sprite in the cloud, so
lower sprites are shaded more. This is controlled by the
bottom-shade parameter.
I suspect that it is the latter that is misbehaving. IIRC the
bottom-shader is applied
as a factor to the lighting, so using a value of (say) 0.1 should
result in a dark cloud
bottom.
Upon further reflection - could it be the problem that I'm trying to
assemble a layer rather than fill a volume?
The bottom shading in 3dcloud.vert is controlled by a combination of
'shade' and 'cloud_height'. Your Nasal interface doesn't provide an option
to set 'cloud_height' explicitly, so I'm assuming it's the box height
determined from 'min-cloud-height-m' and 'max-cloud-height-m' as used by
add-cloud.
Now, in assembling a layer, I want the box to be essentially flat, i.e.
just distribute textures on a layer with very little extension in
altitude, such that the layer thickness is determined by the size of a
single sprite rather than the box size, i.e. the sprite height is larger
than the box height. See my cloud definition code below (it's all written
into a hash first before the property argument for cloud-add is
assembled, but the parameter names are pretty similar - in case you're
wondering, z-scale is just for my reference what should be there later and
in my current experiments simply inserted into the shader by hand)
if (subtype == small) {var mult = 0.7;}
else {var mult = 1.0;}
# characterize the basic texture sheet
cloudAssembly.texture_sheet = /Models/Weather/stratus_sheet1.rgb;
cloudAssembly.num_tex_x = 3;
cloudAssembly.num_tex_y = 2;
#characterize the cloud
cloudAssembly.bottom_shade = 0.4;
cloudAssembly.n_sprites = 20;
cloudAssembly.min_width = 1800.0 * mult;
cloudAssembly.max_width = 2200.0 * mult;
cloudAssembly.min_height = 1800.0 * mult;
cloudAssembly.max_height = 2200.0 * mult;
cloudAssembly.min_cloud_width = 2200.0 * mult * mult * mult;
cloudAssembly.min_cloud_height = 50.0 * mult * mult * mult;
cloudAssembly.z_scale = 0.5;
Case in point - while min_cloud_height is just 50 m, the height of a
texture sheet is 900-1100 m (originally twice that, but z-rescaling
shrinks it again).
I'm suspecting that somehow the shader doesn't expect that. Maybe cloud
height as passed to the shader should be max(box_height, texture_height)?
Or an optional parameter? In clouds_layered.vert, a hard-coded value of
1000 m works fine.
* Thorsten
--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos much more. Register early save!
http://p.sf.net/sfu/rim-blackberry-1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Sun, Aug 7, 2011 at 11:24 AM, Thorsten Renk wrote:
Upon further reflection - could it be the problem that I'm trying to
assemble a layer rather than fill a volume?
The bottom shading in 3dcloud.vert is controlled by a combination of
'shade' and 'cloud_height'. Your Nasal interface doesn't provide an option
to set 'cloud_height' explicitly, so I'm assuming it's the box height
determined from 'min-cloud-height-m' and 'max-cloud-height-m' as used by
add-cloud.
Correct - the cloud is created with a width/height between the min/max values.
There are defaults, but I'm not sure they are what you are looking for! At
present they are as follows:
min-cloud-width-m, 500.0
max-cloud-width-m 1000.0
min-cloud-height-m, min-cloud-width-m
max-cloud-height-m, max-cloud-width-m
min-sprite-width-m, 200.0
max-sprite-width-m, min_sprite_width
min-sprite-height-m, min_sprite_width
max-sprite-height-m, max_sprite_width
I'm happy to change them to something else if it would be useful. I
suspect you might prefer the max values to always default to the min values?
Now, in assembling a layer, I want the box to be essentially flat, i.e.
just distribute textures on a layer with very little extension in
altitude, such that the layer thickness is determined by the size of a
single sprite rather than the box size, i.e. the sprite height is larger
than the box height. See my cloud definition code below (it's all written
into a hash first before the property argument for cloud-add is
assembled, but the parameter names are pretty similar - in case you're
wondering, z-scale is just for my reference what should be there later and
in my current experiments simply inserted into the shader by hand)
if (subtype == small) {var mult = 0.7;}
else {var mult = 1.0;}
# characterize the basic texture sheet
cloudAssembly.texture_sheet = /Models/Weather/stratus_sheet1.rgb;
cloudAssembly.num_tex_x = 3;
cloudAssembly.num_tex_y = 2;
#characterize the cloud
cloudAssembly.bottom_shade = 0.4;
cloudAssembly.n_sprites = 20;
cloudAssembly.min_width = 1800.0 * mult;
cloudAssembly.max_width = 2200.0 * mult;
cloudAssembly.min_height = 1800.0 * mult;
cloudAssembly.max_height = 2200.0 * mult;
cloudAssembly.min_cloud_width = 2200.0 * mult * mult * mult;
cloudAssembly.min_cloud_height = 50.0 * mult * mult * mult;
cloudAssembly.z_scale = 0.5;
Case in point - while min_cloud_height is just 50 m, the height of a
texture sheet is 900-1100 m (originally twice that, but z-rescaling
shrinks it again).
I'm suspecting that somehow the shader doesn't expect that. Maybe cloud
height as passed to the shader should be max(box_height, texture_height)?
Or an optional parameter? In clouds_layered.vert, a hard-coded value of
1000 m works fine.
I think the problem is that you are expecting the cloud height to
indicate the location
of sprite centers, wherease the code is expecting it to be the height
of the actual
cloud.
The code actually _subtracts_ the minimum texture height from the cloud
height to determine where to place sprite centers.
So, the height should always be greater than the minimum texture height.
In your example I would suggest setting
cloudAssembly.min_cloud_height = 50.0 * mult * mult * mul +
cloudAssembly.min_height
That should at least help the problem, though there may be other bugs there too.
BTW - this is all up for discussion. Just because I wrote the default
3D cloud code this
way doesn't mean to say that it's the correct approach!
-Stuart
--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos much more. Register early save!
http://p.sf.net/sfu/rim-blackberry-1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
I think the problem is that you are expecting the cloud height to indicate the location of sprite centers, wherease the code is expecting it to be the height of the actual cloud. The code actually _subtracts_ the minimum texture height from the cloud height to determine where to place sprite centers. So, the height should always be greater than the minimum texture height. Oops... In hindsight, a rather obvious explanation of what I'm seeing - a negative number created in the subtraction would of course invert the shading pattern seen later. Rather embarrassing... Thanks, I'll correct my code. * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Thu, Aug 4, 2011 at 12:51 PM, Thorsten Renk wrote: We should change the maximum to whatever you feel is sensible (40km?), and leave the default as it is (20km). I think my current maximum is 45 km, and for much more one needs a different tile structure anyway, so if we could get 45 km that'd be nice. I've made the small GUI dialog change required to allow users to get this up to 45km. However, I'm not sure we want to be over-riding the user's explicit preferences here. I can turn it around and use the value specified here for the cloud visible range of the old system - if that's not too confusing. I'm not quite sure what you mean, but certainly I think using a single visibility range property is a good idea. Perhaps we should look at integrating your routine to match a given fps value by adjusting cloud visibility range? Do we all agree that it makes sense to use cloud visibility range here, rather than random objects or such like? The advantage of using the cloud visibility range (and tree visibility range if I were to make it similarly dynamic) is that the effect of a change should be fairly subtle. Suddenly disabling (say) the urban shader will have quite a significant visual impact to the user. This probably needs a bit more thought. I'm also looking at ways to speed up the 3d clouds further by not rendering sprites at the back of the cloud (using the currently defunct cloud-density slider). The way this should be solved would be to generate Impostors of clouds where the view direction isn't changing much. Unfortunately the OSG implementation is Impostors doesn't work, and this is probably a lot of work. Yes, that's something I need to do. I think you've already implemented this in your codes. Can you point me at the best example shader/Effect? It's actually quite simple. You have: // Do the matrix multiplication by [ u r w pos]. Assume no // scaling in the homogeneous component of pos. 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; and I add just after that block gl_Position.z = gl_Position.z * zScale; (look into clouds-layered.vert where a value of 0.4 is hard-coded there). This is also now down (thanks to Torsten D. for the very fast merge). We now support a z-scale value which takes a value from 0.0 to 1.0. Default is 1.0. Great. Let me know what else you need and I'll put it near the top of my FG todo list. Wow :-) Thanks a lot! I think wrapping off and z-scaling are what limits my experiments most - otherwise I simply need time to catch up with texturing, parameter tuning, performance tests, but I'll keep you posted. Switching wrapping off is also supported, as of this morning. It is a global boolean property - /sim/rendering/clouds3d-wrap. It defaults to true. I haven't yet put any logic in to switch it on when global weather is enabled, so you'll need too manage it actively within Local Weather for the moment. That combined with Mathias' fantastic work to improve the speed of alt/mat checks via geodinfo() should mean you've got all you need. -Stuart -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Sat, 2011-08-06 at 14:43 +0300, thorsten.i.r...@jyu.fi wrote: Some visual impressions from the 3 cloud types I've converted to the new system so far here: http://www.flightgear.org/forums/viewtopic.php?f=5t=7358start=390#p132335 Stuart - please help: I get anti-shadowing for Stratus clouds, and I don't really understand why... Could this be a normal map problem (I believe it's possible to store the normal map in dds textures) Do we use normal maps for clouds ? Regards, -Fred -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Sat, Aug 6, 2011 at 3:50 PM, Frederic Bouvier wrote: On Sat, 2011-08-06 at 14:43 +0300, thorsten.i.r...@jyu.fi wrote: Some visual impressions from the 3 cloud types I've converted to the new system so far here: http://www.flightgear.org/forums/viewtopic.php?f=5t=7358start=390#p132335 Stuart - please help: I get anti-shadowing for Stratus clouds, and I don't really understand why... Could this be a normal map problem (I believe it's possible to store the normal map in dds textures) Do we use normal maps for clouds ? No, we don't use the normal maps for the clouds. Instead there are two shadings taking place: 1) Shading based on distance of the sprite to the sun. Effectively we compare a vector from the center of the cloud to the sprite location with the light normal. 2) Shading based on the vertical placement of the sprite in the cloud, so lower sprites are shaded more. This is controlled by the bottom-shade parameter. I suspect that it is the latter that is misbehaving. IIRC the bottom-shader is applied as a factor to the lighting, so using a value of (say) 0.1 should result in a dark cloud bottom. -Stuart -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Default 3d clouds in Local Weather
I've finally (I guess you all know the feeling of too much other stuff to do...) managed to start some tests with Stuart's Nasal interface for 3d cloud generation. Right now there is only a very rough placement structure and no real management (no removal, no distinction of cloud size, all same textures, no evolution,...). Basically, it works as advertized: http://www.phy.duke.edu/~trenk/pics/3dclouds-lw.jpg (it's not abundantly visible in the pic, but the layer shown differs from a normal layer in that it doesn't extend over the ocean, so the cloud position distribution is computed using the Local Weather MC code) In performance tests, I've been unable to see a significant effect (the default 3d clouds were maybe 5% better - but since we're comparing different number of cloudlets and different texture resolution, it's not clear to me what that actually means), I didn't notice any difference in tile building time (that's currently for Cu clouds dominated by terrain probing anyway) - but cloud movement in the wind is for free. I can't easily convert the whole system (texture sheets are not ready), but I'll write a parallel system for managing cloud generated with this technique and convert the system to that over time. Some issues: * naturally the clouds obey the visibility range as specified in the rendering dialog - which isn't far enough for my purposes. Can I simply override that number by a setprop() (will it snap back if someone opens the menu?) or is there a better way? * where's the switch to remove the boundary wrapping of the layer? * what property determines the visible motion? When I created the layer using Local Weather, clouds were moving with corrent heading and possibly also windspeed - so I assumed that it's wind settins as specified in /environment/ . However, I then switched Local Weather off, used the property browser to set windspeed to zero and assume the clouds would then stop - they didn't however. So I don't understand what I need to set to get the correct behaviour. * for layered clouds, I really would need the z-rescaling parameter *after* the rotation matrix has been applied (there's no way to do without, you're losing performance quadratically with area, so cloudlets need to be large without making layers ridiculously thick) - can we extend the parameters to be passed to the shader by that? Otherwise, I think this is very promising, and might be ready in a few months... * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Thu, Aug 4, 2011 at 8:15 AM,wrote: I've finally (I guess you all know the feeling of too much other stuff to do...) managed to start some tests with Stuart's Nasal interface for 3d cloud generation. Right now there is only a very rough placement structure and no real management (no removal, no distinction of cloud size, all same textures, no evolution,...). Basically, it works as advertized: http://www.phy.duke.edu/~trenk/pics/3dclouds-lw.jpg Glad you've managed to get the initial placement working In performance tests, I've been unable to see a significant effect (the default 3d clouds were maybe 5% better - but since we're comparing different number of cloudlets and different texture resolution, it's not clear to me what that actually means), I didn't notice any difference in tile building time (that's currently for Cu clouds dominated by terrain probing anyway) - but cloud movement in the wind is for free. Even though your previous testing showed no perf difference between the default 3d clouds and the models, I am slightly disappointed there isn't some intrinsic perf benefit to the default 3d versions. Hopefully I can improve the terrain probing to make a real difference in tile building time. I can't easily convert the whole system (texture sheets are not ready), but I'll write a parallel system for managing cloud generated with this technique and convert the system to that over time. That sounds like a very sensible approach. Some issues: * naturally the clouds obey the visibility range as specified in the rendering dialog - which isn't far enough for my purposes. Can I simply override that number by a setprop() (will it snap back if someone opens the menu?) or is there a better way? Yes, you can just use setprop. However, currently the slider maximum is 20km, so if the user opens the Rendering Dialog and then presses OK, it'll be reset to 20km. We should change the maximum to whatever you feel is sensible (40km?), and leave the default as it is (20km). However, I'm not sure we want to be over-riding the user's explicit preferences here. Perhaps we should look at integrating your routine to match a given fps value by adjusting cloud visibility range? * where's the switch to remove the boundary wrapping of the layer? Not implemented yet. As you've managed to get the general integration done, I'll try to get to it soon. * what property determines the visible motion? When I created the layer using Local Weather, clouds were moving with corrent heading and possibly also windspeed - so I assumed that it's wind settins as specified in /environment/ . However, I then switched Local Weather off, used the property browser to set windspeed to zero and assume the clouds would then stop - they didn't however. So I don't understand what I need to set to get the correct behaviour. From memory, it's from the appropriate /environement/layer[n]/ property. * for layered clouds, I really would need the z-rescaling parameter *after* the rotation matrix has been applied (there's no way to do without, you're losing performance quadratically with area, so cloudlets need to be large without making layers ridiculously thick) - can we extend the parameters to be passed to the shader by that? Yes, that's something I need to do. I think you've already implemented this in your codes. Can you point me at the best example shader/Effect? Otherwise, I think this is very promising, and might be ready in a few months... Great. Let me know what else you need and I'll put it near the top of my FG todo list. -Stuart -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Even though your previous testing showed no perf difference between the default 3d clouds and the models, I am slightly disappointed there isn't some intrinsic perf benefit to the default 3d versions. It's not been a fair comparison as such. Let me try building clouds from the same texture sheet (i.e. same texture resolution, same number of cloudlets) - that's the relevant measure. Also, don't forget the wind drift benefit - that's huge... We should change the maximum to whatever you feel is sensible (40km?), and leave the default as it is (20km). I think my current maximum is 45 km, and for much more one needs a different tile structure anyway, so if we could get 45 km that'd be nice. However, I'm not sure we want to be over-riding the user's explicit preferences here. I can turn it around and use the value specified here for the cloud visible range of the old system - if that's not too confusing. Perhaps we should look at integrating your routine to match a given fps value by adjusting cloud visibility range? Do we all agree that it makes sense to use cloud visibility range here, rather than random objects or such like? Yes, that's something I need to do. I think you've already implemented this in your codes. Can you point me at the best example shader/Effect? It's actually quite simple. You have: // Do the matrix multiplication by [ u r w pos]. Assume no // scaling in the homogeneous component of pos. 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; and I add just after that block gl_Position.z = gl_Position.z * zScale; (look into clouds-layered.vert where a value of 0.4 is hard-coded there). Great. Let me know what else you need and I'll put it near the top of my FG todo list. Wow :-) Thanks a lot! I think wrapping off and z-scaling are what limits my experiments most - otherwise I simply need time to catch up with texturing, parameter tuning, performance tests, but I'll keep you posted. * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Even though your previous testing showed no perf difference between the default 3d clouds and the models, I am slightly disappointed there isn't some intrinsic perf benefit to the default 3d versions. It's not been a fair comparison as such. Let me try building clouds from the same texture sheet (i.e. same texture resolution, same number of cloudlets) - that's the relevant measure. Also, don't forget the wind drift benefit - that's huge... And some benchmark tests with my Altocumulus texture sheet: With the same number of cloudlets and precisely the same texture sheet, Stuart's hard-coded clouds get about 20% more framerate out of my box. Even more impressive, the performance doesn't really degrade until I increase the number of cloudlets by a factor 10 (where I built a cloud from 2 textures previously, I can now use 20) - only when I use 100 sprites per cloud do I see a rather significant performance degradation (black magic??) So we get nicer clouds with better performance - I like that :-) (Don't get overexcited about a factor 10 more cloudlets though - since we distribute them into a volume in the end, the linear resolution of structures only grows with the cubic root of the cloudlets, so the actual improvement factor is more like 2.1... ) * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
