
### Terrain: height + slope blending

I've been working on getting the height modification to work. And also height + slope blending to work the same way across clipmap rings, patch borders and while the camera moves.

---

### What we're building on

We're rendering terrain with a geometry clipmap: multiple LOD rings follow the camera, and each ring is the same grid scaled per LOD. The world is split into patches, and each patch provides:

- height data
- splat weights / material control
- per-material inputs (albedo/normal/ORM + parameters)

This setup is great for coverage and performance, but it also makes it easy to run into sampling problems. Patch borders and ring boundaries are amkes sampling a little more complicated because of discontinuities in how data is laid out, even if the world itself is continuous. 

### Height mips: matching the sample to the ring scale

Early on I was sampling height at full resolution everywhere. Close to the camera it looked fine, but the coarse rings cover a lot of ground per vertex, and they were still reacting to tiny height details that show up as artifacty shimmer during movement, which I don't want since TAA is already an issue.


To fix that, we can generate a mip chain for the height field and choose a mip based on the ring's world-space scale.

which should make:
- coarse rings sample a blurrier height
- reconstructed normals stop reacting to tiny texel changes far away
- slope/cliff decisions become more stable as the camera moves

### Patch issues

Patch UVs behave nicely inside a patch, but they reset at the border. That means the UVs jump from 1 back to 0 when we cross into the next patch.

I switched to taking derivatives from world-space XZ and scaling them into patch UV space. which helped a bit but still isn't enough, however, the seams have largely been elimanted and we use the same sampling. 


### Slopes blending

We want to blend the terrain between slopes and across patch regions seamlessly.

Initially the slope blending was quite unstable, and that was because i was feeding a noise normal map which i thought I could get away with, but it just doesn't look right. Instead now I reconstruct a geometric normal from the height field by sampling around the current point and building a gradient. But we need to make sure that the sampling offset is consistent in world space and we need to make sure the height sample itself comes from the right mip otherwise it would look bad.

### Height blending

With slope somewhat stable, we need to fix the height blending so layers settle naturally instead of looking like a flat mix. I've exposed these variables in the shader
- blend strength
- sharpness
- bias
- contrast

like this: 
```c++
vec4 ApplyHeightBlend(vec4 w, vec4 h)
{
    float strength = clamp(uCB.HeightBlendParams.x, 0.0, 1.0);
    if (strength <= 0.0) return w;

    float sharp = max(uCB.HeightBlendParams.y, 0.001);
    float contrast = max(uCB.HeightBlendParams.z, 0.001);
    float bias = uCB.HeightBlendParams.w;

    h = clamp((h - 0.5) * contrast + 0.5 + bias, 0.0, 1.0);

    float maxH = max(max(h.x, h.y), max(h.z, h.w));
    vec4 a = (h - vec4(maxH)) * (sharp * strength);

    vec4 ww = w * exp2(a);
    ww = max(ww, w * 0.02);

    float s = max(dot(ww, vec4(1.0)), 1e-6);
    return ww / s;
}
```
the inputs `w` is the **sampled splat/weight mask (using gradients for correct mip selection)** from earlier and `h` is **each layers height**, so in this case you'll be right in guessing we support a max of 4 heights, hence vec4, but i'd like to extend the layer system in the future.

The result of `ApplyHeightBlend` is a weighed-sum which we then apply to AO, normal, and baseColor.

Also we want it to be easy to tune per biome/material set without it turning into banding or noise.


<center>

<video poster="https://jadderson.com/static/resources/media/blog/tempest_terrain_height_02_thumb.webp"  width="720" controls autoplay loop muted playsinline preload="auto">
    <source src="https://jadderson.com/static/resources/media/blog/tempest_terrain_height_02.webm" type="video/webm"></source>
    <source src="https://jadderson.com/static/resources/media/blog/tempest_terrain_height_02.mov" type="video/mov"></source>
    <source src="https://jadderson.com/static/resources/media/blog/tempest_terrain_height_02.mp4" type="video/mp4"></source>
</video>

</center>


⛰️ Tempest terrain 2: height + slope materials


