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] specular reflections, where did they go?
The option was removed from the Rendering Options dialog because it became useless, after our switch to OSG. Like Heiko mentioned, such reflections are taken over by shaders nowadays. http://code.google.com/p/flightgear-bugs/issues/detail?id=174 Gijs -- 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] specular reflections, where did they go?
>> Hiwhere did that go? nothing alike in gitthanks >> To get the fuselage reflections enable Specular reflections on >> >> objects in View -> Rendering options.--- ?? Are you sure you are using the latest FGFS-version? Seems not To get the specular reflections just enable the material-shader in the rendering-view! Btw- we have a bug-tracker since a while... still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- 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, 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
[Flightgear-devel] specular reflections, where did they go?
Hiwhere did that go? nothing alike in gitthanks To get the fuselage reflections enable Specular reflections on objects in View -> Rendering options.- 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
