Border around procedural height map
After following Sebastian Lague's tutorial on procedural terrain generation, I then continued to add a manual limited generation script which works fine and allows me to control size.
I then wanted that specific sized area to have a water boundary fading off to the edge of the map, so usign Sebastian's falloff map example I made gradient maps to apply to each individual chunks.
These are created procedurally using Lerp between zero and one and then subtracting said map from the original heightmap of each edge chunk. This alos works and gives the border chunks a fading down of terrain to sea border.
The issue arises with adding the edge maps to the height map, it appears to leave a border of two pixels on the left and bottom of each chunk.
As you can see it's as though the height map is of a larger resolution than the edge map i created, which I have found to be true as in Sebastian's code he pluses two to eahc map chunk size when generating them, but simply applying a plus two to my gradient map genertation seems to not solve the issue.
Please find attached Sebastian's original code and my added code:
https://github.com/SebLague/Procedural-Landmass-Generation/tree/master/Episode%2012/Assets/Scripts
//This generates an array of values from 0 to 1 that form a gradient
public static float[,] GenerateTopGradient(int size)
{
float[,] gradient = new float[size , size];
float t = 0.001f;
float tIncrement = 0.005f;
for (int y = 0; y < size; y++)
{
float vertColor = Mathf.Lerp(1.0f, 0.0f, t);
for (int x = 0; x < size; x++)
{
gradient[x, y] = Evaluate(vertColor);
}
t += tIncrement;
}
return gradient;
}
Applying the gradient
//The gradient array is then subtracted from the height map array
if (edge == 2)
{
noiseMap[x, y] = Mathf.Clamp01(noiseMap[x, y] - topEdgeMap[x, y ]);
}
Any help would be much appreciated, I can add more detail as I'm sure will be needed.
Ins$$anonymous$$d of plugging in the size of your terrain heightmap into the gradient, have you tried plugging in the heightmap image height/width? I am almost positive heightmaps are size + 1 (its been a while since ive done procedural terrain generation) so if you have 512x 512 its actually 513x513, that would explain the 2 extra pixels
Hi thanks for the advice, I'm not sure how to quite take the dimensions of the texture, but I did try using the same array length, but no luck.
I'm starting to wonder if my gradientGenerator is wrong as I seem to be missing the bottom and left 2 rows and columns of pixels. If not that then it's something ot do with the size of the gradient array to the noisemap array as previously discussed.
I've added the code to GitHub (hopefully it's viewable) if you wouldn't $$anonymous$$d having a look at it I'd be hugely grateful.
https://github.com/Bugsy6/$$anonymous$$apGenerator
Thanks
When your noise map is generated you are adding 2 to the map chunk size width and height. I am guessing this was in the tutorial to aid in the tiling of the noise generated or something.
float[,] noise$$anonymous$$ap = Noise.GenerateNoise$$anonymous$$ap(mapChunkSize + 2, mapChunkSize + 2, seed, noiseScale, octaves, persistance, lacunarity, centre + offset, normalize$$anonymous$$ode);
but when you are generating your gradient, you are only plugging in the mapchunk size
GradientGenerator.GenerateTopGradient(mapChunkSize);
try changing it to this:
GradientGenerator.GenerateTopGradient(mapChunkSize + 2);
dont forget to add the + 2 to the bottom/left/right as well
So I just tried to log the results of the gradient array and got some intriguing numbers, baring in $$anonymous$$d that the array values should only be between 0.0 and 1.0 because of my Lerp:
9.419666E-11
1.786381E-06
4.037441E-07
1.292174E-07
2.065507E-08
All these random numbers take up the first 4540 slots of the 58081 array.
Any idea why these strange numbers would be being added? After these numbers it starts from 0.000001 and goes up to 1.0 as it should.
these are fine, the number they represent does not look how it reads without understanding what it actually is. Its scientific notation. Those numbers are just very very very small
Prism switches to scientific notation when the values are very larger or very small. For example: 2.3e-5, means 2.3 times ten to the $$anonymous$$us five power, or 0.000023. 4.5e6 means 4.5 times ten to the sixth power, or 4500000 which is the same as 4,500,000
9.419666E-11 = 0.00000000009419666
1.786381E-06 = 0.000001786381
4.037441E-07 = 0.0000004037441
1.292174E-07 = 0.0000001292174
2.065507E-08 = 0.00000002065507
Ah of course that makes sense, so not the issue (darn! lol).
I can't seem to make the gradient map expand to cover all the noisemap no matter what I change. If I drop the +2 off the noisemap it then matches the gradient map perfectly with no border, but then I'm left with a gap between each terrain chunk as the chunks are smaller.
Thanks for all the help by the way it is really useful, having been staring at this issue on my own for hours a bit of help is great.
Answer by Bugsy6 · Aug 31, 2016 at 03:24 PM
Found the issue!!
It was being caused after the noisemap and the edgemap were combined, they then are passed into a colormap and matched to their correct height and as such their colour. The issue as b1gry4n rightly pointed out was to do with the sizing of the arrays. The noisemap had a size of 241 so I upped the egdemap to also have that, but never increase the colormap, the thing that actually implemented all this data to the screen!
Thanks for you help b1gry4n, always helps to talk it out with some.
Your answer
Follow this Question
Related Questions
Diamond Square Algorithm Problems 0 Answers
How to spawn in loop like snail but in square 0 Answers
Procedural Terrain Diamond Square Height Issue 0 Answers
Can you use the superformula in unity? 0 Answers
Generate Polygon Plane from Array 0 Answers