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
