On Friday 13 April 2012 08:45:26 Renk Thorsten wrote: > > (*)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. You got me wrong there, I meant that what the shader sees in the proerty tree should be weather system (basic or advanced) independent. The shader doesn't need to know if the value comes from either, it just needs the value to be there no matter one's preferences for weather simulation. So in short, a common interface between the various weather implementations and the rest.
> > 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 To be safe you need to limit yourself to 32 float varyings. Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc. Regards, Emilian ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
