- The Perlin noise for the overlay texture and hires textures leaves large-enough empty areas to allow tiling to appear
- The areas covered by the overlay texture are nowhere near half of the total
- Large areas have no hires texture at all
- As a result, the optimum real-world size for the texture is at least 4kmx4km
Have a look at these pictures, taken from 60000ft at 32S, 152.5E. Instead of the overlay and hires textures I have used the "unknown.png" texture for clarity (so 4 squares red-white-red-white is a single texture swatch), and both the bush and unknown textures are specified to be 2000x2000m. I have deliberately not tried to hide the boundaries of the bush texture.
The stock distribution, with a tweak in terrain-ALS-ultra.frag to provide closer to 50% coverage:
- Code: Select all
mix_factor = smoothstep(0.45, 0.49, nSum);
instead of
- Code: Select all
mix_factor = smoothstep(0.50, 0.54, nSum);
With an even bigger version of the above tweak, but at a notionally double frequency obtained by changing
- Code: Select all
nSum = 0.18 * (2.0 * noise_2000m + 2.0 * noise_1500m + noise_500m);
to
- Code: Select all
nSum = 0.18 * (2.0 * noise_1000m + 2.0 * noise_750m + noise_250m);
My feeling is that the top picture has too much tiling evident in the non-overlay area, and the second one is acceptable, just. So therefore either the "standard" texture size for materials that could stretch for long distances should be 4kmx4km, or the overlay noise should be doubled in frequency. I note that the Brazilian textures often use 4km as the texture border size, perhaps because of this, however, almost all other regions of the world stick with 2kmx2km. I think 2km x 2km is desirable for improved resolution at low altitudes, this means that the hires texture is 500mx500m which is pretty nice.
So my questions:
- Would there be any issues with adjusting the Perlin noise in terrain-ALS-ultra.frag as I have done above to make 2x2km the optimum size?
- Would there be any issues adjusting the mix factor as I have done above? Is it possible that other coordinates and/or GPUs will work in the opposite direction and overweight the overlay areas?
- Is there any appetite for a better-behaved noise function (see below) at the expense of slightly more GPU time?
As a coda, here is the same area using a more modern Open Simplex noise with notionally the same noise frequency mix as the stock FG shader[*]. Clearly much more effective across the board in detiling and mixing in hires, and there are no signs of a grid-like pattern emerging (not that that is really an issue for this application). This could be added to noise.frag tomorrow as an alternative noise function, as it is licensed by the "Unlicense" - I just copied it wholesale from the internet - and I suspect any tiling issues would be largely a thing of the past.
[*] I say the same noise frequency mix but that is assuming that Open Simplex noise "repeats" on an integer grid; however I don't understand the noise function well enough to know if this is the case.