Re: [Flightgear-devel] Atmospheric haze modelling
Vivian, - Mail original - > 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. You can use the geometry shader to amplify the geometry if you want to. I used it to build forests "walls" in the landmass shader. Regards, -Fred -- 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
Re: [Flightgear-devel] Atmospheric haze modelling
On Sat, Oct 1, 2011 at 11:13 AM, Vivian Meazza wrote: > 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. Hi Vivian, Another interesting thing is to turn on wireframe rendering and you can see exactly where the triangle seams are in the ocean surface. I noticed visual seams in the sea foam and reflections that weren't related to the underlying structure and seemed more likely to be a texture wrapping problem (i.e. one of the textures wasn't fully tileable?) Either that or there is a texture coordinate problem introduced in the latest water effects code. The original ocean auto-gen code was intended to keep things simple and keep polygon counts low. We certainly could generate more vertices in the ocean auto-gen code. That shouldn't be too hard and probably is worth doing now with computers that could easily handle a few more polygons. The challenge would be mating these autogen tiles up with adjacent terragear-generated tiles that are part land part ocean. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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
Re: [Flightgear-devel] Atmospheric haze modelling
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
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 t
Re: [Flightgear-devel] Atmospheric haze modelling
On Thu, Sep 29, 2011 at 1:10 PM, ThorstenB Well, I have little to add. I can just confirm your and Curt's > descriptions: yes, the tile loader reads the visibility property. When > is has increased above a certain threshold (or when the position has > moved into another area), it starts loading more scenery. And it always > requests all tiles within the range defined by visibility (limited to > the max-lod range though). It could be changed easily to watch for some > other property - such as a specific "ground visibility property", when > that's provided. But yes, loading scenery is a major performance/memory > factor - so we shouldn't be loading much more scenery than we do now - > unless the fundamental concepts are also improved (such as better LOD > support for scenery tiles). > 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. > Just to add a couple more bits of information. The tile loader knows (or can compute) the exact dimensions of the tiles. I thinks in terms of "square" rings if that makes sense. There is the tile which you are over right now. There is a ring of 8 tiles surrounding your current tile. There is a ring of 16 tiles surrounding that and a ring of 24 tiles surrounding that. 3x3 = 9 - the inner tile = 8. 5x5 = 25 - the 3x3 block = 16, etc. So the tile loader loads the 'current tile' which you are over the top of it and proceeds to load as many surrounding 'rings' as needed to cover the current visibility distance. As Thorsten B. points out though ... there is a memory/performance/disk-io price when loading tiles. And if we are pushing scenery complexity at the same time as pushing visibility out, this price will grow exponentially ... so it's worth paying attention to. Regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric haze modelling
On 29.09.2011 10:21, James Turner wrote: > Hopefully ThorstenB will have some comments, since he's the person > who most recently touched the tile-loading code, which is by far the > most sensitive thing (in terms of system performance) for how we > compute visibility. Well, I have little to add. I can just confirm your and Curt's descriptions: yes, the tile loader reads the visibility property. When is has increased above a certain threshold (or when the position has moved into another area), it starts loading more scenery. And it always requests all tiles within the range defined by visibility (limited to the max-lod range though). It could be changed easily to watch for some other property - such as a specific "ground visibility property", when that's provided. But yes, loading scenery is a major performance/memory factor - so we shouldn't be loading much more scenery than we do now - unless the fundamental concepts are also improved (such as better LOD support for scenery tiles). 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. 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-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric haze modelling
On 28 Sep 2011, at 21:14, Curtis Olson wrote: > I suppose it would make sense to grep through the code, but as far as I know, > the primary uses of the visibility value is to properly set the OpenGL fog > parameters and determine how many rings of tiles to load centered on the > current location. >From a software engineering perspective, it would be great to have a >centralised, explicit place where visibility is managed, and especially the >purpose of visibility - since what's needed for scenery loading vs 'fog' >(atmosphere effects) vs weather loading vs AI / multiplayer ranges may not all >agree, but most of those things currently look at the global visibility >property and make some guesses, or apply some heuristics based on that number. Unfortunately, going through the code to find out what will break, is an ugly job - as you have probably realised. In the short term, I think most systems need a 'how far away do I conceivably need to load / simulate items' metric - not necessarily in meters - but really that should be dependent on the observer position of course. Hopefully ThorstenB will have some comments, since he's the person who most recently touched the tile-loading code, which is by far the most sensitive thing (in terms of system performance) for how we compute visibility. James -- 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-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric haze modelling
Hi Thorsten, I haven't seen any other developers reply yet so let me jump in and say what I can. First of all the screen shots look spectacular -- really well done! It also looks like you've done a very nice job of blending the clouds with the sky dome. On the subject of scenery and visibility: Originally the visibility range was used to properly set the opengl fog parameters. It was also used by the scenery paging engine to decide which tiles to load. It would load just enough to cover the visible range, but no more. (There is also a scenery cache so once a tile is loaded it can hang around for a while in case the pilot does a 180 and needs to back track.) There are a couple other things to consider. OpenGL has a near clip plane and a far clip plane. We hard coded the far clip plane to be something like 100km ... far beyond the range of anything anyone would ever want to draw. For what it's worth the far clip plane can be moved out further with little adverse affect on z-buffer precision. It is the near clip plane that significantly impacts z-buffer precision. Also our sky dome is sized to be so big it would always enclose anything we would ever possibly want to draw. 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. 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. 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 suppose it would make sense to grep through the code, but as far as I know, the primary uses of the visibility value is to properly set the OpenGL fog parameters and determine how many rings of tiles to load centered on the current location. Your visual results are quite compelling. The sky looks incredible, and very realistic (not that the current sky doesn't look really good sometimes too, but obviously your approach covers a broader range of conditions very well.) So definitely we should try to figure out how to make your sky model blend with the terrain some how. 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. Hope that helps encourage you! It would be great if users were *begging* us to do the next release ahead of schedule because of all the new cool effects. :-) Curt. On Tue, Sep 27, 2011 at 5:46 AM, Thorsten wrote: > > I've spent some time over the last days to add a model for an optically > thick regime to the skydome scattering shader. I am rather happy with the > model (as far as the skydome is concerned, it now renders visibilities > down to 1000 m in a plausible way, the transition to the optically thin > regime looks nice and you get spectacular sunsets - see > > > http://www.flightgear.org/forums/viewtopic.php?f=47&t=11274&start=90#p137694 > > for some pictures). > > The problem is that making this really work means rethinking some concepts. > > What I have done so far is adding a layer of constant optical thickness > from ground level up to some given altitude. That particular case has an > analytic solution and hence computes rather fast - I think it's much > faster to render an arbitrary density distribution as 10 subsequent layers > of constant density each than to put the numerical integration in > explicitly. > > What that means is that visibility is no longer a parameter which changes > with your loaction - the visibility at the ground is tracked and > determines in an essential way how the scene looks - even if you have 100 > km horizontal visibility at your current position, what you see on the > ground depends on the angle under which you view the ground haze layer and > may be much less. On the other hand, this means that mountain ranges can > stick out of the ground haze and be visible much further than the terrain > just below. Ultimately, in this concept the notion of a single visibility > determining everything is gone and instead you specify optical properties > of the atmosphere in certain regions. > > It's probably obvious why this is tricky - the single visibility parameter > currently governs many other things (sc
[Flightgear-devel] Atmospheric haze modelling
I've spent some time over the last days to add a model for an optically thick regime to the skydome scattering shader. I am rather happy with the model (as far as the skydome is concerned, it now renders visibilities down to 1000 m in a plausible way, the transition to the optically thin regime looks nice and you get spectacular sunsets - see http://www.flightgear.org/forums/viewtopic.php?f=47&t=11274&start=90#p137694 for some pictures). The problem is that making this really work means rethinking some concepts. What I have done so far is adding a layer of constant optical thickness from ground level up to some given altitude. That particular case has an analytic solution and hence computes rather fast - I think it's much faster to render an arbitrary density distribution as 10 subsequent layers of constant density each than to put the numerical integration in explicitly. What that means is that visibility is no longer a parameter which changes with your loaction - the visibility at the ground is tracked and determines in an essential way how the scene looks - even if you have 100 km horizontal visibility at your current position, what you see on the ground depends on the angle under which you view the ground haze layer and may be much less. On the other hand, this means that mountain ranges can stick out of the ground haze and be visible much further than the terrain just below. Ultimately, in this concept the notion of a single visibility determining everything is gone and instead you specify optical properties of the atmosphere in certain regions. It's probably obvious why this is tricky - the single visibility parameter currently governs many other things (scenery tile loading springs to mind, objects,...). It's also tricky but crucial to apply the same technique to the terrain, otherwise the horizon line never matches up. So, at this point, I thought I better start asking for some thoughts before finding myself in a difficult place. * Is this something we want to do at all (it's reasonably obvious that I want to do it, but I don't think I can develop this as a harmless addon mode)? * Is there a good way to implement this concept *without* causing too many problems for global weather or the default terrain rendering (for instance, right now, my version of skydome.vert and skydome.frag only run with global weather when some parameters are manually entered via property browser - not user-friendly... but in principle the parameters necessary could be computed from weather info), or is it acceptable that only non-shader rendering stays how it was, but shader-based rendering gets all changed? Or that global weather can't use the skydome shader any more? * Is there a way to implement this without altering every single terrain type/object/... shader and to put the equations for fading of objects with distance into one single place where they are easily updated? Some thoughts are very welcome at this point (possibly also some help in the implementation - I can derive the math quite alright, but to get GLSL to run for me takes an awful lot of time - I'm essentially learning by reverse engineering and trial and error). 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-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
