Hi Thosten,
On Saturday, May 21, 2011 13:45:50 ThorstenB wrote:
> Am Freitag, den 20.05.2011, 19:06 +0200 schrieb ThorstenB:
> > On 19.05.2011 20:38, Lauri Peltonen wrote:
> > > So the solution is either change the clear color to what it was, or
> > > make it ramp linearly to black or something with altitude.
> > >
> > > Or change simgear/scene/sky.cxx around line 117 (repaint method), there
> > > is a
> > > if ( effective_visibility> 1000.0 ) {
> > >
> > > ...
> > >
> > > } else {
> > >
> > > // turn off sky
> > > disable();
> > >
> > > }
> >
> > My suggestion: we try removing the condition now and see if anyone sees
> > new issues.
>
> After looking into this more closely, I revert my suggestion. Not a good
> idea to remove the condition. It's there for several reasons:
> * Switches off sun/moon/stars when visibility is low. Looks odd when
> there's a bright (red) sun or stars in very dense the fog - so we have
> to keep this.
> * Also switches off the blue (or colorful) sky dome at low visibility.
Well, I believe that the reason for that switch was, that you cannot see the
sky anymore if you have this small visibility.
> Before the patch, the clear color was synchronized to the current fog
> color:
> SGVec4f clearColor(l->adj_fog_color());
> Hence, switching off the sky dome turned all empty bits into fog -
> including the entire sky.
>
> So, we need something in the scenery which can be painted with the fog
> color. For anyone interested in working on it (Lauri? ;-) ) here are
> some options:
>
> * Change the sky dome itself so its color can uniformly be switched to
> "fog color" when visibility is low, and then (the easy part ;-) ) move
> the sky dome element above the switched sky group (so it's not affected
> when the other sky elements are switched off).
>
> * Switch the sky dome off but introduce/enable a new "fog dome" at low
> visibility (painted with the fog color).
>
> * Or, change the implementation of FGLighting::adj_fog_color
> (and ::sky_color) to return black as the current fog/sky color at high
> altitudes - and keep all the other stuff.
>
> The last option is probably the easiest. But not sure what the "right"
> solution was - maybe an osg/scenery expert can comment? (Tim/Mathias?)
>
> I've reverted the original patch for now, since we'll need to work on
> the particular renderer.cxx lines anyway to solve the issue - and there
> were also a few minor "technical" things (see revert-commit comment), so
> we should provide a better patch once we know how to solve the fog issue
> altogether.
Ok, I believe that reverting that clear color change is a good idea. So, the
current state is ok. IMO.
I tried to keep out of the scenegraph/rendering discussions lately. But for
that topic, I have some thoughts. Nothing for this current upcomming release,
but may be for the next round:
At first, I like the O'Neil sky very much. This is the easiest variant of the
scattering shader approaches. This one is a good starting point!
For something more advanced see http://hal.inria.fr/inria-00288758/en/ for
example :-)
One problem with the current view ray dependent sky colors from the O'Neil
approach is that the scattering integrals really vary with the views
direction. That means we do not have a uniform fog color over the whole scene
any more. As a result the scenery that is rendered with a static fog color
does no longer integrate seamless with the sky as it did before.
The next problem is the sky dome geometry that is somehow limiting the
possible eye points to be within the usualy flight altitudes.
Whatever we do here stays some kind of workaround for the skydome/static fog
color being something unapropriate for the job.
I think that we should at some time switch to a two pass rendering for the
scene:
At first render the scene without fog and sky and with a black clear color into
an fbo.
Then, in a second pass, use the color/depth information from this first render
pass' fbo and render the sky/fog on top of this pregenerated scenery picture.
The sky/fog is drawn using a screen aligned quad that has the sky shader
attached. Using the original projection matrix in a shader uniform and the z
values from the first render pass' depth texture, the ray of sight is computed
and used for the O'Neil sky/fog computations. If the z value is the depth
clear value, we assume that we need to intersect the ray of sight with the
atmosphere boundary as it is done for the sky colors. If we have a finite z
value, compute the scatteing from the eye to the color fragement and
underblend the fragment color from the first rendering pass.
Our depth partitioning implementation will require the first pass to happen for
two parts of our scene. One being the far part of the scene, one being the
near part of the scene. So, the composition/sky/fog shader will have two color
and two depth textures from the two depth partitioning passes as an input.
The three color values (far scene, near scene, fog) need to be blended
together in the correct order.
So, some work there, but that will solve the sky problems also for the out of
atmosphere cases.
Greetings
Mathias
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