Tempest doesn't have a terrain system yet, so I spent my christmas holiday on creating one. I had collected some references and had some visions in mind of what it could look like: A weighted mix between City Skylines 2, Diablo 4, RDD2, and Unreal's Terrain system. I also want Procedural content generation to be integrated deeply into the terrain system. Most importantly I like to have it behave differently based on weather conditions, without diving too deep into erosion.
I found this talk from Aaron Aikman: [H2O in H3LL: The Various Forms of Water in 'Diablo IV'](https://gdcvault.com/play/1034490/Technical-Artist-Summit-H2O-in), Which inspired me to do something about the non-existing terrain system in tempest. 

### Let's define some goals

I want terrain that:

- covers a big area
- keeps detail near the camera
- stays roughly the same cost while moving
- doesn’t require one huge mesh
- is easy to extend (snow, vegetation, procedural content)
- looks great in first person and from top down.

---
### Why not just one mesh?

A single terrain mesh doesn’t scale well:

- vertex count grows with world size
- updates get expensive (rebuilds, stitching, streaming)
- we end up spending detail where we don’t need it
- hiding LOD changes gets messy if we split into chunks

Even if we chunk the world, we still fight two problems:

1) too much geometry far away
2) seams and pops where chunk LODs meet

---


### Clipmaps

Geometry clipmaps solve this by drawing **nested grids** around the camera:

- the inner grid is high detail
- outer rings are lower detail but cover more area
- total vertex count stays roughly constant
- the terrain "moves" by shifting a **grid origin**, not by rebuilding meshes

This is the classic reference and what I wanted to recreate:

