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 (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
>
--
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
