erik wrote in Tue Aug 15, 2017 8:30 am:For some operations a value below zero or greater than 1 could cause these kinds of problems, even if it is just a marginally small fraction outside the 0.0 .. 1.0 band like 1.000001. This could be handled differently between drivers if one clamps it by itself an another relies the inputs are valid.
That said, it could still be just a driver bug.
Erik
In my programming experience say is a "drive bug" is how to say i do not know so i do not do anything ...!
In short, it is not a great answer sincerely and does not solve the problem. In this case, it seems odd to me that it is a trivial drive problem because even though I replace the "smoothstep ()" code with the equivalent function ... I get exactly the same problem!
This fact should make us think differently and look for the problem elsewhere. For example, if I replace:
- Code: Select all
// distance to fragment
float dist = length(relPos);
With the value of a uniform float variable such as the snow dimension: "
uniform float snowlevel;" Getting this expression:
- Code: Select all
// distance to fragment
float dist = snowlevel;
You see that when the variable is negative you have the error (cyan color and vibrating black spots) otherwise, agriculture seems to be correct.
This obviously makes me think of some problems related to the length (relPos) function that determines the length of a vector named "relPos".
Could this function, in other types of drives, correctly handle something that in the case of an Intel for Linux (?!) Drive is not handled in the same way, or is this the correct function to get the distance?
Reading the distance determination problem, I found the "distance ()" function that finds the distance between two points I tried this way:
- Code: Select all
// distance to fragment
// float dist = length(relPos);
float dist = distance(localPoint, relPos);
It works the same way as the function: "float dist = length(relPos);" so the problem is elsewhere!
My impression is that the distance value varies too fast to handle the next interpolation that is the "Transition". In fact, if I remove the "Transition" shader option with a value of less than 5 (it seems to me that it works by simulating a kind of diffusion effect or fog ...), everything is back in place!
When changing the code line:
- Code: Select all
texel.rgb = mix(texel.rgb, grain_texel.rgb, grain_strength * grain_texel.a * (1.0 - mix_factor) * (1.0-smoothstep(2000.0,5000.0, dist)));
with this code:
- Code: Select all
texel.rgb = mix(texel.rgb, grain_texel.rgb, grain_strength * grain_texel.a * (1.0 - mix_factor) );
It reduces the variation frequency of the "texel" variable, which then becomes fragColor (via the fragColor = color * texel + specular; statement)
This explains why the problem is becoming smaller at high altitudes and at lower angles, in situations where the frequency of distance variation tends to shrink.
How to reduce or eliminate the problem1. I think it's okay (however, it is possible to observe some artifact) to remove "* (1.0-smoothstep (2000.0,5000.0, dist))" is the one that works best and does not seem to give artifacts. In this case, the local variation of the "texel" is rather contained and is not re-evaluated on the "Transition" shader process ".
2. Much more radical is to replace "agriculture-ALS.frag" with another program, I used "terrain-ALS-detailed.frag" renaming it with "agriculture-ALS.frag". In this case, everything works similar at "agriculture-ALS.frag" but some features are not exploited.
I personally prefer the first solution, but maybe in time, putting hands to "transition.frag" can also solve the problem for less powerful cards such as intel.