Thorsten wrote:
>
> > Plus, if you neglect the curvature effect in every relevant vector,
> > the rendering artefacts at the tile boundaries must go away, because
> > the differences in rendering geometry between tiles go away, and
> > they're the only thing which can introduce the artefacts in the first
place.
>
> Turns out I was wrong here - found and eliminated the tile boundary bug.
>
> The problematic thing seems to be refTex in the following code block of
the
> water_sine fragment shader:
>
> //load reflection
> vec4 tmp = vec4(lightdir, 0.0);
> vec4 refTex = texture2D(water_reflection, vec2(tmp)) ;
> vec4 refTexGrey = texture2D(water_reflection_grey, vec2(tmp)) ;
> vec4 refl ;
>
> if(cover >= 1.5){
> refl= normalize(refTex);
> }
> else
> {
> refl = normalize(refTexGrey);
> refl.r *= (0.75 + 0.15 * cover);
> refl.g *= (0.80 + 0.15 * cover);
> refl.b *= (0.875 + 0.125 * cover);
> refl.a *= 1.0;
> }
>
> If refTex is replaced by refTexGrey, the problem goes away (but the sea
> becomes grey even in sunshine), so there's something odd with the texture
> (?). But the whole block is actually obsolete. It basically loads a
128x128
> homogeneous grey and a 128x128 homogeneous white texture, samples
> both, since both textures are homogeneous it finds the same color every
> time no matter where it is sampled, then chooses one of the textures and
> discards the other one to determine an (rgb) vector to be modified for
cloud
> cover.
>
> Apparently we have the GPU power and texture memory by the bucketful
> so that we can use that procedure to determine a color vector. On the way,
I
> also eliminated a few normalize(some_vector); statements of vectors which
> were already normalized before passing them, so the whole shader has
> other obsolete steps as well.
>
> Not that I would be an expert in shader design, but about the same output
> (without tiling artefacts) can be achieved in a two-liner:
>
> // basic water color
> vec4 refl = vec4 (0.148, 0.27, 0.3, 1.0);
>
> // de-saturate for reduced light
> refl.rgb = mix(refl.rgb, vec3 (0.248, 0.248, 0.248), 1.0 -
smoothstep(0.4, 1.0,
> scattering));
>
> That has the neat side effect that we could even pass the basic color as a
> uniform from outside the shader and change the water color smoothly from
> the shore to deep ocean and dependent on latitude (the weather system
> happens to know if there's terrain in the vicinity or not).
>
> Feel free to do whatever you want with the information provided, after all
> it's open source...Oh, and why do I read so often that coding in Nasal is
a
> problem for the performance actually?
>
I don't think your analysis can be correct; are you saying that the
surrounding if.. else statement is a non op? The intention is to set the
reflection colour as white if cover >= 1.5 else set it to grey. AFAIK it
works that way as well. Something wrong with the texture? I don't think so.
It also works with your modification. If we had a better input with which to
set the sea colour to reflect the sky conditions then I would have used it.
It's all an attempt to emulate the cloud cover over the sea and stop it
being a lovely blue in the middle of a storm. I don't see that your
modification honours this intent. The basic colour of the sea is, without
the effects of particulates and phytoplankton in the water, salinity,
reflection from the bottom and other factors, a surprisingly dark blue, but
when there is cloud cover present the sea is more grey.
Proximity of land is only a very rough guide to depth of water. You can go a
long way from shore in the North Sea without finding deep water, but the sea
gets very deep very fast off the Azores. If we can represent all this
better, then I'm all for it.
Vivian
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
