> (*)No it's not bad design, it's a conscious hack around the state that > the environment interface was in when the shader was developed.
Something like a property rule or a Nasal script outside the shader would have done the trick as well... But I'm not arguing why it's done the way it is, and I don't want to talk down the great work that has been done with the water shader, I think we agree that a proper weather/environment interface is the way to go. > It would be good to make it Weather system agnostic from the > effect/shader side of things, don't you think? No. If you want to render atmospheric light effects, the shader needs to know the structure of the atmosphere and at what altitude the light attenuation due to clouds occurs, and the only system which has this information is the weather system, so the effect side can not be agnostic to what goes on in the weather system. It should be agnostic to how the weather system internally determines and manages these parameters, but I don't think we need to argue that passing a single 'ground light intensity' is superior to passing 5 cloud layer coverages and determining ground light intensity from that inside the fragment shader. Currently the issue is that I determine many parameters characterizing the light attenuation in the atmosphere dynamically in Advanced Weather but insert default values into environment.xml which are never changed by Basic Weather, so Basic Weather runs with lightfields, but doesn't produce realistic results because the defaults aren't ever adapted to the actual weather situation. If so desired, someone can insert computations/property rules/whatever... into Basic Weather to set these things dynamically - that is what I'm talking about. I don't see the value in inserting a heuristics for determining such parameters dynamically from the native parameters of Basic Weather inside the lightfield shaders, because that degrades performance quite a lot, and I have spent weeks optimizing the computations to get decent performance. In my view, this heuristics should be outside the shaders. > Not when the varying number is limited. So you gain a bit of speed, but > you lose a lot of compatibility.(think ATi/intel, or OSS drivers for nVidia) You gain a lot of speed. But what is the max. allowed number of varying? It's difficult to code anything when there is some upper limit, but I just don't know what it is. Cheers, * Thorsten ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
