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
