Thorsten > -----Original Message----- > From: thorsten.i.r...@jyu.fi [mailto:thorsten.i.r...@jyu.fi] > Sent: 01 October 2011 11:20 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Atmospheric haze modelling > > > Hi Curt, > > thanks for your comments and explanations. > > > We always recognized potential difficulties with blending the sky into > > the terrain. The original design used the fog color as the opengl clear > > color (the color that the display buffer is cleared to before starting > > to draw any > > of the frame). We blended the bottom of the skydome into the fog color. > > And then made sure we drew enough tiles to extend at least to the fully > > fogged range in all directions. This allowed us to "hide" the seam > > between the sky and the ground in the fog/haze at the horizon. > > Yes, as far as I can see, that's the only way this can be done and why the > scattering skydome shader never worked with the default terrain shading. > > As a side note: I've observed that we're currently fading into fog with > > exp(-d^2/vis^2) > > where d is distance and vis is visibility where I believe the physically > correct behaviour would be > > exp(-d/vis) > > Now, the only reason I can think of to do the square fading is that you > really get a hard cutoff after d = vis and minimize the amount of terrain > tiles you need for a seamless blending. On the other hand, the square > fading brings less fog for d< vis than there should be, and actually many > optical integrals rely on the factorization transmission (layer a) * > transmission (layer b) = transmission (layer a + layer b). So I would > prefer linear exponential fading. If the hard cutoff is the only rational > for square fading, then I'd propose to use > > exp(-d/vis - 0.1 (d/vis)^6) > > instead which for any distance d < vis gives linear fading and then has a > cutoff as efficient as square fading. Please let me know if there's any > other reason why the current code is as it is! > > > > One problem: tall > > mountains in the distance would be fog colored and extend visually up > > into the blue part of the skydome and look weird -- so the original > > design worked pretty well, but wasn't perfect. > > I would guess it is visually acceptable to let mountaintops never blend > into the horizon fog. In my current design it would be possible to do so, > provided the visibility passed to the tile manager is a clever combination > of ground and aloft visibility. > > Maybe that's actually the general solution - pass a function of different > visibility properties used by the shader to the tile manager. The simplest > solution is to pass the maximum of all visibilities, but that may load > more than one ever needs, so probably an angular weighted version > dependent on current altitude would be more useful. I can work the math > out... as long as it's possible to go for a solution like that. > > > Oh, and we also had some additional code that would change the fog color > > depending on your view angle relative to the sun ... so at sun set/rise > > the fog color would be oranger/redder looking at the sun versus > > looking away from it. > > I'm currently using gl_LightSource[0].diffuse as fog color - to the degree > that sunlight light changes, my version inherits that (seems to be working > fine so far). > > > So definitely we should try to figure out how to make your sky model > > blend with the terrain some how. > > It *seems* to be doing fine now after I introduced the harder fogging > cutoff - above the ground layer, it still uses /environment/visibility-m > to keep track of this part of the optical integrals, so the amount of > tiles loaded is actually sufficient - but at 50.000 ft or so I rountinely > have visibility values of 100 km. For me, Flightgear renders that still > stable and reasonably fast (I tried Custom France scenery, Hawaii as well > as Pacific Northwest as test cases), and only above 140 km I get unstable > behaviour (some of my Blackbird Screenshots were rather difficult). But on > slow machines, this'd probably be a show-stopper. But that's not a shader > problem but related to the weather code - that can be instructed to > provide a cutoff for visibility that is never exceeded. > > > One more thought while I'm writing. The current scattering effect > > skydome > > has a glitch/seam at the azimuth. Depending on the time of day it is > > more > > or less visible. It can be really ugly, I'd love to get this fixed if > > you happen to stumble on what's causing it as you play with all > > this code. > > I know... > > I'm really not a shader person, I have just one idea as to what the cause > might be (?). > > I've often observed that the edges of scenery tiles with the water > reflection shader have different colors. I have also on occasion seen fog > artefacts at just the same position. My theory as to what happens is that > the vertices in this case (= the tile edges) are rather far apart, so when > the vertex shader is asked to compute an angle for reflection or light > scattering or fogging, it must interpolate over a large area because the > vertices are far apart. If it interpolates linear, but the quantity to > interpolate is (as in this case) non-linear, then in a certain angular > regime there must be artefacts. > > In this case, there'd be nothing wrong with the shader, the vertices would > just too far apart to get it right. > > Now, I have no idea how many vertices the skydome has or if that is indeed > the problem - it's just my working hypothesis based on what I see. > > ThorstenB wrote: > > > And it'd be rather complicated to implement any other tile loading > > method instead of the current concept of loading all tiles within a > > certain range. The tile loader lives in a simple 2D world. It knows > > nothing about elevation of certain tiles etc. > > But can it be made to use a function of all visibility parameters used by > the shader? For zero elevation the problem is not difficult to solve, the > terrain shader basically does it for every vertex in the scene per frame > anyway - just solving it once every couple of frames for the tile manager > shouldn't be an issue, even Local Weather's Nasal code could do it. > > But we probably have something like min_elevation and max-elevation for > the scenery tiles we have already loaded, so these can be used to even > optimize the guess when the next tile might become visible. > > It'd be so cool to be able to load only the mountains sticking out of > haze... But I think we can do well enough without that gimmick. > > In completely different matters: > > Does anyone know of a short writeup of how the shader coordinate systems > are defined? I waste most of my time debugging code to find out that a > vector never was what I thought it should be because I started with the > wrong coordinate system, and that's starting to annoy me. Once I have the > vectors right, then everything works much faster... > > Thanks in advance! > > * Thorsten
Emilian and I have been working on the water shader, and have run into some show stoppers caused by the lack mf vertices in the ocean tiles - there are just 4 so far as we can see, so the junctions between tiles always show up as you speculate. It might be we can do something about this in due course. Vivian ------------------------------------------------------------------------------ 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