![clipmaps](https://developer.download.nvidia.com/books/gpugems2/02_clipmaps_01.jpg)
![clipmaps](https://developer.download.nvidia.com/books/gpugems2/02_clipmaps_02.jpg)

This is also commonly in used water rendering. You'd generate the clipmaps and then run FFT + gestner waves. I'd like to try this later in the terrain series, and perhaps add a whirlpool like in the movie the Pirates of the Carribean.

---

### How we build the rings

Instead of generating terrain geometry every frame, we prebuild a small library of mesh pieces:

- `TILE` (main interior quads)
- `EDGE_A`, `EDGE_B` (long strips)
- `FILL_A`, `FILL_B` (patches that plug gaps on LOD1+)
- `TRIM_A`, `TRIM_B` (LOD0-specific strips to meet LOD1 cleanly)

These meshes are generated once on the CPU (grid vertices + indices) and uploaded once into a static GPU pool.

The key point is that geometry cost doesn’t scale with world size. It scales with the clipmap resolution we choose, and we can pick that resolution based on whether we’re aiming at a top-down camera or a first-person camera.

---

### Offsets and the ring layout

Each LOD ring is drawn by placing those same pieces at fixed offsets.
LOD0 is a little special (more pieces) so the handoff into LOD1 behaves.

The render loop is basically:

- for each LOD:
- compute the scale (meters-per-vertex)
- compute an origin that follows the camera, snapped to the grid
- draw the same set of pieces at fixed offsets

---

### Snapping and keeping things consistent

If the clipmap origin follows the camera smoothly, the surface appears to "swim" under movement. It also causes problems for anything that uses frame history later (TAA, reprojection, temporal effects).

So each LOD origin snaps to its grid step size. Coarser LOD means a bigger snap step.

- LOD0: small snap step
- LODN: higher LODs grow with power of two: snap step = `2^(N+1) * vertexSpacing`

We also track alignment against the next LOD so we can pick the correct edge pieces.

This makes sampling and shading behave more predictably as the camera moves.

Here's a simplified version of the snap logic:

```cpp
float snappedX = floorf(camX / VertexSpacing)* VertexSpacing;
float snappedZ = floorf(camZ / VertexSpacing)* VertexSpacing;

for(u32 lod =0; lod < Lods;++lod)
{
  float snapStep =(float)(1u<<(lod +1))* VertexSpacing;
  float nextSnapStep =(float)(1u<<(lod +2))* VertexSpacing;

  float posX =roundf(snappedX / snapStep)* snapStep;
  float posZ =roundf(snappedZ / snapStep)* snapStep;

  float nextX =roundf(snappedX / nextSnapStep)* nextSnapStep;
  float nextZ =roundf(snappedZ / nextSnapStep)* nextSnapStep;

  LodPos[lod]=V3(posX,0, posZ);

  // Used to pick which edge strip to use (alignment vs next LOD)
  int testX =ClampInt((int)roundf((posX - nextX)/ snapStep)+1,0,2);
  int testZ =ClampInt((int)roundf((posZ - nextZ)/ snapStep)+1,0,2);
  LodTestX[lod]= testX;
  LodTestZ[lod]= testZ;
}
```

---

### Seams between rings

Different LOD densities meet at ring boundaries. If we do nothing, cracks and flicker show up.

Right now we’re using a simple approach:

- skirts at ring borders
- a small overlap between rings

It’s not the final solution, but it keeps the surface connected while we build out the rest.

I also have a debug toggle that draws ring edges, which makes this stuff way easier to iterate on.

---

### Vertex shader: sampling height without shimmer

Each clipmap vertex starts as a grid point in local tile space. In the vertex shader we:

- convert local grid coords to world XZ using the LOD scale + translation
- find which terrain region/tile owns that world position (via a region table)
- sample height from a texture array layer
- choose a height mip level based on how coarse the current LOD is

The important part is the mip selection. Coarse rings shouldn’t sample the highest-frequency height detail, because it causes visible vertex-height shimmer under movement.
```c++
float SampleHeightWS(vec2 worldXZ,float lodScale)
{
  vec2 uv;
  float layer;
  vec2 invSize;
  FindRegion(worldXZ, uv, layer, invSize);

  // baseCell = world meters per height texel for this specific region
  float sizeX =1.0/ max(invSize.x,1e-8);
  float sizeZ =1.0/ max(invSize.y,1e-8);
  float baseCell = max(sizeX * uCB.Params1.x, sizeZ * uCB.Params1.y);

  float mipCount = HeightMipCount();
  float lod = clamp(log2(max(lodScale / max(baseCell,1e-6),1.0)),0.0, mipCount -1.0);

  float h = textureLod(uHeightTex, vec3(uv, layer), lod).r;
  return h * uCB.Params0.y + uCB.Params0.z;
}
```

To support that, we build a CPU box-filter mip chain per height tile and upload all mip levels into the height texture array. It’s basic, but it reduces the shimmer a lot and makes the distant rings behave better.

---

### TAA

Still figuring this out.

We have a geomorph path in the shader that blends vertices toward the next LOD grid in an outer “morph zone”, but the tricky part is motion vectors and reprojection. When vertices morph, “previous position” needs careful handling or temporal history gets confused.

For now we take the safe route: if a vertex is in the morph zone, we avoid providing misleading velocity to TAA.

---

### Texturing + materials (splat + arrays)


Each terrain region stores:
- height (R32F)
- splat weights (RGBA8)
- wetness (R8)

All of these are texture arrays, indexed by a per-tile layer value stored in the region table.

Each region also carries four material IDs (RGBA → four global material indices). In the fragment shader we:

- read splat weights
- map them to material textures (albedo/normal/ORM arrays)
- height-blend weights
- apply slope-based cliff triplanar
- add macro noise + a detail normal
- apply wetness (darkening, roughness changes, and a light coat spec)

There’s a lot going on, but the intent is straightforward: materials should not shift around as the clipmap rings snap and follow the camera. This post focuses on the geometry side; the next post will go deeper on height and slope blending.


---

### What we have so far

- nested grid layout (clipmap rings)
- camera-following origin
- snapped per-LOD origins
- ring debug visualization
- height mip chains
- texture-array region lookup (height/splat/wetness)
- simple seam strategy (skirts + overlap)


#### Future work

- smoother ring transition blending (better geomorph + shading continuity)
- better normals across boundaries
- faster region lookup (spatial acceleration instead of a linear scan)

### References:

- [GPU Gems 2- Chapter 2: Terrain Rendering Using GPU-Based Geometry Clipmap](https://developer.nvidia.com/gpugems/gpugems2/part-i-geometric-complexity/chapter-2-terrain-rendering-using-gpu-based-geometry)
- [H2O in H3LL: The Various Forms of Water in 'Diablo IV'](https://gdcvault.com/play/1034490/Technical-Artist-Summit-H2O-in)



⛰️ Tempest terrain 1: geometry clipmaps


Vulkan pipeline creation can get expensive, especially once a project has a lot of pipelines.

Tempest uses `VkPipelineCache` to make startup a little smoother. The cache is saved to disk and loaded again next time the engine starts.

This is mainly useful on desktop/editor builds. On mobile it’s disabled.

---

## # How it works

- Load the cache file (if it exists)
- Validate it against the current GPU + driver
- Create a `VkPipelineCache` (from file data or empty)
- Pass it into `vkCreateGraphicsPipelines`
- On shutdown, save the updated cache back to disk

Pipeline caching is disabled on mobile. Cache behavior varies too much across devices and updates to be worth dealing with.

---

## # Validation and regeneration

Pipeline caches are not portable. A driver update, a new GPU, or even moving to a different machine can invalidate them.

Tempest checks the cache header and only accepts it if these match:

- `vendorID`
- `deviceID`
- `pipelineCacheUUID`

If the cache is invalid, it’s deleted and rebuilt on the next run. The cache can also grow over time, so it’s fine to regenerate it when needed.

---

## # Saving the cache

```c++
void
TempestVulkanDevice::StorePipelineCache()
{
    byte_buffer Buffer;
    vkGetPipelineCacheData(m_device, m_pipelineCache, &Buffer.Size, NULL);
    Buffer.AllocateZeroes(Buffer.Size);
    vkGetPipelineCacheData(m_device, m_pipelineCache, &Buffer.Size, Buffer.Data);

    stack_string_1024 Path("Internal/PipelineCache.bin");
    EngineDeleteFile(Path.ToPathString().GetFullPath().String);
    EngineWriteFile(Path.ToPathString().GetFullPath().String, Buffer.Data, Buffer.Size);
}
```

## # Creating the cache

On desktop/editor builds, Tempest loads the cache from disk and validates it. If it matches the current device properties, it’s used during pipeline creation.

If it doesn’t match, the cache file is deleted so it regenerates cleanly.

On mobile builds, caching is disabled entirely.


```c++
void
TempestVulkanDevice::CreatePipelineCache()
{
    #ifdef ENGINE_PLATFORM_MOBILE
    // Pipeline caching disabled on mobile targets
    VkPipelineCacheCreateInfo pipelineCache{};
    pipelineCache.sType = VK_STRUCTURE_TYPE_PIPELINE_CACHE_CREATE_INFO;

    VkResult res = vkCreatePipelineCache(m_device, &pipelineCache, NULL, &m_pipelineCache);
    assert(res == VK_SUCCESS);
    return;
    #endif

    b32 CacheIsValid = false;
    byte_buffer Buffer = {};

    stack_string_1024 Path("Internal/PipelineCache.bin");
    engine_file File = {};

    if (EngineFileExists(Path.ToPathString().GetFullPath().String))
    {
        EngineReadFile(Path.ToPathString().GetFullPath().String, &File);
        Buffer = File.CopyToByteBuffer();
        EngineCloseFile(File);

        if (Buffer.Data && Buffer.Size >= sizeof(VkPipelineCacheHeaderVersionOne))
        {
            VkPipelineCacheHeaderVersionOne* Header =
                (VkPipelineCacheHeaderVersionOne*)Buffer.Data;

            if (Header->deviceID == m_deviceProperties.deviceID &&
                Header->vendorID == m_deviceProperties.vendorID &&
                memcmp(Header->pipelineCacheUUID,
                       m_deviceProperties.pipelineCacheUUID,
                       VK_UUID_SIZE) == 0)
            {
                CacheIsValid = true;
            }
            else
            {
                CacheIsValid = false;

                // deleting the invalid cache file so it regenerates next run
                EngineDeleteFile(Path.ToPathString().GetFullPath().String);
            }
        }
    }

    VkPipelineCacheCreateInfo pipelineCache{};
    pipelineCache.sType = VK_STRUCTURE_TYPE_PIPELINE_CACHE_CREATE_INFO;
    pipelineCache.pNext = NULL;
    pipelineCache.initialDataSize = CacheIsValid ? Buffer.Size : 0;
    pipelineCache.pInitialData = CacheIsValid ? Buffer.Data : NULL;
    pipelineCache.flags = 0;

    VkResult res = vkCreatePipelineCache(m_device, &pipelineCache, NULL, &m_pipelineCache);
    assert(res == VK_SUCCESS);

    Buffer.Destroy();
}
```

## # Notes

* Pipeline caches only help after the first run, since they need to be generated.
* Caches are not permanent. Driver updates can invalidate them.
* Tempest regenerates the cache automatically by deleting invalid files.
* Pipeline caching is disabled on mobile.

Speeding up Tempest by Pipeline Caching


Some of my experiments with procedural generation.

I created a root prefab called Terrain which has a FloorTerrain script.
On initialization we'll generate several planes from the center of the Terrain object.

To achieve this we'll have to create a root prefab; Which I've called Terrain.


Things we need to know is the location of the Player at every frame and which entity/prefab we'll have to create when the player reaches the edge.

On initialization we create the starting platform like so:

```csharp
//create the starting platform
for (int x = -halfTilesX; x < halfTilesX; x++)
{
    for (int z = -halfTilesZ; z < halfTilesZ; z++)
    {
        Vector3 pos = new Vector3((x * planeSize + startPos.x), 0, (z * planeSize + startPos.z));
        GameObject t = (GameObject)Instantiate(tilePrefab, pos, Quaternion.identity);
        tileName = "Tile_" + ((int)(pos.x)).ToString() + "_" + ((int)(pos.z)).ToString();
        t.GetComponent<Floor>().Init(pos, chunkSize, tileName, ft);
        tile = new Tile(t, updateTime);
        tiles.Add(tileName, tile);
    }
}
```


Here I am assuming that the Y-axis is up instead of Z. All we're doing is generating a 2D grid of Tiles these tiles are just regular planes, which is an equilateral square. Once we've calculated the position of the plane we'll add the Floor script to it and initialize it then we'll add it to a HashTable. 
Which happens here:

```csharp
string tileName = "Tile_" + ((int)(pos.x)).ToString() + "_" + ((int)(pos.z)).ToString();
tiles.Add(tileName, tile);
```

This is not ideal and you don't want to use a Hashmap here at all, even though the lookup is in constant time on average. You should instead try to use an array that contains larger chunks of terrain and inside each chunk is a subdivision of smaller terrain planes. The indices of each plane can then be calculated based on the position of the player, how big the chunk dimension is and how many chunks and planes there are.
[Casey Muratori does an amazing job at explaining how this is done in his Handmade Hero game engine series](https://www.youtube.com/watch?v=lDp4rqcigZs). When I wrote this I had no idea how easy it was and ended up using a Hashtable because that's always the easy solution. 

# Main logic
For the main logic, this is what we do in FixedUpdate:
```csharp
private void FixedUpdate() 
{
    //determine how far the player has moved since last terrain update
    int xMove = (int)(player.transform.position.x - startPos.x);
    int zMove = (int)(player.transform.position.z - startPos.z);
    if (Mathf.Abs(xMove) >= planeSize || Mathf.Abs(zMove) >= planeSize)
    {
        float updateTime = Time.realtimeSinceStartup;

        //force integer position and round to nearest tilesize
        int playerX = (int)(Mathf.RoundToInt(player.transform.position.x / planeSize) * planeSize);
        int playerZ = (int)(Mathf.RoundToInt(player.transform.position.z / planeSize) * planeSize);

        for (int x = -halfTilesX; x < halfTilesX; x++)
        {
            for (int z = -halfTilesZ; z < halfTilesZ; z++)
            {
                Vector3 pos = new Vector3((x * planeSize + playerX), 0, (z * planeSize + playerZ));

                string tilename = "Tile_" + ((int)(pos.x)).ToString() + "_" + ((int)(pos.z)).ToString();

                if (!tiles.ContainsKey(tilename))
                {
                    GameObject t = (GameObject)Instantiate(tilePrefab, pos, Quaternion.identity);
                    t.GetComponent<Floor>().Init(pos, chunkSize, tilename, ft);
                    Tile tile = new Tile(t, updateTime);
                    tiles.Add(tilename, tile);
                }
            }
        }
        startPos = player.transform.position;
    }
}
```

The above code triggers when the player moves and thus, we don't have to do extra work when the player is standing still. We round down the nearest player position which is important. Then we'll generate terrain around the player whilst checking that we're not generating duplicates. We do that by a lookup to the hashtable.

The important thing to note here is that because we're just generating new GameObjects on the fly when we need them as opposed to a predefined size, and because we're storing them in a hashmap this gives us sparseness for very little code. 

# Procedurally creating the terrain
For procedural work, it's important to mark the mesh as dynamic. This allows unity to do some optimizations in the background and prevents unity from using static buffers. 
```csharp
terrainMeshFilter.mesh.MarkDynamic();
```
However, since we're generating Terrain and not changing the vertices of the terrain afterwards, we don't have to worry about marking it as Dynamic. Instead, in this case, it would be far better not to.   

This is the entire tile creation routine:
```csharp
private void createFloorTile(Vector3 CenterPosition, float chunkSize, FloorTerrain ft)
{
    Vertices.Add(new Vector3(CenterPosition.x - chunkSize, CenterPosition.y, CenterPosition.z + chunkSize)); //0
    Vertices.Add(new Vector3(CenterPosition.x + chunkSize, CenterPosition.y, CenterPosition.z + chunkSize)); //1
    Vertices.Add(new Vector3(CenterPosition.x, CenterPosition.y, CenterPosition.z)); //2
    Vertices.Add(new Vector3(CenterPosition.x - chunkSize, CenterPosition.y, CenterPosition.z - chunkSize)); //3
    Vertices.Add(new Vector3(CenterPosition.x + chunkSize, CenterPosition.y, CenterPosition.z - chunkSize)); //4

    Normals.Add(Vector3.up); //0
    Normals.Add(Vector3.up); //1
    Normals.Add(Vector3.up); //2
    Normals.Add(Vector3.up); //3
    Normals.Add(Vector3.up); //4

    Triangles.Add(2);
    Triangles.Add(0);
    Triangles.Add(1);

    Triangles.Add(1);
    Triangles.Add(4);
    Triangles.Add(2);

    Triangles.Add(4);
    Triangles.Add(3);
    Triangles.Add(2);

    Triangles.Add(3);
    Triangles.Add(0);
    Triangles.Add(2);

    UVs.Add(new Vector2(0, 1));
    UVs.Add(new Vector2(1, 1));
    UVs.Add(new Vector2(0.5f, 0.5f));
    UVs.Add(new Vector2(0, 0));
    UVs.Add(new Vector2(1, 0));

    //ADD RANDOM COLOR
    //Gradient gradient = RandomE.gradientHSV;
    var noiseOffset = new Vector2(Random.Range(0f, 100f), Random.Range(0f, 100f));
    ft.floorContainer.floorColors.Clear();
    
	float noiseScale = 0.15f;
    float noise = 0f;

    foreach (Vector3 vertex in Vertices)
    {
        float x = noiseScale * vertex.x / 2 + noiseOffset.x;
        float y = noiseScale * vertex.z / 2 + noiseOffset.y;
        noise = Mathf.PerlinNoise(x, y);
        Colors.Add(ft.floorGradient.Evaluate(noise));
    }

    for (int i = 0; i < Vertices.Count; i++)
    {
        Vertices[i] = new Vector3(Vertices[i].x, Mathf.PerlinNoise((CenterPosition.x + transform.position.x) / detailScale, (CenterPosition.z + transform.position.z) / detailScale) * heightScale, Vertices[i].z);
    }

    ft.gameCenteredFloors.Add(CenterPosition, this);

    flush(ft);
}
```
CenterPosition is the coordinate we want to place the Tile at. ChunkSize is how big the tile is, I've set this to 1 meter. First, we create the vertices, assign the triangles (Unity uses a clockwise winding order for the triangles).  We then generate the UVs and generate a random gradient sampling from a predefined gradient LUT:

<center>

![gradient lut](https://jadderson.com/static/resources/media/blog/pcg/gradient_lut.webp)

</center>

This is the result:

<center>

<video poster="https://jadderson.com/static/resources/media/blog/pcg/pcg-2_thumbnail.png"  width="720" controls autoplay loop muted playsinline preload="auto">
    <source src="https://jadderson.com/static/resources/media/blog/pcg/pcg-2.webm" type="video/webm"></source>
    <source src="https://jadderson.com/static/resources/media/blog/pcg/pcg-2.mp4" type="video/mp4"></source>
    <source src="https://jadderson.com/static/resources/media/blog/pcg/pcg-2.mov" type="video/mov"></source>
</video>

</center>


For the edges and we can simply generate rectangles and place them on top with an offset. We also know the side length of each tile and can easily create oblong rectangles that span the entire side of the tile.

Another approach would be to procedurally generate the edges as well, which would be the optimal strategy. The challenges there would be to calculate the correct placement of each edge such that center-tiles won't have edges and edge-tiles would. This requires a numbering system of each tile in the chunk. There is more work involved, but in terms of performance, that's the best choice. 

Doing all of that, this is the result: 


<center>

<video poster="https://jadderson.com/static/resources/media/blog/pcg/pcg-1_thumbnail.png"  width="720" controls autoplay loop muted playsinline preload="auto">
    <source src="https://jadderson.com/static/resources/media/blog/pcg/pcg-1.webm" type="video/webm"></source>
    <source src="https://jadderson.com/static/resources/media/blog/pcg/pcg-1.mp4" type="video/mp4"></source>
    <source src="https://jadderson.com/static/resources/media/blog/pcg/pcg-1.mov" type="video/mov"></source>
</video>

</center>


# Optimizations
I ran into optimization problems early on when doing this.
Because creating a ton of planes and rendering them one by one is never as efficient as rendering a single big geometry all at once. I had the idea to try to combine the meshes like so:
```csharp
public void OptimizeAndCombine()
{
    MeshFilter[] meshFilters = GetComponentsInChildren<MeshFilter>();
    CombineInstance[] combine = new CombineInstance[meshFilters.Length];
    int i = 0;
    while (i < meshFilters.Length)
    {
        combine[i].mesh = meshFilters[i].mesh;
        combine[i].transform = meshFilters[i].transform.localToWorldMatrix;
        meshFilters[i].gameObject.SetActive(false);
        if (meshFilters[i] != terrainMeshFilter)
        {
            unusedFloors.Add(meshFilters[i].gameObject);
        }
        i++;
    }
    terrainMeshFilter.mesh = new Mesh();
    terrainMeshFilter.mesh.CombineMeshes(combine, true);
    terrainMeshFilter.mesh.RecalculateBounds();
    terrainMeshCollider.sharedMesh = terrainMeshFilter.mesh;
    transform.gameObject.SetActive(true);
    removeUnwantedFloors();
    //groundDecoration.OptimizeAndCombineRocks();
}
```
This worked great and i did achieve significant fps speedups and less drawcalls. However, it's not a great solution and I wish I had more access to the Unity rendering API to have abit more control and optimize it further.

I then added some post-processing effect to the camera along with screen space antialiasing, and managed to capture this: 

<center>

<video poster="https://jadderson.com/static/resources/media/blog/pcg/pcg-overview_thumbnail.png"  width="720" controls autoplay loop muted playsinline preload="auto">
    <source src="https://jadderson.com/static/resources/media/blog/pcg/pcg-overview.webm" type="video/webm"></source>
    <source src="https://jadderson.com/static/resources/media/blog/pcg/pcg-overview.mp4" type="video/mp4"></source>
    <source src="https://jadderson.com/static/resources/media/blog/pcg/pcg-overview.mov" type="video/mov"></source>
</video>

</center>
