SecondSystem

Plate Tectonics 3

Sun, 04 Sep 2022 00:00:00 +0000

Now that we have a way to generate some (albeit a bit dull) tectonic plates, we can use an iterative algorithm that simulates plate movements and interactions, to refine it into (hopefully) realistic looking landforms.

Because the simulation itself is relatively complex^[1], I’ve split it into three separate posts:

Moving the plates and determining how they should interact with each other (this post)
Updating the mesh after vertices have been moved, which includes the creation and destruction of crust material on plate boundaries, as well as detecting and handling collisions between plates
Simulating large-scale plate interactions like rifting and suturing

Plate Motion

The first aspect we will take a closer look at, is how moving the plates on the surface is implemented – which are steps 2, 4 and 5 of the algorithm outline I’ve given here.

To recap, contrary to the work of Cortial et al., we model our plates as a collection of interconnected sub-plates, each defining an area of similar composition and properties around it. To simulate the movement of these sub-plates, each of them is treated like an infinitesimal particle (represented by the mesh vertices), that interacts with each sub-plate around it by applying forces to them, depending on their relationship^[2].

This model allows us not only to represent heterogeneous plates, that are composed of many different types of crust, but also simplifies our simulation algorithm because (at least in this step) we only need to check the surrounding vertices to calculate the forces that affect each sub-plates movements.

Our goal for this part of the algorithm is to simulate the motion of each of these sub-plates/vertices/particles. Since each sub-plate is modelled as a particle, calculating their motion consists of two main steps: First determine the forces that act on each particle, and second update their acceleration, velocity and position based on these forces.

Step 2: Identify boundary-types

The forces that each sub-plate applies to its direct neighbors depend on their distance to each other and how they relate to each other. The latter of which is based on the five boundary types, we’ve discussed earlier:

Divergent boundary: Two plates moving away from each other^[source]

Convergent boundary (CO): An oceanic and a continental plate colliding with each other^[source]

Convergent boundary (OO): Two oceanic plates colliding with each other^[source]

Transform boundary: Two plates moving past each other^[source]

Convergent boundary (CC): Two continental plates colliding with each other ^[source]

Based on these types, we define the following enum, which we’ll use to annotate each edge with the necessary information:

enum class Boundary_type : int8_t {
	joined,            // both vertices belong to the same plate
	ridge              // divergent boundary
	subducting_origin, // the origin vertex is subducted under the dest vertex
	subducting_dest,   // the dest vertex is subducted under the origin vertex
	transform,         // transform boundary
	collision,         // CC convergent boundary
};

As we can see, there are two minor differences to the boundary types used by the theoretical model. The first is, that we need an additional type joined, for edges that connect to vertices that are part of the same plate. And the second is that convergent boundaries are labeled a bit differently. As we’ll see later, CO ad OO boundaries are handled by the same code path, so we don’t have to differentiate them here. But we still need two values for these types of boundaries because we have to encode which of the two vertices is subducted. We could encode this by storing the Boundary_type for both directions of the edge. But since the other boundary types don’t care about the direction, we can instead utilize that every directed edge has fixed a “preferred direction”, which is the first edge of its corresponding quad-edge, which means that e.origin() and e.dest() are well-defined for every undirected Edge e.

What this comes down to is, that we’ve to iterate over each edge^[3] in our mesh and assign them a Boundary_type based on the properties of the two vertices that they connect.

This step follows a couple of simple rules and mostly depends on the distance between the vertices $d$ and their converging-velocity $v$ , that is the component of their combined velocities that moves them towards each other (or apart for negative values):

Initially, all edges start as transform boundaries
If the two vertices reference the same plate id, they are set to joined and if that ever changes or the edge is invalidated it’s transitioned back to transform
If a transform boundary is separating ( $v <= -0.05$ and $d>=1500km$ ) the edge becomes a ridge
If a transform boundary is converging ( $v > 0.1$ $v > 0.1$ ), we need to determine which of the two sub-plates would subduct^[4]
- subducting_origin if e.origin() would be subducted
- subducting_dest if e.dest() would be subducted
- collision if none of the two plates can be subducted because both are continental plates
Finally, if collision, subducting_origin or subducting_dest boundaries cease to converge or if ridge boundaries start to converge again, they become a transform boundary once again

Step 4: Calculate all forces acting on the sub-plates

Now that we know the relationship between all connected vertices, we can calculate the forces that act on them.

In our model, all forces are caused by edges. Hence, the $\vec{force}$ that acts on a given vertex, is just the sum of the forces caused by each of its connected edges. To calculate these, we iterate over all edges, calculate the force it applies to its dest() and origin() — based on its Boundary_type — and keep a running total of all forces per vertex.

Boundary_type::joined

Vertices with this boundary type are part of the same plate. Since plates should keep their overall shape across time steps but still be slightly deformable on collisions, they are approximated as soft bodies.

To achieve this, we model all Boundary_type::joined as damped springs, that apply a force to the two connected vertices, which aims to keep their distance constant. The combination of these damped springs on both primal and dual edges, combined with the restriction of vertices to a 2D surface and prevention of self-intersections and other artifacts, is sufficient to achieve the overall effect of a slightly deformable solid. Because the springs try to maintain their initial length, collisions behave elastic by default. But more forceful collisions will cause modifications in the mesh topology, which invalidates previously stored distance information, causing a more plastic collision response.

To calculate the force, we utilize a standard damped spring equation^[5]:

const auto k_compressed = 1e-4f;
const auto k_stretched  = 5e-5f;
const auto damping      = 2e-6f;

const auto difference   = positions[dest] - positions[origin];
const auto distance     = length(difference);
const auto direction    = difference / distance;
const auto displacement = target_distances[e] - distance;

const auto relative_velocity = dot(velocities[origin] - velocities[dest], direction);

const auto k     = displacement > 0.f ? k_compressed : k_stretched;
const auto force = direction * (displacement * k + relative_velocity * damping);

forces[origin] -= force;
forces[dest]   += force;

Boundary_type::ridge

Ridges are boundaries where two plats separate and mantel material wells upwards, forming new oceanic crust. This upwelling of material also pushes the two plates further apart, speeding up their separation.

Not only is this one of the main forces that keeps the Wilson-Cycle of plate subduction going^[6], but it also helps to stabilize the simulation, since it causes plates that started separating to keep doing so, instead of bouncing back or oscillate.

This force is pretty easy to model, since we just need to apply a small constant force to both vertices, that pushes them apart:

const auto ridge_push_force = 2e-8f;

const auto origin_to_dest = normalized(positions[dest] - positions[origin]);

forces[origin] -= origin_to_dest * ridge_push_force;
forces[dest]   += origin_to_dest * ridge_push_force;

Boundary_type::subducting_origin

The main force for the Wilson-Cycle in our simulation is the Slab-Pull force, that acts on subduction boundaries and pulls the subducting plate closer.

When a piece of crust is pushed underneath another plate, it isn’t actually hot enough to melt. Instead, it undergoes a complex process of partial melting, which causes the volcanism we can observe at the surface and also increases its density. Driven by this increased density, it starts to sink into the mantle, pulling the rest of the plate it’s still connected to down with it.

Like the ridge-push above, this is again just a constant force. But contrary to ridges it doesn’t act on both vertices but just on the one that is belongs to the subducting plate. Which is of course the reason why we’ve split this boundary into two distinct types. Hence, except for the fact to which vertex the force is added, the calculation is identical for both Boundary_type::subducting_origin and Boundary_type::subducting_dest:

const auto slab_pull_force = 5e-8f;

// Boundary_type::subducting_origin
forces[origin] += normalized(positions[dest] - positions[origin]) * slab_pull_force;

// Boundary_type::subducting_dest
forces[dest] += normalized(positions[origin] - positions[dest]) * slab_pull_force;

Boundary_type::transform and Boundary_type::collision

The final two boundary types we need to handle are quite similar and actually use the exact same code, since they both apply a force to prevent two plates from intersecting. The only difference is that collision boundaries are converging much more forcefully, which might result in one plate suturing onto the other.

Similar to the others, this boils down to a force applied in the direction of the boundary. Since the goal is to prevent the two plates from coming closer than they currently are, without affecting lateral motion or separation, the amount of force depends on the converging velocity between the two vertices. That is, the part of their velocity that acts to move them closer together, so exactly what we intend to negate.

const auto difference          = positions[dest] - positions[origin];
const auto distance            = length(difference);
const auto direction           = difference / distance;
const auto converging_velocity = dot(velocities[origin]-velocities[dest], direction);

If this converging velocity is greater than one, so if the two vertices are moving closer together, we need to apply a collision-response force.

To fully negate that part of their velocity, we would have to apply a force of $\frac{\vec{v}}{\text{dt} \cdot 2}$ to both vertices. But since this force is applied to all vertices that theoretically could collide, a response that that would be too strict and prevent nearly all movement. Instead, we need to modulate the force depending on the current distance between the two vertices and the closest distance that we want to allow. This can be achieved using a simple quadratic falloff like this:

f(x) = \frac{1}{1 + \left (\frac{\text{max}(0,\:\text{distance}\: -\: \text{min\_distance})}{\text{min\_distance}}\right ) ^2}

Plot of the falloff equation with a minimum distance of 8km.

const auto collision_min_distance = 8'000.f; // meter

if(converging_velocity > 0.f) {
	const auto d = std::max(0.f, dist - collision_min_distance) / collision_min_distance;
	const auto alpha = std::clamp(1.f / (1.f + d * d), 0.f, 1.f);
	const auto force = direction * (alpha * converging_velocity / delta_time / 2.f);

	forces[origin] -= force;
	forces[dest]   += force;
}

Step 5: Simulate movement

Now that we know what forces are acting on each sub-plate, we just need to simulate their movement. The motion of each particle follows the well-known Newtonian equations of motion, which we will approximate numerically using Verlet integration because of a couple of key advantages:

Similar computational complexity to implicit/explicit Euler integration, but with much better numeric stability
Easy to implement, since we only need to keep track of the current and previous position
Constraints are trivially easy to implement, by just modifying the calculated new positions. Which is important for us because we have to constrain each vertex to keep it on the sphere’s surface.

To update each vertex position $\vec{p}$ we use:

\vec{p}_t = \left \| \vec{p}_{t-1} + (\vec{v}_{t-1}\cdot \text{dt} + \frac{\vec{\text{force}}}{\text{mass}}\cdot \text{dt}^2)\cdot (1-\text{drag} \cdot dt) \right \| \cdot \text{radius}

Where $dt$ is the delta time between the two steps, $\vec{force}$ is the sum of all forces acting on the sub-plate, $mass$ and $drag$ are constants and $\vec{v}$ is the velocity, which is calculated after the positions are updated using:

\vec{v}_t = \frac{\vec{p}_t-\vec{p}_{t-1}}{dt}

Of course, because each sub-plate moves independent of the others, there will be some problems like self-intersections, which we’ll need to clean up afterwards. But that is a topic for another blog post.

Tectonic plates moving, colliding and being subducted.

Elevation

Now that we have continental and oceanic plates moving about, we can also use that information to finally pile up some mountains and create some actual terrain.

6. Update elevation

Mountain formation in reality is a complex process, involving 3D interactions and folding between parts of the crust with varying compositions and densities. But in our model this is simplified quite a bit and only depends on the sub-plates velocities and their Boundary_type.

In fact, there are only two types of boundaries that are relevant for mountain formation:

Boundary_type::collision

During collisions, the crust material between the two plates is pushed closer together. Since both plates are not dense enough to subduct they instead pile up, which forms large mountain ranges and plateaus, like the Alps or Mount Everest.

To simulate this process, each edge on a collision boundary is check and if the two plates are still converging, the crust around the boundary is lifted by an amount based on the converging velocity and its distance to the boundary. Since this affects not just the two vertices, that are part of the boundary, but also the crust that is further away, a flood-fill is used to recursively visit all neighboring vertices of the plate until the elevation change becomes insignificant.

My initial implementation actually contained a more general approach, that compared the volume of the Voronoi cell of every vertex, including internal ones, between time-steps and updated the elevation to preserve their volume, also taking the isostatic equilibrium into account. My hope was, that this would better simulate the effects of collisions further from the boundary. Alas, the resulting terrain was much more messy and noisy than the current implementation. But that is definitely an approach I plan to revisit once the simulation is stable and produces satisfactory results.

Boundary_type::subducting_*

The other type of boundary that contributes to mountain formation are subduction zones. In the partial melting process of the subducted crust, water and other foreign materials, that were pulled down with the bedrock, disrupt the equilibrium inside the upper mantle, which causes a sharp increase in volcanism on the un-subducted plate above. This process creates the long thin mountain ranges near subduction boundaries, like the Andes and the islands around the ring of fire.

The simulation for this is currently quite similar to that for collision boundaries, except that only one of the plates is lifted up, while the other one is pulled down, and that the position of the elevation increase is slightly different, i.e. a smaller area and slightly inland from the actual boundary.

9. Simulate Erosion

The elevation-code described above mostly adds elevation. So, if left to its own devices, the whole planet would be one huge mountain range. To balance this out, we need an additional system that reduces the elevation, which is precisely what the erosion simulation does.

This part is more or less copied as is from the paper of Cortial et al., with just some minor additions. Eventually, once we have a climate simulation to generate temperatures, precipitation and watersheds, we’ll extend this to a more interesting/faithful/complete erosion system. But for now, this simple simulation is good enough to counterbalance the mountain formation.

const auto ocean_elevation =  -6'000.f; // meter
const auto max_elevation   =  10'000.f; // meter
const auto min_elevation   = -10'000.f; // meter

const auto oceanic_dampening  = 6e-5f; // meter/year
const auto sediment_accretion = 3e-6f; // meter/year
const auto simple_erosion     = 8e-5f; // meter/year

const auto sink_amount   = 0.006f; // meter/year
const auto sink_begin    = 2'000'000.f; // years
const auto sink_duration = 2'000'000.f; // years

if(types[v] == Crust_type::continental) {
    // Move elevation of continental crust towards 0m above sea level.
    // Since this is based on the current elevation, larger mountains are eroded faster.
	elevation -= elevation / max_elevation * simple_erosion * dt;

} else if(elevation > -6'000.f) {
    // Oceanic ridges are initially less dense than the surrounding sea floor and
    //   cool and sink over time, which is (crudely) simulated here
	const auto age = now - created[v];
	if(age > sink_begin && age < sink_duration + sink_begin) {
		elevation = std::max(ocean_elevation, elevation - sink_amount * dt);
	}

    // Ocean floor above the height of the abyssal plane is pushed down
	const auto x      = elevation / ocean_elevation;
	const auto factor = (1.f - elevation / min_elevation) * smootherstep(0.f, 0.2f, x);
	const auto delta  = std::max(0.f, factor * oceanic_dampening * dt);
	elevation         = std::max(ocean_elevation, elevation - delta);

} else {
    // Ocean floor below the abyssal plane (e.g. from old inactive subduction zones)
    //   is slowly filled up by sediment.
	elevation += sediment_accretion * dt;
}

Conclusion

Now that we’ve got some movement going and elevation elevating, we’ve actually already covered half of the algorithm:

Add vertices where more details are needed and remove vertices unessential ones
✔ Compare the properties of neighboring sub-plates to determine if they belong to the same tectonic plate or fall into one of the boundary zones discussed above (transform, divergent, convergent CC/OC/OO)
Create new oceanic crust at divergent boundaries
✔ Calculate all forces acting on the sub-plates
✔ Calculate the acceleration of all sub-plates, based on the forces acting on them, and utilize Verlet integration to calculate their new velocities and positions
✔ Update each sub-plate’s elevation, if they are part of a subduction or collision zone
Check for collisions and resolve them
Check and restore Delaunay condition, if required ^[7]
✔ Simulate erosion
Combine colliding continental plates and split plates that have gotten too large

All that’s left for the last two posts now, is to clean up the mess we left behind in step 5. Which means cleaning up inconsistencies in the mesh and handling collisions caused by the plate’s movement (7. and 8.) as well as creating/destroying crust (1. and 3.) and simulating large-scale plate interactions (10.).

Plate Tectonics 2

Sat, 19 Mar 2022 00:00:00 +0000

The first aspect we will have to take a closer look at, is how we can generate our starting point, i.e. the initial state before the simulation is run.

We’ve already discussed the first half of that in a previous post, where we’ve generated a simple triangle mesh of a sphere. So, I’ll first recap the most important part of that and then dive into how we can populate that mesh with the information we need for the actual simulation, like plate-IDs, plate-velocities and elevations.

Creating the mesh

(A) Uniformly distributed points (Fibonacci Sphere)

To recap, what we need is a set of random points, that are uniformly distributed on the surface of a sphere, where each point represents part of a tectonic plate. To generate uniformly distributed points^[1], we utilize the golden angle to create a Fibonacci Sphere, by placing points walking downwards from one of the poles and rotating $2\pi \cdot (2-\phi)$ radians^[2] each step (image A).

(B) Shaded triangulation of these points

Once we have a set of points, the next step is to generate a triangle mesh from them. There are many possible ways to triangulate a set of points, but the one we’ll use is the Delaunay triangulation, because it avoids long thin triangles, that could be problematic during the simulation, and also because its dual-mesh is the Voronoi diagram of the mesh, which we’ll utilize for other parts of the simulation. While there are more efficient algorithms to generate a Delaunay triangulation of a set of points, since our points all lay on the surface of a sphere, the easiest approach is to generate the convex hull of the points (using the QuickHull algorithm), which in this case coincides with the Delaunay triangulation of the points (image B).

The algorithm described above distributes the points completely uniformly. But for a more natural look, it’s actually preferable to sacrifice some uniformity to achieve a less predictable structure. Luckily, all that’s required to achieve this, is to offset each point by a random amount (image C). And as long as that offset is smaller than our step-size, the points are still guaranteed to be far enough apart.

This gives use the following code to generate our mesh:

// Define the data layer that contains the vertex positions in 3D Cartesian coordinates
constexpr auto position_info = Layer_info<Vec3, Layer_type::vertex>("position");

// Acquire all necessary resources from the world structure
auto mesh        = world.lock_mesh();
auto [positions] = world.lock_layer(position_info);
auto rand        = world.lock_random();

// Create N vertices
mesh->add_vertices(vertex_count);

// Pre-calculate the golden angle and the step-size for calculating y,
//   so we just need to multiply them with i in the loop
constexpr auto golden_angle = 2.f * std::numbers::pi_v<float> * (2.f - std::numbers::phi_v<float>);
const auto     step_size    = 2.f / (vertices - 1);

for(std::int32_t i = 0; i < vertices; i++) {
	const auto offset = perturbation > 0 ? rand->uniform(0.f, perturbation) : 0.f;
	auto       ii    = std::min(i + offset, vertices - 1.f);

	// Calculate the x/y/z position of the current vertex on the unit sphere
	const auto y     = 1.f - step_size * ii;
	const auto r     = std::sqrt(1 - y * y);
	const auto theta = golden_angle * ii;
	const auto x     = std::cos(theta) * r;
	const auto z     = std::sin(theta) * r;

	// Set the vertex position (multiplying with the radius of our sphere)
	positions[Vertex(i)] = Vec3{x, y, z} * radius;
}

// Triangulate the generated points
auto  qh      = quickhull::QuickHull<float>{};
auto  hull    = qh.getConvexHull(&positions.begin()->x, positions.size(), false, true);
auto& indices = hull.getIndexBuffer();

for(std::size_t i = 0; i < indices.size(); i += 3) {
	mesh->add_face(indices[i], indices[i+1], indices[i+2]);
}

Generating the first tectonic plates

Besides the mesh itself, there are also a couple of values the simulation uses, that we need to initialize to create the initial set of tectonic plates. As already mentioned, these values are attached to the meshes vertices to describe the properties of the area around the vertex and are defined as follows in the code:

enum class Crust_type : int8_t { none, oceanic, continental };

// Position of the vertex in space (initialized by the process above)
constexpr auto layer_position   = Layer_info<Vec3,       Layer_type::vertex>("position");
// Integer ID of the plate, the vertex belongs to
constexpr auto layer_plate_id   = Layer_info<int32_t,    Layer_type::vertex>("plate_id");
// Dominant type of the crust in this area
constexpr auto layer_plate_type = Layer_info<Plate_type, Layer_type::vertex>("crust_type");
// Velocity of this piece of crust
constexpr auto layer_velocity   = Layer_info<Vec3,       Layer_type::vertex>("velocity");
// Height of this piece of crust above/below the (arbitrary) sea level
constexpr auto layer_elevation  = Layer_info<float,      Layer_type::vertex>("elevation");
// The timestamp at which the crust has formed
constexpr auto layer_created    = Layer_info<float,      Layer_type::vertex>("crust_created");

The process of generating the values itself is actually incredibly simple. First we pick $N$ random vertices as seed-points to create $N$ tectonic plates, assign them each a random elevation/velocity/… and finally use a flood-fill type algorithm to grow them in all directions, until all vertices are assigned to a plate.

Initialize seed vertices

First we’ll need to pick a couple of random points that will be the seeds from which we then grow our tectonic plates. The number of plates we want to generate, as well as what percentage of these will be oceanic/continental crust, is defined by a set of parameters. Then we just loop $N$ times, choosing a random vertex^[3] in each iteration and assigning it a random initial state (ID of the plate, type of crust, age, elevation and its initial velocity).

const auto count       = rand.uniform(plates_min, plates_max);
const auto ocean_count = static_cast<int>(std::floor(count * ocean_prop));
		
auto next_id       = std::int32_t(1);
auto open_vertices = std::vector<Vertex>();
open_vertices.reserve(static_cast<std::size_t>(count) * 10u);

for(auto i = 0; i < count; i++) {
	// Try to find a free vertex to use as a seed point
	if(auto seed_vertex = random_vertex(mesh, rng, [&ids = ids](auto v) { return ids[v] == 0; })) {
		const auto ocean = i < ocean_count; // First X plates are oceanic, rest is continental
		
		ids[*seed_vertex]   = next_id++;
		types[*seed_vertex] = ocean ? Crust_type::oceanic : Crust_type::continental;
		// Assign other properties based on crust type
		// ...

		// Remember the seed vertices, so we can use them for the flood-fill
		open_vertices.emplace_back(*seed_vertex);
	}
}

Most of the properties are pretty straightforward. The ID and crust type are directly defined in the code above. And the crusts age and elevation are then randomly chosen from a range of acceptable values for the given type of crust. The only property that is a bit more complicated to compute is the crusts initial velocity. Because I’ve opted to use a simple Cartesian coordinate system, the velocity is a 3D vector that could point in any direction. But, since the vertices are restrained to the sphere’s surface, the velocity should ideally be locally flat, i.e. perpendicular to the surface normal at any given position. Since our mesh is a sphere, we can derive the surface normal by normalizing the position vector of the current vertex. Based on this vector, we can then construct an orthonormal basis at this point, as shown in the code below^[4]. We can then generate a random 2D vector from an angle and a target velocity and transform it into the coordinate basis we just defined.

// Generate random 2D velocity vector
const auto angle  = rng.uniform(0.2f, 2.f * 3.141f);
const auto speed  = rng.uniform(0.01f, 1.f) * (ocean ? max_ocean_speed : max_continent_speed);
const auto vel_2d = Vec2{std::sin(angle), std::cos(angle)} * speed;

// Build 3D coordinate system at current vertex
const auto normal        = normalized(positions[*seed_vertex]);
const auto tangent       = cross(normal, Vec3(-normal.z, normal.x, normal.y));
const auto bitangent     = cross(normal, tangent);

// Transform the 2D vector to lay in the 3D plane defined by the tangent and bitangent
velocities[*seed_vertex] = vel_2d.x*tangent + vel_2d.y*bitangent;

Flood Fill

The final step of the process is then to iteratively grow each plate from its initial seed, until all vertices are assigned to a tectonic plate.

We already have a list of the seed vertices, that we memorized in the previous step. So, all we have to do now is iterate over each of these vertices neighbors, copy their properties to these neighbors, if they are still uninitialized, and repeat that recursively until there are no uninitialized vertices left.

auto new_opened_vertices = std::vector<Vertex>();
new_opened_vertices.reserve(open_vertices.size());

// Iterate until the last iteration didn't contain any new, formally unassigned, vertices
while(!open_vertices.empty()) {
	for(auto& seed : open_vertices) {
		for(Vertex n : v.neighbors(mesh)) {
			if(types[n] == Crust_type::none) {
				ids[n]           = ids[seed];
				types[n]         = types[seed];
				elevations[n]    = elevations[seed] + /* ... */;
				created_times[n] = created_times[seed] + /* ... */;
				velocities[n]    = normalized_velocity(positions[n], velocities[seed]);

				// Remember as starting point for next iteration of outer loop
				new_opened_vertices.emplace_back(n);
			}
		}
	}

	// Iterate again with the new points,
	// but in a random order to avoid growing the first plates larger than the rest
	rng.shuffle(new_opened_vertices);
	std::swap(new_opened_vertices, open_vertices);
	new_opened_vertices.clear();
}

The implementation is again relatively straightforward. We are using a secondary vertex-list, that we populate with the new vertices we initialized in this loop. Iterate over the previous list of seeds, to add each of their neighbors to their plate and remember them for the next iteration. And after each iteration of the outer loop, we swap the two vertex-lists and continue until we had one iteration where no new vertices have been assigned, so we know we are done. The only aspect we have to consider, is that this algorithm favors plates that are visited earlier because they tend to have more unassigned neighbors to “convert” to their plate. Since the first seed also adds its converted neighbors to the front of the next-iterations list, this effect could disproportionately grow the first couple of plates. To counteract this, we need to randomize the order of the vertices in each iteration, so it cancels out over multiple iterations. And as an added bonus, this also tends to generate less circular and more natural-looking shapes.

The process of assigning a new vertex to a seed’s plate is, as can be seen above, again pretty simple. Most of the properties are copied directly from the original plate, applying small perturbations to both the crust formation time^[5] and its elevation^[6]. The only property that needs additional consideration is (again) the velocity. Because the velocity vector should still be perpendicular to the new vertices surface normal, we can’t just copy it from the original vertex. Instead, we need to re-normalize it using the following function:

Vec3 normalized_velocity(const Vec3& position, const Vec3& velocity) {
	constexpr auto dt = 100.f;
	
	auto next_position = position + velocity * dt;                     // Move position one step with given velocity
	next_position      = normalized(next_position) * length(position); // Normalize new position back to sphere surface
	return (next_position - position) / dt;                            // Calculate actual velocity
}

The generated planet, with the area around each vertex highlighted in the plate's color. Shades of blue for oceanic sub-plates and shades of green for continental ones

The generated planet with arrows indicating each sub-plate's movement direction

With that out of the way, in the following posts we’ll look into the simulation algorithm, that iterates from this initial state to generate our terrain.

Plate Tectonics 1

Tue, 01 Mar 2022 00:00:00 +0000

Well, that was a bit of a longer pause, than I had hoped. So much for my “best intentions of documenting my progress”…

But I’ve finally managed to implement a working prove-of-concept for the plate simulation to generate terrain, also it’s still a bit rough around the edges.

Plate simulation (5x speed-up), consisting of about 2'500 triangles

While there are still many problems that need more work^[1], the general approach appears to work, at least.

But one thing that I noticed now is that the current tooling to visualize the results is not enough to test and debug the algorithm. So, before I continue working on the algorithm itself, I’ve decided to refactor and improve the editor to better visualize the generated data and allow users to modify the intermediary results. But first, it’s probably a good idea to document how the current implementation of the plate simulation works^[2].

The plate simulation in its current form is heavily inspired by the work of Cortial et al. in their 2019 paper Procedural Tectonic Planets. However, there are some aspects where my implementation diverges. Either because the paper didn’t provide details about a specific part of their implementation or because I think it will fare better, with my specific goals in mind.

Procedural Tectonic Planets

As the algorithm is relatively complex, I’ve split this post into multiple entries. In this one, we’ll look at how the tectonic plates are modelled and get an overview of the simulation on an abstract level and the following posts will then go into more detail about

The generation of the initial state (i.e., the planet and its plates, that we use as input for the actual simulation)
How plates are moved across the sphere’s surface and how that effects the elevation
How collisions and intersection between plates are resolved and when/how new crust is generated
When and how plates are merged or split (i.e. suturing and rifting)

Enough plate tectonics to be dangerous interesting

But first, let’s recap what I want to achieve with the plate simulation. The main focus of this step is to generate high-level terrain features, that look as realistic as possible^[3], at a resolution of about 1000 km² per data-point. Of course, for any practical use-case, as well as features like rivers, we’ll need a much higher resolution. My hope is that (similar to Undiscovered Worlds and the followup paper by Cortial et al. from 2020 “Procedural-Tectonic-Planets”) I will be able to later generate a more detailed small-scale view, based on the output of this high-level simulation.

To achieve these realistic results, I planned to stray as little as possible into the fun and easy, but unpredictable and boring world of random noise. Instead, I wanted to try to stay as close as reasonably possible to the physical reality^[4]. The problem with that is that plate tectonics is actually a quite complex 3D problem^[5] and a bit difficult to observe at the time-scales I’m interested in. So, I obviously can’t really hope to accurately simulate even a couple of years of plate movement on my target hardware, much less the millions of years I’ll need.

Luckily, I only really want to fool humans. So, the algorithm doesn’t have to be perfect, but only slightly more capable than the average observer and (as others have already demonstrated) I should be able to ignore a surprising amount of the more complicated aspects and only focus on some of the more obvious high-level features.

Plate-Interactions and the Wilson Cycle

The one thing I definitely can’t avoid to model are the tectonic plates themselves. So first, I should probably summarize what I understand about the physical processes, before I explain how I simplified them for my model^[6].

Tectonic activity map of the Earth^[source]

Tectonic plates are disjointed pieces of the Earth’s crust, that “float” on top of the mantel. Their movement is driven by convection currents in the upper mantle, that are in-turn influenced by the properties and interactions of the plates above. A common misconception^[7] is imagining the plates as solid ridged stone slabs, that float on top of liquid magma. Also, this a nice simple visualization, it’s important for their interactions to understand that both the crust and the mantel are actually solids. It is only over these long geological time-scales that the mantle behaves similar to a high-viscosity fluid. But over these time-scales, the crust also exhibits less rigid and more elastic properties, which enables some of the deformations we observe.

A nice simple model, that nonetheless contains all the high-level aspects I’m interested in, is the Wilson Cycle, that describes the formation and breakup of supercontinents as a series of stages.

Visualization of the Wilson Cycle^[source]

One essential factor in this model is the density of the crust that makes up the tectonic plate. While their composition is again quite complex, the crust can be classified into two general types: Continental crust, that has a relatively high density and makes up most of the dry landmass, and oceanic crust, that has a comparatively high density and makes up most of the deep ocean floor. Because the crust floats on top of the mantle, its density not only determines “how high” it floats, but also how it behaves when it gets thicker or thinner and how it reacts to collisions with other plates.

It’s important to note here, that this distinction is not as cut and dry as one might hope. Instead, it’s more of a categorization, based on the density of the average composition of the crust in an area. Which means, while there are some plates that consist mostly of continental/oceanic crust, most plates consist of both (as can be seen on the map above). And It’s also not uncommon for oceanic crust to end up on dry land, as well as for continental crust to be part of an ocean. But to keep the following descriptions as concise as possible, I’ll use the terms “continental plate” to describe a plate that mostly consists of low-density material in the relevant area and “oceanic crust” for high-density.

Considering all this, there are five types of interactions between plates we need to model:

Transform boundary: Two plates moving past each other^[source]

Divergent boundary: Two plates moving away from each other^[source]

Convergent boundary (CO): An oceanic and a continental plate colliding with each other^[source]

Convergent boundary (OO): Two oceanic plates colliding with each other^[source]

Convergent boundary (CC): Two continental plates colliding with each other ^[source]

Transform boundaries mostly just cause earthquakes, and are therefore not really of interest to us. So, we only have to look at convergent and divergent boundaries.

Divergent boundaries are relatively simple. The two plates move apart and mantel material wells up between them, which begins to a new ocean, once they have moved sufficiently far apart.

The most interesting boundaries are the convergent once, which we have to further distinguish into three subtypes based on the density/type of the involved crust:

Continental-Oceanic (CO): The type of boundary we can see in the animation above. Here the denser oceanic plate is subducted under the continental plate, forming a trench between them, and starts to sink into the mantel. Once the subduction started, the weight of the already subducted plate also pulls on the remaining part, further speeding up the process. As the water subducted with the plate lowers the melting-point of the mantle material, it begins to partially melt, causing magma to rise and a volcanic mountain range to form^[8].
Oceanic-Oceanic (OO): Quite similar to CO boundaries, except that the two plates are much more similar in density. But the principle remains the same, meaning the higher-density plate subducts, which will usually be the older of the two. This type of collision forms deep oceanic trenches and island arcs.
Continental-Continental (CC): In contrast to the other two, there is no significant subduction here because both plates are too low-density to sink into the mantel, and are instead uplifted to create large mountains like the Himalayas.

Another interesting aspect, that is currently not implemented, is the formation of mid-plate volcanos, like the one that formed the Hawaiian islands. These are not caused by plate interactions, but are instead thought to be fed by hotspots in the mantle. Hence, they are mostly stationary and cause island arcs to form, when the crust above them moves.

Discretization of Space

The most obvious simplification in my model is that I’m using an extremely coarse discretization of the simulated space. In this step, I only really care about the rough shape of tectonic plates and large mountains, which doesn’t require much in terms of resolution.

As I’ve already outlined in the previous blog posts, I’m modelling my planets as triangle meshes with data stored on the vertices, faces and edges, instead of a more structured/uniform grid. This allows for a dynamic adjustment of the resolution in interesting (i.e. especially active) areas, without having to store detailed data about large stretches of empty boring ocean.

The simulation at the top consist of about 2’500 triangles and 1’300 Vertices, that are more or less evenly distributed on the surface (510’064’471 km²), which gives us a resolution of about 400’000 km² per Vertex.

One of the next steps will be to improve the subdivision algorithm, so I’ll end up with about 1’000’000 km² in mostly empty/flat areas and 1’000 km² - 100’000 km² near the coastline and mountains.

Reduced Dimensionality

There is one more way we can reduce the space we need to simulate: reduce the number of dimensions

While actual plate tectonics is a complex 3D problem — with complicated fluid dynamics and the isostatic equilibrium determining how plates interact and how high/low pieces of crust “float” — in this simplified model we can ignore most of this and only focus on the position of the plates on the surface and their elevation.

Visualization of the tectonic plates, consisting of multiple sub-plates, each with their own velocity, type, and elevation

To summarize, the planet is modelled as a triangle mesh^[9] where each vertex describes the properties of the crust in the surrounding area. To form tectonic plates, multiple connected vertices are grouped together by assigning them an integer ID. Or put another way, the vertices describe sub-plates, that are part of a larger tectonic plate.

So, each vertex stores the following information:

The ID of the plate it belongs to
Its elevation, i.e. the average elevation of this area’s crust (negative for areas below sea level)
If it contains (mostly) continental or oceanic crust
Its velocity
When the crust formed, i.e. how old it is

Since each vertex is connected by an edge to its nearest neighbors, forming a Delaunay triangulation, we can inspect this mesh to detect collisions, traverse the plates and store additional information required for the simulation on its edges.

This is also one of the major differences to the work of Cortial et al., since they appear to store each plate as an individual spherical triangulation of points, instead of one coherent mesh. While keeping the plates as separate triangulations would simplify some parts of the algorithm (collision detection/resolution) my hope is that a single coherent mesh will make it easier to reuse the structure for both other simulations (water-shed, weather patterns, …) and rendering.

Simulation

On the simplest level, all we are doing to simulate plate tectonics is moving vertices around on the sphere’s surface and handle collisions by adding/removing vertices, changing the topology or modifying their elevation.

The movement itself is extremely simple. Since the vertices already know their position and velocity, all we need to do is apply the well-known equations of motion to calculate their new position on each time-step with: $x_{n+1} = x_n + v_n t + a_n t^2$

Some vertices belonging to different plates (green/blue), as well as their velocities, connections and a visualization of some of the forces that affect them: Orange spring-damper systems between vertices of the same plate and red force-generators between different plates, that pull/push vertices based on more complicated rules.

The interesting part is how we determine the vertices (i.e. sub-plates) accelerations $a_n$ . This is the second part where we deviate from the work of Cortial et al., in part because of our different data model. Since all vertices are part of the same Delaunay triangulation, we can make the simplifying assumption that a vertex is only significantly affected by its direct neighbors, without introducing too many noticeable errors. Hence, we can use the same general system to calculate both the interaction between sub-plates belonging to the same tectonic plate and interactions between different plates.

This system can be thought of as similar to a spring-damping model based soft-body simulation. The vertices are treated as point masses, and each edge applies a force on its origin and destination based on its properties and the type of boundary the edge represents:

Both vertices belong to the same plate: The force is calculated by a damped spring, that causes the sub-plates to retain their initial distance but allows for some deformations.
Divergent boundary: A small ridge-push force is applied, that moves the vertices further apart.
Convergent boundary (CC): A force, proportional to the velocity along the convergence direction and the distance between the plates, is applied to resist the collision until the plates either separate again or are sutured together.
Convergent boundary (OC or OO): The denser of the two sub-plates is slowly subducted under the other and a force is applied to the subducting plate to simulate the slab pull

Forces are not just modelled based on the primal edges (gray lines), but also for their duals (dashed white line), which connect the faces and the left/right of the primal edge. But in this case, they are modelled as springs which connect the left and right vertices.

It should be noted that that model outlined here would not work for soft-body simulations, in the general case. Because we rely exclusively on the triangle edges to calculate forces, we are missing many springs that should normally be present in such a system, to prevent shearing and bending. However, in our case we avoid such artifacts because the individual vertices are (a) constrained to the sphere’s surface, (b) cover the whole sphere and we (c) prevent self-intersections and non-manifold geometry. This effectively limits the simulation to 2D, also the surface itself is a 3D sphere, and doesn’t allow for bending, folding or significant shearing, which would otherwise occur.

However, using just the edges of the primal mesh is not sufficient because of another reason: During the simulation the mesh is continuously updated, which includes flipping edges. Since this effectively removes springs, which are potentially under compression/tension, from the model and adds new ones, between formally unconnected vertices, which would then be in a relaxed state, this would create artifacts like heavy deformation of continents or loss of land area^[10]. To solve this, we don’t use only primal but also dual edges, which apply forces to the two vertices opposite of the corresponding primal edge (see image above). Because of this, when an edge is flipped, the spring-parameters can be swapped between the primal and dual edge, thereby conserving the spring’s stored energy and avoiding these kinds of artifacts.

Apart from the plate movement itself, there are also some other steps we need to take care of, that will be the focus of the next posts:

The elevation of each sub-plate is updated near convergent and divergent plate boundaries, based on their separating velocities.^[11]
Moving the vertices sometimes causes self-intersections of the mesh, that have to be fixed by removing one of the vertices. Since all triangles are restricted to the sphere’s surface and have the same winding-order, these artifacts can be detected by checking if a face has been inverted, i.e. its normal points in the opposite direction than the sphere’s surface normal.
The vertices’ movement also frequently causes the Delaunay condition to be violated, which means we have to check and possibly restore it after each iteration. Since the number of violations is usually small, this is currently done by flipping edges that don’t pass the circumference-condition until the Delaunay triangulation is restored.
And finally, there are steps that create/destroy vertices, either because of rifting/subduction or because an area needs more/less detail and thus vertices per km².

[Algorithm-Outline] After this high-level overview, here are the detailed steps each iteration of the simulation goes through, which the next couple of posts will look at in more detail:

Add vertices where more details are needed and remove vertices unessential ones
Compare the properties of neighboring sub-plates to determine if they belong to the same tectonic plate or fall into one of the boundary zones discussed above (transform, divergent, convergent CC/OC/OO)
Create new oceanic crust at divergent boundaries
Calculate all forces acting on the sub-plates
Calculate the acceleration of all sub-plates, based on the forces acting on them, and utilize Verlet integration to calculate their new velocities and positions
Update each sub-plate’s elevation, if they are part of a subduction or collision zone
Check for collisions and resolve them
Check and restore Delaunay condition, if required ^[12]
Simulate erosion
Combine colliding continental plates and split plates that have gotten too large

Conclusion

To summarize, the algorithm is heavily based on the 2019 paper Procedural Tectonic Planets by Cortial et al., with the following noteworthy modifications:

The plates are not modelled as individual triangulation, but instead the complete planet forms a coherent triangle mesh, whose topology is continuously updated during the simulation. My hope here is that this will be more suitable for later simulations and allow for an easier integration with other parts of the system, even though it sadly makes the actual plate simulation a bit more difficult.
Since the paper’s focus is the interactions between plates, the implementation of the movement itself was sadly not describes in any detail. Because of this — and enabled by the different triangulation approach — I’ve chosen to model the plate’s movement similar to a particle-based soft-body simulation. This should also allow for more plastic behavior and interesting deformations of plates during collisions.
The last difference, that I’ll discuss in one of the following posts, is that collisions between plates are handled differently. Instead of resolving collisions immediately when they are detected, the different representation allows us to derive stresses at plate boundaries and ongoing collision and thus solve collisions over multiple iterations, which should (hopefully) generate more natural-looking results.

That should be about it for this high-level overview of the plate simulation. And in the next post we’ll look in more detail at how the initial planet is generated, before the actual simulation starts.

Modifying Meshes

Sat, 15 May 2021 00:00:00 +0000

This will (hopefully) be the last post about geometry and the Mesh-API, before we can start with the actual generation algorithms.

We’ve already defined a basic data structure for our geometry, implemented algorithms to traverse it and, in the last post, constructed a spherical Delaunay triangulation of random points, distributed evenly on a sphere.

So, the only part of the API that is still missing are functions to modify existing meshes. The three fundamental operations we’ll define for this are:

class Mesh {
  public:
	// ...
	
	void   flip    (Edge e);
	Edge   split   (Edge e, float split_point);
	Vertex collapse(Edge e, float join_point);
};

Edge Flip

The first of the three operations is the edge flip, that we’ll need later to restore the Delaunay condition of our mesh after vertices have been moved^[1].

The effect of an edge flip is relatively straightforward. It just takes the edge, that is passed to it, and rotates it counterclockwise in the quad formed by the four surrounding vertices, as seen below:

Initial mesh before flip

Mesh after flip(e)

What we’ve ultimately done here is we removed the passed edge, to transform the two neighboring faces into a quad, and then created a new edge between the previously unconnected vertices to split it into two triangles again. From this, we also see that we can’t flip edges at the boundary of our mesh, since those only have a single “real” face.

Our implementation is further simplified by the fact that we don’t need to handle multiple cases, like did for add_face(). The reason is that there are only two possible ways to split a quad, which means the result is always unambiguous, regardless of which part of a quad-edge we pass as the argument. That means flip(e), flip(e.rot()), flip(e.sym()) and flip(e.inv_rot()) are all equivalent, and we can just normalize the input with e = e.base() and ignore all other cases, like flipping dual edges.

As always, there are two parts to this operation: Updating the primal mesh and its dual counterpart:

Primal Mesh

The update of the primal mesh is pretty straightforward. We just need to remove e and e.sym() from their old and add them to their new edge-rings.

Because we need to traverse the mesh during our modification, we have to be careful that we only override the data after we’ve read the required information. Therefore, we have to load and cache all values before we can write the new values to the Mesh member variables. So to make our lives easier and the code more readable, we use new_origin_next to memorize the new values and only apply them at the end using a simple class like this:

template <typename Value, std::size_t N>
class Edge_changes {
  public:
	// Array-Access-Operator reserves space for the new value
	//   and returns a reference to it
	Value& operator[](Edge e) {
		assert(next_idx_ < int(new_values_.size()));
		auto& e = new_values_[next_idx_++];
		e.first = e.index();
		return e.second;
	}

	// Apply the recorded changes to the given vector
	void apply(std::vector<Value>& out) {
		for(int i = 0; i < next_idx_; i++) {
			auto&& [index, val] = new_values_[i];
			out[index]          = val;
		}
	}

  private:
	std::array<std::pair<uint32_t, Value>, N> new_values_;
	int                                       next_idx_ = 0;
};

// Later instanciated with
auto new_origin_next = Edge_changes<Edge, 6>{};

This allows us to write the following code, to update all affected primal edges:

// Remove e and e.sym() from their current edge-rings
new_origin_next[e.origin_prev(mesh)]       = e.origin_next(mesh);
new_origin_next[e.sym().origin_prev(mesh)] = e.sym().origin_next(mesh);

// Add e to its new edge-ring
new_origin_next[e.dest_next(mesh)] = e;
new_origin_next[e]                 = e.origin_prev(mesh).sym();

// Add e.sym() to its new edge-ring
new_origin_next[e.origin_next(mesh).sym()] = e.sym();
new_origin_next[e.sym()]                   = e.dest_prev(mesh);

// ...

// Check if the original origin/dest vertices referenced the flipped edge
//   and set them to one of the remaining edges, if required
if(vertex_edges_[e.origin(mesh)] == e)
	vertex_edges_[e.origin(mesh)] = e.origin_next(mesh);
if(vertex_edges_[e.dest(mesh)] == e.sym())
	vertex_edges_[e.dest(mesh)] = e.sym().origin_next(mesh);

// Update the origin
primal_edge_origin_[e.index()] = e.origin_prev(mesh).dest(mesh);
primal_edge_origin_[e.sym().index()] = e.origin_next(mesh).dest(mesh);

// Apply the changes
new_origin_next.apply(primal_edge_next_);

Dual Mesh

Updating the dual mesh might look more complex at first because the flip also changes which faces are neighboring each other, but it’s actually simpler, because the edge-rings around faces are much more restricted. Since every face has exactly three outgoing edges and all flips are identical, we can just look at our diagram and see that we only need to swap two dual edges from the rings around e.left() and e.right().

Initial mesh before flip, with the two edges of the dual mesh that have to be moved highlighted.

Mesh after the flip(e). The dual edge de1 has been moved to the left and de2 to the right face, after e.rot() and e.inv_rot() respectively.

// Move edge from left face to right face
const auto edge_from_left      = e.inv_rot().origin_next(mesh);
const auto edge_from_left_prev = e.rot().origin_prev(mesh);
new_dual_origin_next[edge_from_left]      = e.rot();
new_dual_origin_next[e.rot()]             = edge_from_left_prev;
new_dual_origin_next[edge_from_left_prev] = edge_from_left;

// Move edge from right face to left face
const auto edge_from_right      = e.rot().origin_next(mesh);
const auto edge_from_right_prev = e.inv_rot().origin_prev(mesh);
new_dual_origin_next[edge_from_right]      = e.inv_rot();
new_dual_origin_next[e.inv_rot())          = edge_from_right_prev;
new_dual_origin_next[edge_from_right_prev) = edge_from_right;

// ... Update the primal mesh, as seen above ...

// Set the edges for the modified faces to one of the edges
face_edges_[e.left(mesh)] = e;
face_edges_[e.right(mesh)] = e.sym();

// Update the origin
dual_edge_origin_[edge_from_left.index()]  = e.right(mesh);
dual_edge_origin_[edge_from_right.index()] = e.left(mesh);

// Apply the changes
new_dual_origin_next.apply(primal_edge_next_);

Edge Split and Collapse

One of the key advantages of representing our map as a triangle mesh, is that we can dynamically add/remove vertices to change the local resolution of our data. That means that we can use far fewer vertices in the middle of the ocean, where we don’t care about most terrain features, and use that storage for the parts that actually interest us instead.

To achieve this, we need two operations, one to add a new vertex at a given point and one to remove it again:^[2]

Edge split(Edge e, float split_point): Takes an edge and a position on this edge ^[3] and splits the edge into two new edges, creating a new vertex at the given position and inserting edges and faces left/right of the edge, as required. The returned value is the new half of the split edge, pointing from the new vertex to the original destination.^[4]
Vertex collapse(Edge e, float join_point): Takes an edge and a position on it and collapses the edge, merging the origin() and dest() into the specified location, as well as merging its left()/right() faces and their supporting edges.

As can be seen in the following image, we can interpret the operations as each other’s inverse.

Executing split(e, 0.25f) transforms the left mesh into the right one, inserting a new vertex — 25% along the way between the origin and destination of e —, two faces (F_L and F_R) and three quad-edges.

Executing collapse(e', 1.f) reverses this operation. The edge e’ is removed and its origin and destination are collapsed into a single vertex, that keeps the position of the destination (100% along the way from origin to destination).

While the implementation is a bit more intricate because we have more edges to consider, it follows the same procedure as flip(), i.e. connect the edges into valid edge-rings. Thus, I won’t go into too much detail here and focus on the preconditions and how deletions are handled, instead.

Preconditions for `split()`

The precondition of split() is quite simple — simpler even than for flip() — because it works on any edge with at least one face, which includes boundary edges. That is also the one special case we need to handle in the implementation: Are both faces present or are we splitting a boundary edge and the left/right face is missing.

Preconditions for `collapse()`

The situation for collapse() is quite different, however. Although, it could also function with any valid edge with at least one face, collapsing some edges might create invalid meshes. What all of these invalid cases have in common, is that collapse() would have to collapse more than the left/right faces, or it would leave unconnected edges/vertices behind. So, to detect them and avoid creating these corrupted meshes, there are two conditions we need to check first.

1. The Link Condition

The first thing we have to check is that the edge we want to collapse satisfies the link condition, defined in the 1998 paper “Topology Preserving Edge Contraction” by Dr. Tamal Dey et al, that guarantees that our manifold mesh will still be manifold after the collapse().

Its formal definition is, given the edge $e$ between vertices $v_1$ and $v_2$ :

\text{one-ring}(v_1) \cap \text{one-ring}(v_2) = \text{one-ring}(e)

Put simply, this means that every vertex that is connected to both $v_1$ and $v_2$ also has to be part of the face on the left or right side of $e$ . When put like this, we can also see the problem, that would arise if we ignored this condition: After we collapsed $e$ , there would be multiple distinct edges between the same two vertices, $v_1$ and $v_2$ .

An example of an edge that doesn’t satisfy the link condition. The origin and destination of e are both connected to the vertex V_P, which means the intersection of their one-rings contains the vertex V_P, that is missing in the one-ring of e.
This means that we would have to also collapse some of the edges and faces around V_P or produce a non-manifold mesh. Which is why this case is forbidden.

To check this condition, we can just iterate over the edge-ring around e.origin() and check if one of its neighboring vertices is also a neighbor of e.sym(). For this, we can utilize the Edge::origin_ccw() method, that returns a range of all edge in the origin-edge-ring, and the std::find_first_of algorithm, that tries to find the first matching element between two ranges. Of course, when iterating over the edge-rings we have to skip the first element, which is e itself. But we also need to skip the edge after that, if there is a face on that side of e because these edges are still part of the left/right face.

// Iterator ranges over the two edge-rings, starting from the edge after e (the edge we are collapsing)
// We also need to skip the vertex of the neighboring face, if there is one
const auto origin_edges = e.origin_ccw(mesh).skip(left ? 2 : 1);
const auto dest_edges   = e.sym().origin_ccw(mesh).skip(right ? 2 : 1);

// Check if there is an edge in the two ranges that share a common destination vertex
const auto iter = std::find_first_of(origin_edges.begin(),
                                     origin_edges.end_iterator(),
                                     dest_edges.begin(),
                                     dest_edges.end_iterator(),
                                     [&](Edge oe, Edge de) { return oe.dest(mesh) == de.dest(mesh); });

if(iter != origin_edges.end()) {
	// If there is such an edge the link condition is not satisfied
	yggdrasill::make_error(out_error, YGDL_ERROR_CODE_MESH_CORRUPTION, [&] {
		return "The link-condition is not satisfied for the edge passed to collapse()";
	});
	return no_vertex;
}

2. Vertices Shared by Unconnected Faces

While we can find most problematic cases by checking the link condition, there are still some we need to check separately, that are caused by our less restrictive mesh definition (e.g. unconnected sub-meshes, faces connected by only one vertex, unclosed meshes, …).

One of these is the “forbidden case” we excluded in add_face(), but now coming from the opposite direction. That is, we can’t collapse an edge if that would result in a vertex that is shared by multiple unconnected faces.

We can identify this case by checking if there are multiple boundary edges originating from e.origin() or e.dest() that are missing a face on the same side. Coincidentally, this also catches another minor error-case: When we collapse the last face of an unconnected sub-mesh, we would leave behind vertices without edges.

if(e.left(mesh) != no_face && e.right(mesh) != no_face) {
	// We only need to check this, if e is not already a boundary edge

	// We want to check if there are any edges in the given range, that don't have a right face
	auto has_right_boundary = [&](const auto& edge_range) {
		return std::any_of(edge_range.begin(), edge_range.end_iterator(),
		                   [&](Edge e) {return e.right(mesh) == no_face;} );
	};
	
	// ... and we want to check if that is the case around both the origin and destination of e 
	if(has_right_boundary(e.origin_ccw(mesh)) && has_right_boundary(e.sym().origin_ccw(mesh))) {
		yggdrasill::make_error(out_error, YGDL_ERROR_CODE_MESH_CORRUPTION, [&] {
			return "Requested edge collapse would cause a corrupted mesh (multiple unconnected faces "
			       "on the same vertex) or a dangling vertex";
		});
		return no_vertex;
	}

} else if(e.left(mesh) == no_face && e.right(mesh) == no_face) {
	// The edge e is not part of any faces, which means the initial mesh is not valid to begin with
	yggdrasill::make_error(out_error, YGDL_ERROR_CODE_MESH_CORRUPTION, [&] {
		return "Corrupted mesh. The edge that should be collapsed is not part of a triangle";
	});
	return no_vertex;
}

Handling Deletions

Although, we now know how our data structure needs to change on split() and collapse(), there is one point we glossed over, which we briefly touched on when we first defined our mesh structure: Deleting elements of our mesh (vertices, faces and edges)

As we have seen above, collapsing an edge effectively deletes it, as well as its destination, bordering faces and some of their edges. But that is a problem because we can’t just directly delete part of our Mesh structure since we store all data of our elements in continuous vectors. So if we would just delete e.g. an edge from this structure, we would need to move all following values to close the gap and keep everything contiguous. However, that would not just be extremely inefficient for larger meshes, but also disturb our IDs. Remember that the ID of an element is also the index in the corresponding data-vector^[5]. So if the index would change, that in turn would also change its ID, which we use everywhere to reference it. Which means we can’t do that and need an alternative solution.

Luckily, we already reserved one special ID for each of the element types, to represent a missing or invalid element (no_edge/no_vertex/no_face), which we can utilize now. So, when we have to delete an element, we will instead memorize its ID in a vector (called a free-list) and set all its values in the Mesh to this invalid state. And then when we later need to create new vertices, edges or faces, we can check this free-list first before allocating new storage, to fill in these “holes” the deletions left behind.

Of course, if we never really delete elements but just mark them as deleted, we must take care that they are never referenced or returned from any of our function. Following the algorithm outlined above, there already should never be any part of the mesh that references the vertices/edges/faces that were deleted, since these references were overridden by new values. So, the traversal operations should already work as expected, without any further work from our part. But where we need to do extra work is when we iterate over all vertices/faces/edges in the mesh. These operations would normally just iterate over all indices and return the corresponding IDs. Thus, we must add an extra check in the iterator, that reads one of the elements values from Mesh and checks whether it is set to a valid value.

Although, this means extra work on a relatively common operation, a linear read and comparison of 32-Bit integers should not impact us much^[6]. Hence, at least for the expected use-case, where meshes don’t shrink over time^[7], this should be pretty efficient.

Handling Topological Changes in Data Layers

Before we can (finally) close this chapter, there is one last aspect that deserves attention: How the data layers react to changes

As already mentioned, we’ll store all our data in layers that bind values of various types to parts of our mesh (vertices, faces and directed or undirected edges of the primal/dual mesh). So, when we modify the mesh itself, that will obviously affect the layer values for elements we added or deleted. But it might also invalidate information that was used to compute the values, e.g. if we flip() an edge no parts of the mesh are deleted, but some edges will be connected to entirely different vertices.

Hence, we’ll need a way to automatically modify layers if the mesh is changed, which is actually one of the reasons why we’ve defined the overarching World structure that contains both the mesh and all layers. So, when one of the modification operations of the mesh is called, we can just access the layers through our parent World, lock them for modification and apply any necessary changes to them.

Of course, that begs the question of what changes would be necessary. When we modify the mesh, we already know which parts of the mesh will be affected in what way. And through the World class and the Layer_info objects stored there, we can also determine which layers contain values that are linked to these affected elements. But the decision how values should be changed depends on the semantics of the concrete layer, which we’ll store in the Layer_info as two enumerations, one for each major type of topological change^[8].

Deletion and Modification

The first (and easier) of these two covers the case when data is completely invalidated. Either because the part of the mesh that is referenced has been deleted or because the origin()/dest() of an edge changed. And the enum that describes the possible reactions is:

enum class On_mesh_change {
	keep,            // The value is not changed
	reset_affected,  // The value is reset to its initial value (normally 0)
	reset_all,       // ALL values of the layer are reset
	remove_layer     // The layer is deleted entirely
};

Creation and Merging

The second enumeration is a tad more complicated because it’s not used for invalidated or removed elements, but to calculate entirely new values.

This one is used every time a new element is inserted (new vertex, faces and edges) by split(), to interpolate its value based on its two neighbors^[9], or when collapse() merged the two vertices of an edge into one^[10]:

enum class Interpolation {
	dont_care,
	reset_affected,
	reset_all,
	remove_layer,
	keep_src,
	keep_dest,
	lerp,
	slerp,
	min_value,
	max_value,
	min_weight,
	max_weight
};

Because the behavior might not be obvious from their names alone, it’s perhaps better to show what their result would be for different inputs^[11]:

Name	Description	Src	Dest	Weight	Result
`dont_care`	Don’t set the value	…	…	…	…
`reset_affected`	Reset to initial value (usually 0)	…	…	…	0.0
`reset_all`	Reset all values in the layer	…	…	…	0.0
`remove_layer`	Remove the entire layer	…	…	…	…
`keep_src`	Always keep the source value	0.1	…	…	0.1
`keep_dest`	Always keep the destination value	…	0.9	…	0.9
`lerp`	Linearly interpolate between the two values	0.1	0.9	0.5	0.1+0.5*(0.9-0.1) = 0.5
`slerp`	Linearly interpolate on a sphere ^[12]	(1,0,0)	(0,1,0)	0.5	(0.71, 0.71, 0)
`min_value`	Keep the smaller of the two values	0.1	0.9	…	0.1
`max_value`	Keep the larger of the two values	0.1	0.9	…	0.9
`min_weight`	Keep the value with the smallest weight	0.1	…	0.6	0.1
`max_weight`	Keep the value with the largest weight	…	0.9	0.6	0.9

And finally, here are some examples that show how this functionality will be used in practice:

// The layer that stores the vertex positions.
// Since all points have to be located on the surface of a sphere, 
//   the interpolation has to make sure that they stay there
constexpr auto position_info  = Layer_info<Vec3, Layer_type::vertex>("position")
								.interpolation(Interpolation::slerp)
								.on_mesh_change(On_mesh_change::reset_affected);
								
// Each vertex is also assigned to a specific tectonic plate, by giving it an ID.
// Since we can't interpolate between IDs, we instead pick the one of the nearest vertex
constexpr auto layer_plate_id = Layer_info<std::int32_t, Layer_type::vertex>("plate_id")
								.interpolation(Interpolation::max_weight)
								.on_mesh_change(On_mesh_change::reset_affected);
                                        
// We also need to memorize the distance between sub-plates/vertices.
// These are assigned to the edges between vertices (independent of their direction).
// But if the topology changes we can't recompute them with the logic outlined above,
//   so instead they are reset to a known value (-1.0) and recomputed as needed.
constexpr auto layer_distance = Layer_info<float, Layer_type::edge_primal>("plate_distance")
								.initial(-1.f)
								.on_mesh_change(On_mesh_change::reset_affected)
								.interpolation(Interpolation::reset_affected);

Summary

That should be all fundamentals we require for now, and our current architecture looks something like this:

We have a Mesh class that describes the topology of our generated world as a Delaunay triangulation, in terms of vertices, faces and edges — i.e. a set of places and information about how they are connected — and allows us to traverse and modify it
All the actual data is stored in Layer objects — whose properties are defined in Layer_info structures — that contain things like the position of our vertices, their elevation above sea level, their temperature, …
Both of these are combined into a World class that manages them, e.g. resizes and modifies layers if the topology changes
The code that actually generates the world consists of independent modules that are sequentially invoked on the same World object to incrementally fill it with additional information and advance the simulation
- So, the only way for these modules to interact with each other is through layers or modifying the mesh itself
- These will also be the main focus of the next posts, where we’ll dive into the actual plate simulation

World mesh creation

Sun, 02 May 2021 00:00:00 +0000

In the last post we’ve looked at how we can store our geometry, how we can traverse the resulting mesh and how we’ll later store our actual data. But one aspect we haven’t looked at yet is how such a mesh data structure can be constructed in the first place, i.e. how we get from a soup of triangle faces to a quad-edge mesh.

There are two basic operations defined in the original paper to construct and modify meshes:

MakeEdge: Creates a new edge e and its corresponding quad-edge
Splice: Takes two edges a and b and either connects them or splits them apart, if they are already connected.

While these two operations are powerful enough to construct any quad-edge mesh and apply any modification we might want, they are not ideal for our use-case. First they are rather more complex to use, than I would like for everyday use because they require quite a bit of knowledge about topology and use concepts that are not as easy to visualize as faces in a triangle mesh. And secondly, they allow for structures that we don’t actually want to support, like non-triangular faces.

So, what we will do instead is define our own operations, to make our use case as easy as possible. In this post, we will first look at just the construction of a new mesh, for which we’ll define two functions:

class Mesh {
  public:
	// Create a new vertex, that is not connected to anything (i.e. its vertex_edge is no_edge)
	Vertex add_vertex();
	
	// Connect the three passed vertices into a new triangle face (in counterclockwise order)
	Face   add_face(Vertex a, Vertex b, Vertex c);
};

While these operations are much easier to use, their implementation is also quite a bit more complex. So, to make this less theoretical, we’ll first take a look at how they will be used to construct a spherical mesh for our world, before we get into the implementation details.

Creating a Sphere

As stated in the first post, I want to initially focus on generating spherical worlds. The first step of this will be generating and simulating tectonic plates. Of course, plate tectonics in the real world are much more complex than I can hope to simulate. But I’m not aiming for perfect, just close enough to look realistic, and I’m mostly interested in the high-level features like mountain ranges and not so much in the complex formation, layering and folding of plates.

My simplified model will primarily be based on the work of Cortial et al., deviating on some details where it suits my specific goals or where the paper didn’t specify enough details.

The basic approach is modelling tectonic plates as a set of points on the surface of a sphere, not dissimilar to particle based fluid simulations. So, the first step is to evenly distribute a number of sampling points on the surface and then partition them into individual plates. By doing this, we simplified a complicated 3D phenomenon into a manageable 2D one, which means that we’ll lose many of the complex details — like folding of plates — but terrain features like mountain ranges and coastlines should hopefully still be retained.

Not entirely coincidentally, this model maps quite well to the triangle mesh we’ve defined so far. Each of our vertices will be a sampling point — representing the properties of the voronoi cell around it — and connected through edges to its nearest neighbors. This will also simplify the simulation because when we need to calculate the interactions with every neighboring voronoi cell, we just need to iterate over all neighbors of the vertex.

UV Sphere^[source]

Cube Sphere^[source]

Subdivided Icosahedron^[source]

So first, we must distribute our vertices (i.e. sampling points) on the sphere’s surface. To have the ideal starting conditions for the simulation algorithms, the points should be evenly distributed on the surface. That means that the distance between the two closest vertices should be as large as possible. Perhaps surprisingly, evenly distributing points on a sphere is a quite difficult problem. But there are several common ways to define such spherical meshes, the most common of which are:

UV Sphere: Uses rings of square faces to cut up the sphere, similar to the latitude and longitude lines used in cartography. While it approximates the surface of a sphere pretty well, the distribution of vertices is very uneven, especially at the poles and equator
Cube Sphere: Starts with a cube, whose faces are then tessellated, and the vertices are projected onto the surface of the sphere. The nice property of this mapping is that it enables an easy mapping of the sphere back onto the flat cube surfaces. But while it’s less unevenly distributed than UV-Spheres, the distribution is still far from uniform.
Subdivided Icosahedron: This is probably the most common way to define a sphere mesh with evenly distributed vertices. The shape starts as an icosahedron with 12 vertices that loosely approximates the sphere. To get a better approximation, the next step is to subdivide its triangular faces into smaller triangles and then project each vertex onto the sphere’s surface. After a couple such subdivisions, this approximation gets relatively close to a real sphere, while the uniform distance between its vertices is conserved, which would make it a nice option for us. But a limitation of this approach is, that the number of vertices is defined by the number of subdivisions and increases quadratically (12, 42, 162, 642, 2562, …), which limits our options for the initial resolution more than I would prefer.

Rotating Fibonacci Sphere

The subdivided Icosahedron would probably work for us, but I don’t particularly like the restrictive vertex count options forced upon us by the recursive subdivision. Hence, we’ll instead use Fibonacci Spheres, which have a similar nice uniform distribution, but are not limited to particular vertex counts.

I won’t go into too much detail about how they are computed, as others have already covered that far better than I probably could. But to put it simply, they utilize the golden spiral (aka the Fibonacci spiral) to uniformly distribute points on a surface. This is similar to the way some plants distribute their leaves or seeds, by placing each point $2\pi \cdot (2-\phi)$ radians^[1] further along a spiral path from the center, where $\phi$ is the golden ratio. So for $N$ points in a 2D spherical coordinate system we would use something like:

(\theta, r)_i = (i \cdot 2\pi \cdot (2\phi), \frac{i}{N})

Now all that is left to use this on the surface of our sphere is to extend it from 2D spherical coordinates to 3D Cartesian coordinates. This can be done by cutting the sphere into circles along the Y-axis, by deriving the Y coordinate directly from the current index $i$ . Based on the radius of the sphere, we can then derive the radius of the current circle and calculate X and Z from the angle given by the equation above. So for the unit sphere with radius 1 and $N$ points we get:

\begin{align*} y_i &= 1 - \frac{2i}{N-1}\\ r_i &= \sqrt{1-y_i^2} \\ \theta_i &= i \cdot 2\pi \cdot (2-\phi) \\\\ (x,y,z)_i &= (cos(\theta_i) \cdot r_i, y_i, sin(\theta_i) \cdot r_i) \end{align*}

Combining all this, the code that generates our vertex positions looks like this:

// Define the data layer that contains the vertex positions in 3D Cartesian coordinates
constexpr auto position_info = Layer_info<Vec3, Layer_type::vertex>("position");

// Acquire all necessary resources from the world structure
auto mesh        = world.lock_mesh();
auto [positions] = world.lock_layer(position_info);
auto rand        = world.lock_random();

// Create N vertices
mesh->add_vertices(vertex_count);

// Pre-calculate the golden angle and the step-size for calculating y,
//   so we just need to multiply them with i in the loop
constexpr auto golden_angle = 2.f * std::numbers::pi_v<float> * (2.f - std::numbers::phi_v<float>);
const auto     step_size    = 2.f / (vertices - 1);

for(std::int32_t i = 0; i < vertices; i++) {
	// Calculate the x/y/z position of the current vertex on the unit sphere
	const auto y     = 1.f - step_size * i;
	const auto r     = std::sqrt(1 - y * y);
	const auto theta = golden_angle * i;
	const auto x     = std::cos(theta) * r;
	const auto z     = std::sin(theta) * r;

	// Set the vertex position (multiplying with the radius of our sphere)
	positions[Vertex(i)] = Vec3{x, y, z} * radius;
}

Until now, we only defined our vertices as a cloud of points without any connectivity. So, the next step is to compute the Delaunay triangulation of these points. There are again a couple of ways to achieve this, but the easiest is to utilize the fact that the Delaunay triangulation of points on the surface of a sphere is identical to the convex hull of said points. Thus, all that’s left to do is import a library that computes the convex hull. The library already gives us a list of faces, that we just need to pass onto the add_face() function of Mesh^[2]:

quickhull::QuickHull<float> qh;
auto  hull    = qh.getConvexHull(&positions.begin()->x, positions.size(), false, true);
auto& indices = hull.getIndexBuffer();

for(std::size_t i = 0; i < indices.size(); i += 3) {
	mesh->add_face(indices[i], indices[i+1], indices[i+2]);
}

As can be seen in the images below, the vertices are distributed evenly on the surface … perhaps too evenly. In some cases we might want a more natural and less uniform look. This can be achieved easily by adding a small random offset (0 <= offset < 1.0) to the loop variable i before it’s used in the calculations:

const auto offset = perturbation > 0 ? rand->uniform(0.f, perturbation) : 0.f;
auto       ii    = std::min(i + offset, vertices - 1.f);
// then use ii instead of i in the body of the loop

Wireframe of the generated mesh

Shaded rendering of the same sphere

Sphere with more vertices and a small random perturbation

Implementing add_face

As said above, implementing this operation is not as straightforward as one might hope. The main problem is that triangles could be added in (nearly) any order, and we need to update the connectivity information correctly for all possible cases. Which boils down to updating the origin_next(e) references for all modified primal and dual edges, to preserve valid edge-rings, as visualized below.

origin_next(e) for primal edges must always form an edge-ring that contains all primal edges with the same origin vertex, in counterclockwise order.

Similarly, origin_next(e) for dual edges must form an edge-ring counterclockwise around a face.

A special case for dual edges are boundaries of unclosed geometry. At boundaries, edges miss either their left or right face, which is normally not allowed by the data structure. To bypass this restriction, we treat the outside of our shape as a single imaginary face (the only face that doesn't have to be triangular) with the highest possible ID (all bits are 1). Of course, this face also has an edge-ring, consisting of the rot(e) of every boundary edge. While the order of the edges looks clockwise here, it's technically still counterclockwise, when seen from the perspective of the imaginary boundary face.

Forbidden case: The central vertex is already used by two faces, that are not connected by another face. When we want to add a new face that is not connected to one of the existing faces, we can't decide if it should be inserted at the top (A) or bottom (B).

Because our mesh implementation doesn’t know about the position of vertices, we need to enforce one additional restriction on valid topologies: If multiple unconnected faces share a vertex, a new face can only be added to that vertex, if it also shares at least one edge with one of the existing faces. The problem we solve with this restriction is, that we have to know the order of the faces around a vertex, to be able to insert the edges at the correct positions in their new edge-rings. This ambiguity could^[3] also be resolved by comparing the positions of the connected vertices. But this small restriction enables us to entirely ignore the vertex positions when working on the mesh and look at the topology only in terms of which vertices/faces are connected, without knowing how they will be laid out in space.

When we take all these restrictions into account and simplify the problem a bit, we only have to handle 8 different cases in total to add a new face to the mesh. One for each of the three quad-edges of the new face, that could either be missing or already exist. Luckily, most of these are rotationally symmetrical, and we only need to look at 4 distinct cases, that we can identify by counting the number of preexisting edges.

Case 0: No Preexisting Edges

The simplest case — and also the first one we need when we construct a new mesh — is the situation where we don’t have any faces or edges. All we need to do in this case is create one face and three quad-edges and connect them as shown below^[4]:

Primal: One edge-ring around each of the three vertices.

Dual: One edge-ring around the new face and one around the boundary edge.

Case 1: One Preexisting Edge (two new Edges)

The next case is a bit more complex: One of our edges already exists. What that means is that we add our face onto another face, with which we share a single edge.

The complexity here comes from the fact that we need to insert our new edges into existing edge-rings. To be exact, the complex part is finding the correct edge-ring and insert position, i.e. the edge that should be directly in front of us in the ring. In contrast, the insertion itself is relatively easy^[5]:

void insert_after(Edge predecessor, Edge new_edge) {
	// Find the edge that currently comes after the predecessor,
	auto& predecessor_next = primal_edge_next_[predecessor.index()];
	
	// ... set that as our next edge and
	primal_edge_next_[new_edge.index()] = predecessor_next;
	
	// ... change the predecessor, so that it points to us
	predecessor_next = new_edge;
}

A relatively common case is that we know our successor but not our predecessor. In this case, we can just use origin_prev(e) to get its predecessor and insert ourselves between them. Though, one thing we need to keep in mind, is that the traversal operations won’t work as expected if we already modified part of the topology. So, the usual procedure is that we calculate and remember all information about the current topology that we will need and only modify it afterwards, whereby we achieve a consistent view of the topology.

void insert_before(Edge successor, Edge new_edge) {
	insert_after(successor.origin_prev(*this), new_edge);
}

Primal: The right vertex is identical to the simple case, but the other two edges need to be inserted into the existing edge-ring by calling insert_before() with e1,e2 and e3,e4.

Dual: The edge-ring around the new face is identical to the simple case, but the boundary edge-ring is more complicated here. Before we inserted our new face, the shared edge was a boundary edge and e1 was part of the boundary edge-ring. After the insertion that is no longer the case and e2 and e3 should be part of this edge-ring instead. So, we have to retrieve the predecessor of e1, let it point to e2, which points to e3, which finally points to the original successor of e1.

Case 2: Two Preexisting Edges (one new Edge)

This case is quite similar to the previous one, but slightly simpler because we only have one newly created quad-edge that we need to connect. Thereby, the primal edge ring around one of the vertices is already correct, and we only need to update the other two to include the new edge. Wiring up the dual edges is the only part with a bit of complexity, but that case is also quite similar to case 1.

Primal: The edge-ring around the bottom right vertex is already complete and doesn't need to be modified. The only thing we need to do here is insert our new edges into the ring around the remaining two vertices. Which can be done in the same way as in the previous case.

Dual: Like in the last case, we have to remove the out-going edges of the new face from the boundary-ring and replace it with the new edge. The difference is that we now remove two edges (e1 and e2) and replace them with a single new edge (e3).

Case 3: Three Preexisting Edges

The opposite of Case 1 is also simple enough: All three vertices of our face are already connected by edges, and we currently have a hole where we want to create the face. Because all connections are already established in this case, we don’t have to connect any edge, but just create a new face and set the origin of the dual edges leaving the face accordingly^[6].

The Edge-Case^[7]

We owe the simplicity of the previous cases primarily to one assumption: If a vertex is already part of a face, we share an edge with at least one of its faces.

Special-Case: New face between two previously unconnected faces

But that assumption doesn’t hold in all cases. While our restriction from the beginning does forbid all cases where a vertex is shared by more than two unconnected faces, it leaves one case open that we still need to handle: A vertex that is shared by exactly two faces. We could’ve excluded that case too, of course. But in contrast to the others, this one is actually decidable based only on the topology. And by not allowing it we would unduly restrict the construction of meshes because without this case all new faces after the first one would have to share an edge with an existing face.

The reason that we’ve ignored this cases until now is that we can actually separate these concerns by splitting our function in two steps:

Add the face like above, ignoring this special case
Iterate over each affected vertex and fix the errors introduced by ignoring it

The specific errors that are introduced by this are unconnected edge-rings^[8], which would cause massive problems during traversal because we would only see one of them when we iterate with origin_next(e). Luckily, we can solve this problem relatively easily by merging the two edge-rings:

void merge_edge_ring(Edge last_edge_of_a, Edge last_edge_of_b) {
	auto& a_next = primal_edge_next_[last_edge_of_a.index()];
	auto& b_next = primal_edge_next_[last_edge_of_b.index()];
	
	std::swap(a_next, b_next);
	// Now last_edge_of_a points to the first edge in b
	//  and last_edge_of_b points to the first edge in a
}

Primal: Next-Pointers after first step in orange and changes in red. To merge the two rings, we need to find the last edge of the new (e1) and old edge-ring (e2). To do that here, we can just iterate over all edges of the respective ring, looking for the first edge that has no left face.

Dual: Next-Pointers after first step in cyan and changes in red. The two edges we need for the merge operation can be determined by iterating the edge-rings, looking for one where the connecting vertex is on the left side. Or we can find them by traversing the mesh after we've found the two edges for the primal merge-operation.

Conclusion

Now that we have our first world mesh, we can nearly start with the generation algorithms, like simulating plate tectonics. We’re just missing one final puzzle piece, we’ll look at next, that is the modification of our mesh during the simulation.

World Data Structure

Sun, 11 Apr 2021 00:00:00 +0000

Before we can get started with the actual generation/simulation algorithms we first need to decide how to store our data, i.e. how the world is represented in the data-model. Given that it’s not clear what algorithms, we will use later and what their requirements will be, we’ll want to choose an extendable model, that won’t restrict our options later.

There is however one decision we need to make right now, and that is what kind of shapes we want to support. As said in the previous post, I plan to focus on spherical worlds, seeing as the real world is (nearly) spherical^[1] and I want to be able to directly compare it with my results. Since we are — at least at the current scale — only interested in the information on the surface of our world, this means that we need an efficient way to store information for points on the surface of a sphere.

On a Sphere, triangles can have more than one right angle ^[source]

Working on the surface of a sphere brings with it a number of interesting problems^[2] because it’s not the kind of euclidean space we are used to from school, but an elliptic space. This doesn’t really affect us at human scale, but at the scale of continents we will need to take that into account when moving points on the surface and calculating distances and angles. Another problem with using a sphere for our world is that it limits our possible data structures because a sphere can’t be projected onto a flat surface without introducing distortions or other artifacts. So, simply projecting a bitmap texture onto the sphere is not really a practical course of action, if we want to avoid those problems.

But based on the other projects I’ve looked at and my requirements, a triangle mesh is the obvious choice, anyway. Structured Grids like bitmaps/2D-Arrays often suffer from artifacts, either from discretization problems or other limitations, that are less apparent on unstructured grids. A triangle mesh is also a promising data structure because it’s extremely flexible as far as the resolution is concerned, which will be required to support the relatively large detailed worlds I’m looking to generate.

So, the data structure of choice will be a triangle mesh of a Delauny triangulation (as well as its dual-graph, the voronoi diagram) with a variable resolution based on local detail requirements.

Mesh Data Structure: Quad-Edges

The next question is: How do we store this triangle mesh?

The simple option would be an array of faces, each containing the connected vertices. But to actually work with the mesh we’ll need an efficient way to traverse it, i.e. answer questions like “what other vertices/faces are connected to this vertex?”. Other common data structures for triangle meshes, that solve this problem, are directed edges, winged edges and half-edges.

But the data structure I’ve decided on are quad-edges, first described by Jorge Stolfi and Leonidas J. Guibas in 1985. Their main benefit is, that they model the primal triangle mesh, as well as its dual (voronoi diagram) at the same time. This means that we can traverse both and naturally switch between them if our algorithm requires it. Furthermore, quad-edges can answer many questions about the topology in constant time and often with just a simple bit-operation or by dereferencing a single pointer. And despite all, that their memory layout can be quite compact, which will be important for larger worlds.

The three main concepts are the same as for any mesh: vertices, faces and edges. Vertices are points on the surface and the element to which we will link most of our information like elevation. Two vertices can be connected by an edge, and three connected vertices form a single triangular face.

In addition to this primal mesh, we also want to work with its dual. Here vertices and faces switch places, that is each face in the primal mesh is a vertex in the dual mesh^[3], which are connected into voronoi cells with one of the primal vertices inside. As we can see in the image below, for each edge in the primal mesh (gray) the dual mesh contains an edge that connects the face on the left and on the right side of it. But the edges and vertices at the boundary are a bit of an edge case and form voronoi cells that are infinitely large. Luckily, that is a case we can ignore for now because our sphere is a closed mesh without any holes or boundaries.

The dual mesh is especially interesting for us because the voronoi cells define the area around each primal-vertex that is closer to it than any other vertex. Which is useful to calculate its sphere of influence or mass during plate simulation and will also prove useful for simulating drainage areas and rivers, later.

A Delaunay triangulation (grey) of the vertices (red) and its dual, consisting of the circumcenters of the faces (blue) and connecting edges (cyan), forming the voronoi cells.

Of these three concepts, the most important one for our quad-edge data structure is — as the name suggest — the edge. Our edges are directed, which means they know which vertex they are coming from, which one they are going to and which faces are on their left/right side. Thus, we need to store a total of four vertices for each pair of connected vertices, that form a quad-edge (see image below), to model the two possible directions of both the primal and dual mesh at that point.

Besides these pieces of information, we only need one other datum to describe the complete topology: Which edges start at a given vertex, i.e. the outgoing edges^[4]. And we store these as linked-lists of edges, where each edge knows the next edge around its origin, which is called an edge-ring.

This might look like a lot of information, but as we will see, most of it is redundant and doesn’t need to stored directly, but can instead be derived from the following and stored surprisingly compactly.

Each edge e knows its origin/destination vertex, as well as which face is on its left/right side.
Or origin/destination faces and left/right vertices for edges of the dual mesh.

Each edge also knows the other edges that are part of the same quad-edge, which we can access by rotating the edge counter clockwise.

Finally, each edge knows the next edge, when rotating counterclockwise around its vertex of origin, i.e. its edge-ring.

The information above describes the complete topology of our mesh, which we can access using the following basic operations:

origin(e): Gives us the origin of an edge (either a vertex in the primal or a face in the dual mesh).
dest(e): Gives us the destination of an edge.
left(e): Gives us the face/vertex on the left side of the edge.
right(e): Gives us the face/vertex on the right side of the edge.
rot(e): Gives us the next edge in a quad-edge. As each quad-edge consists of four edges, the result of the fourth rotation is our initial edge, again.
sym(e): Gives us the edge that points in the opposite direction. So it’s the same as rotating the edge twice.
origin_next(e): Gives us the next edge when rotating counterclockwise around the origin of an edge. Like rot(e) this will loop back on itself after we have visited every outgoing edge from the origin.

We can also combine these into more complex operations to traverse the mesh:

dest_next(e): Same as origin_next(e) but gives us the next edge around the destination instead.
left_next(e): Gives us the next edge rotating around the left face, i.e. left(e) will return the same value and the origin of the returned edge is our destination.
right_next(e): Same as left_next(e) but rotates around the right face.

As we’ve seen, all operations above always rotate counterclockwise. So, the final operations we will define are variants of the above, that rotate in the opposite direction:

inv_rot(e)
origin_prev(e)
left_prev(e)
right_prev(e)

origin_next(e) allows us to iterate over all edges around a vertex or face. As with all operations the direction is counterclockwise and origin_prev(e) can be used for clockwise iteration.

Similarly, dest_next(e) can be used to iterate over all edges with a given destination.

And finally left_next(e) can be used to iterate over all edges that are part of a given face.

There is one more operation defined by the paper, that we will ignore here: flip(e), which returns the edge as seen from the other side of the polygon, i.e. the origin and destination stay the same but the left and right face are swapped. This operation is useful because quad-edges can actually represent any manifold polygon^[5], including non-triangular meshes and even non-orientable surfaces^[6], and don’t have an inherent preference for a specific side of the polygon. But we don’t really need that sort of flexibility for our endeavor, which is describing the topology of the surface of a sphere (and maybe later other simple shapes) and would rather trade it for some simplicity further down the road. So, what we will do instead is drop this operation and only work on one side of the polygon, defined by a consistent counterclockwise winding order.

Implementation

Now that we have seen how quad-edges describe the topology and what operations we need, we can start with the interesting part: Implementing it and looking for potential optimizations.

First, let’s reiterate what we need to store:

For each vertex: one outgoing edge (an edge where origin(e) is our vertex)
For each face: one edge going counterclockwise around the face (an edge where left(e) is our face)
For each edge:
1. Its siblings, i.e. the three other edges that are part of the same quad-edge.
2. The next edge, iterating counterclockwise around its origin (origin_next(e)).
3. The origin/destination vertex and left/right face.

One thing we can drop immediately from that list is most of 3.3. Because each edge already knows the other edges of the quad-edge, we only really need to store the origin vertex/face of each edge. Everything else can be reconstructed from just these two, with:

destination(e) == origin(sym(e))
left(e) == origin(inv_rot(e))
right(e) == origin(rot(e))

We could do something similar for the references to an edges siblings:

sym(e) == rot(rot(e))
inv_rot(e) == rot(rot(rot(e)))

But, as we will see next, that doesn’t really buy us anything because we can get rid of 3.1 entirely.

If we were to translate that naively to C++ it could look something like this:

struct Vertex {
	Edge* outgoing_edge;           // 1.
};
struct Face {
	Edge* ccw_edge;                // 2.
};
struct Edge {
	std::array<Edge*, 4> siblings; // 3.1.
	Edge*                next;     // 3.2.
};

// We need two separate types for edges, because the 
//   type of the origin is different for primal and dual edges
struct Primal_edge : Edge {
	Vertex* origin;                // 3.3.
};
struct Dual_edge : Edge {
	Face* origin;                  // 3.3.
};

struct Mesh {
	// The actual data, that is referenced by the pointers above
	std::vector<Vertex>      vertices;
	std::vector<Face>        faces;
	std::vector<Primal_edge> primal_edges;
	std::vector<Dual_edge>   dual_edges;
};

As this just defines the topology, we still need a way to store our actual data, like vertex positions or elevations. We could just add those to the struct as additional member variables, but that would mean that we need to modify them each time we implement a new generation algorithm, which would make future expansion more difficult^[7]. Hence, instead we will give each vertex/face/edge a unique ID, that we can then later use as a key to reference our data.

To define these IDs, we will just use their index position inside the std::vector that contains them. For vertices and faces this will work flawlessly, but for edges we also need to differentiate between primal and dual edges. To solve this problem, we will resort to the age-old tradition of stealing every bit that isn’t nailed down. To be precise, we will use the most significant bit of our ID to decide if it references a primal or dual edge^[8].

If we visualize that structure, we see another interesting effect. Because each edge always belongs to a quad-edge, if we add a new edge to our mesh, we will always need to create 4 edges (2 primal + 2 dual). So if we store and reference our edges as described above, we can find the siblings of an edge just by modifying their index, without storing any additional data.

                       quad edge 1               quad edge 2
                           ︷                        ︷
              ╭────────────┬────────────┬────────────┬────────────┬────────────╮
primal_edges: │     e0     │     e1     │     e2     │     e3     │     ...    │
              ╰────────────┴────────────┴────────────┴────────────┴────────────╯
              ╭────────────┬────────────┬────────────┬────────────┬────────────╮
dual_edges:   │     e0     │     e1     │     e2     │     e3     │     ...    │
              ╰────────────┴────────────┴────────────┴────────────┴────────────╯

Edge-index bits:
       ╭──┬──┬──┬──┬───┬──┬──┬──┬──╮
Bit:   │31│30│29│28│...│ 3│ 2│ 1│ 0│
       ╞══╪══╪══╪══╪═══╪══╪══╪══╪══╡
Value: │ 1│ 0│ 1│ 1│...│ 1│ 0│ 0│ 1│
       ╰──┴──┴──┴──┴───┴──┴──┴──┴──╯
         ↑                        ↑ 
         0 = primal edge          0 = 1. edge of quad-edge
         1 = dual edge            1 = 3. edge of quad-edge (== sym(e) == rot(rot(e)))

The 31st bit is reserved to decide if the edge belongs to the primal mesh or its dual, and the rest is used as the index into the respective vector. But because we allocate the edges continuously, they always come in pairs inside each vector, and we can switch between them by just flipping the 0th bit of their index. What this means is that we can not only drop the siblings member but that we can actually calculate rot(e), sym(e) and inv_rot(e) using relatively simple bit-wise math instead of chasing pointers!

Since we are already stealing parts of our indices, we will reserve one more value from each as an identifier^[9] for invalid or unset edges, vertices and faces. These will be important later to define boundary edges or incomplete meshes during construction. But they also allow as to “delete” elements from the mesh. Because the index of an element is also used to reference it, we can’t just remove them from the vector, as that would move all later elements, changing their index. Instead, we’ll utilize the invalid IDs to leave “holes” in the vector, that we can skip during processing and fill in later with new vertices/faces/edges.

And that’s it, for the most part. As a last step, we’ll just sprinkle a bit of data-oriented design over our structure, by moving our data from the Vertex/Face/Edge struct directly into separate vectors in the Mesh. That doesn’t change much in our case, as our structs were already rather small and simple, but could be a wee bit faster for some cases^[10]. And it also frees up Face, Vertex and Edge as type names, that we can then use as type-safe ID-wrappers^[11]. We also dropped the separate types for primal and dual edges, to further simplify the structure. However, it might be interesting to provide separate types to already distinguish them in the type-system, instead of later at runtime. But that is an extension I might look at later.

struct Face {
	uint32_t id;
};
struct Vertex {
	uint32_t id;
};
struct Edge {
	uint32_t mask;
};

class Mesh {
  private:
	friend struct Edge;
	
	std::vector<Edge>   vertex_edges_;
	std::vector<Edge>   face_edges_;
	
	std::vector<Vertex> primal_edge_origin_;
	std::vector<Edge>   primal_edge_next_;
	std::vector<Face>   dual_edge_origin_;
	std::vector<Edge>   dual_edge_next_;
};

Operations

We’ve already seen that we can implement rot(), sym() and inv_rot() as bit-wise operations on the ID, so that is the first thing we will implement^[12]:

inline constexpr auto edge_type_bit = uint32_t(1) << 31u;

struct Edge {
	uint32_t mask;
	
	// The default constructor sets all bits to 1,
	//   which is our representation for an invalid edge
	Edge() : mask{~uint32_t(0)} {}
	
	// And we also have constructors that take a mask 
	//   or construct a new one from an index and a bool 
	//   (i.e. set the highest bit if it's a dual edge)
	Edge(uint32_t mask) : mask{mask} {}
	Edge(bool dual, uint32_t index)
	  : mask{dual ? (index | edge_type_bit) : index} {
	}
	
	// If we need the actual index, we have to unset the highest bit
	uint32_t index()const   { return mask & ~edge_type_bit; }
	// And to decide if an edge belongs to the dual or primal mesh
	//   we can just shift it, so its highest bit is the only one left
	bool     is_dual()const { return mask >> 31u; }
	
	// A simple operation, we haven't talked about, which gives
	//   us the first edge of a quad-edge by unsetting both the highest and lowest bit.
	Edge base()const    { return { mask & ~(edge_type_bit | 1u)}; }

	// As we have seen above, the two primal/dual edges that
	//   belong to the same quad edge are always at an odd/even
	//   index and right beside each other.
	// So we just need to xor the least significant 
	//   bit to switch between them
	Edge sym()const     { return { mask ^ 1u}; }
	
	// rot and inv_rot are a bit more complex, because we need to change both bits.
	// First we always need to xor the highest bit, as rot always 
	//   alternates between dual and primal edges.
	// And we also need to change the lowest bit, which we will do
	//   with the second xor (see graphic below)
	Edge rot()const     { return {(mask ^ edge_type_bit) ^  is_dual()}; }
	Edge inv_rot()const { return {(mask ^ edge_type_bit) ^ (is_dual() ^ 1u)}; }

To implement the rotate operation, we need to change both the most and least significant bit. The most significant bit alternates between 0 and 1 as we alternate between primal and dual edges. But the least significant bit only changes every two steps. To implement this, its change is dependent on the most significant bit, i.e. we only alternate it if we rotate from a dual to a primal edge.

The next steps are the origin(e)/dest(e)/… operations to get the surrounding vertices and faces of an edge. The functions to get the origin vertex/face are relatively simple, as we just need to check if the operation is valid for this type of edge (primal vs. dual) and access the corresponding vector in the Mesh struct. And for the destination and the left/right face, we just have to rotate the edge appropriately beforehand and then get the origin of the result.

	Vertex origin(const Mesh& mesh)const {
		assert(!is_dual());
		return mesh.primal_edge_origin_[mask];
	}
	Vertex dest(const Mesh& mesh)const {
		return sym().origin(mesh);
	}
	
	Face origin_face(const Mesh& mesh)const {
		assert(is_dual());
		return mesh.dual_edge_origin_[index()];
	}
	Face dest_face(const Mesh& mesh)const {
		return sym().origin_face(mesh);
	}
	
	Face left(const Mesh& mesh)const {
		return inv_rot().origin_face(mesh);
	}
	Face right(const Mesh& mesh)const {
		return rot().origin_face(mesh);
	}

Next are the functions to actually traverse the mesh. origin_next(e) is again quite simple — determine the correct vector based on the type of the edge and load the corresponding next pointer — but implementing all the others in-terms-of it is a bit more complex and perhaps needs a bit of visualization:

	Edge origin_next(const Mesh& mesh)const {
		return is_dual() ? mesh.dual_edge_next_[index()]
		                 : mesh.primal_edge_next_[index()];
	}
	Edge origin_prev(const Mesh& mesh)const {
		return rot().origin_next(mesh).rot();
	}
	Edge dest_next(const Mesh& mesh)const {
		return sym().origin_next(mesh).sym();
	}
	Edge dest_prev(const Mesh& mesh)const {
		return inv_rot().origin_next(mesh).inv_rot();
	}
	Edge left_next(const Mesh& mesh)const {
		return inv_rot().origin_next(mesh).rot();
	}
	Edge left_prev(const Mesh& mesh)const {
		return origin_next(mesh).sym();
	}
	Edge right_next(const Mesh& mesh)const {
		return rot().origin_next(mesh).inv_rot();
	}
	Edge right_prev(const Mesh& mesh)const {
		return sym().origin_next(mesh);
	}
};

One example for the methods above, that shows how origin_prev() can be implemented in terms of origin_next().

The key here is that we first rotate the edge, to get the dual edge that points from the right to the left face. Just like with primal edges, we can use origin_next() to get the next (counterclockwise) edge around the origin, but for dual edges that origin is a face instead of a vertex. So, when we rotate our dual edge, we get the dual edge that point “through” the next edge of the right face or in other words origin_prev() of our original mesh. And to get the primal edge, we are actually looking for, we then just need to rotate the dual edge again.

Higher Level Abstractions

Based on these relatively simple operations, we have seen so far, we can now construct higher level abstractions to navigate the topology. One operation we need relatively often is iterating over every neighbor of a given vertex^[13], which can be implemented as:

// Get any edge that points away from the vertex
auto edge = vertex.edge(mesh);
auto e    = edge;
do {
	// Get the destination vertex of the current edge
	auto v = e.dest(mesh);
	
	// Do something with v
	
	// Get the next (CCW) edge
	e = e.origin_next(mesh);
	
	// If the next edge is the one we started with,
	//   we have visited all edges and can stop
} while(e!=edge);

Precisely because this is a common operation, the actual API provides iterators and methods that simplify the above code to:

for(auto v : vertex.neighbors(mesh)) {
	// Do something with v
}

One part of the API we’ve ignored so far is how we construct a mesh to begin with. And for some algorithms, we will also need to be able to modify an existing mesh. The operations we will need for this are:

Create a new triangle face that connects three vertices
Flip the central edge of two adjacent faces, i.e. remove the shared edge and replace it with a new edge between the two previously unconnected vertices
Split an edge into two edges, inserting a new vertex and new faces between them
Collapse an edge, i.e. merge two vertices and remove the edges and faces between them

But because these operations are a bit more complicated and this post is already far longer than I originally planned, we will look at that in a future post.

Positions, Elevations and other Additional Information

However, there is one part we still have to talk about. Everything we have looked at so far is purely concerned with the topology — which vertices/faces are connected to each other — and isn’t concerned about how it’s actually laid out in space. That is, if it can be laid out without intersecting itself, it doesn’t matter if our basic shape is a sphere, cube, plane or tesseract^[14].

But even if our data structure isn’t concerned about the positions in space, we still do care about that for many applications and need a way to store them. We’ve already touched on the fact that we can use the IDs of our vertices/faces/edges to link them to additional information like elevation or temperature, and we will handle their positions in exactly the same way. Because our elements are laid out in a continuous vector in memory^[15] and our IDs are based on their position, we can also just use a vector for our addition data and use the IDs to index into them.

While that will work, there is a bit more complexity, to handle changes when we modify the mesh later. And a bit of validation and type-safety would also be a welcome addition. To achieve that, we will create a new Layer type that stores information linked to a given part of our mesh, that looks like this^[16]:

enum class Layer_type {
	vertex, face, edge_primal, edge_primal_directed, edge_dual, edge_dual_directed
};
	
template <typename T, Layer_type Element>
class Layer {
  public:
	// Access the data for a specific element
	// The parameter type is Vertex, Face or Edge depending on the Layer_type
	T&       operator[](type<Element>);
	const T& operator[](type<Element>)const;
	
	size_t size() const;
	bool   empty() const;
	
	// begin() and end() so the type can be used in range-for loops
	T*       begin();
	const T* begin()const;
	T*       end();
	const T* end()const;

  private:
	// ...
};

Because Layer is a class template, it can be used to store all kinds of different data types^[17] and can reference vertices, faces and all types of edges.

One thing that might be a bit surprising at first is the number of possible types of edges in Layer_type. In addition to the distinction between primal and dual edges, we also differentiate between directed and undirected edges here. While the edges in our mesh are always directed, much of the information we might want to store about them will be identical for both directions. For example, when we model plate tectonics and store the distance between neighboring vertices, we would choose edge_primal instead of edge_primal_directed and only require half the memory to store our data.

Not all data is directly related to parts of the mesh or might be so sparse that a continuous storage doesn’t make sense. For these cases, there will also be unstructured data layers, that model a simple key-value store, which I might talk about later.

World Class

As already noted, the Layers might need to be updated whenever the mesh is modified, which means both are heavily intertwined. Thus, it isn’t really feasible to construct them independently of each other. Hence, we will encapsulate both in a World type that manages both the Mesh and any created Layer:

class World {
  public:
	const Mesh& mesh() const;
	Mesh_lock   lock_mesh();

	const Dict*             layer(std::string_view id) const;
	Unstructured_layer_lock lock_layer(std::string_view id);

	template <typename LayerInfo>
	const typename LayerInfo::layer_t* layer(const LayerInfo& info) const;
	
	template <typename LayerInfo>
	Layer_lock<LayerInfo> lock_layer(const LayerInfo& info);

  private:
	// ...
};

In contrast to the types we have seen previously, the const and non-const getters are rather different here and also have different names. Because a complete World will be a pretty large and complex object with many layers, it is not feasible to copy it often. But creating copies of the current state of a World will be required later to implement an undo/redo functionality in the editor. To solve this, the World class implements copy-on-write semantics for the objects it contains. That means when a World is copied it still references the data of the original and only when one of them is modified the affected data — and only it — is actually copied. But to track these modifications, we need a bit of machinery, provided here by the ..._lock classes and lock_... methods. This recording of modifications will also allow us to check when the underlying data has been modified and for example cache the textures and vertex buffers used by the renderer.

Besides the mesh() getter, the class also contains two getters for layers, one for simple unstructured layers — that just have a name — and one for our more complex mesh-based layers.^[18] The latter is again a template, which hopefully is not that surprising because our Layer was also a template. But the parameter of the method probably warrants some further explanation. Every layer has a name with which it’s referenced in the procedural generation code, but it also has additional metadata linked to it:

The type of the data that it stores (T template parameter in Layer)
What its data is linked to in the mesh (Layer_type)
The initial value of its data (used both when it’s first created and when a new vertex is added to the mesh)
The range of valid values (only positive numbers, only numbers between 0 and 10, …)
Whether its data should be automatically validated against this range, to detect runtime errors
How the data should react to changes of the mesh (e.g. when an edge is split, should the value for the new vertex be interpolated between the original origin and destination, reset to the initial value, use the min/max of the values, …?)

Layers will usually be shared between multiple independent modules, that contain the actual procedural generation code. In fact, they are the main way of communication between them. Because it would be impractical to keep all of them synchronized, the system remembers all information about a layer at the time of creation. So, all later modules that want to access an existing layer only need to pass the first two points from the list above (which are validated against the stored information) and all others will be ignored.

Therefore, we also introduce a new type Layer_info to describe what a layer looks like and how it should behave, which can be constructed and then used to retrieve a concrete layer from the World:

constexpr auto position_layer = Layer_info<Vec3, Layer_type::vertex>("position");
constexpr auto distance_layer = Layer_info<float, Layer_type::edge_primal>("plate_distance")
                                .initial(-1.f);

auto [positions] = world.lock_layer(position_layer);

// Once we have the layer, we can access its data with the operator[] defined in the Layer class 
positions[Vertex(42)] = Vec3{10.f, -2.f, 3.f};

Conclusion

That is all for now, as I think this post is already a bit too long and complicated. We now just have to look at how meshes can be created and modified, before we can start with the really interesting parts.

Yggdrasill

Thu, 04 Mar 2021 00:00:00 +0000

As the end of my studies is nigh, I’m looking into possible topics for my master thesis. Alas, I’ve grown a bit tired of writing game engines and renderers lately — who’d have thought.

Luckily, this quest for new ~~shores~~ topics was solved quickly. I’ve also developed quite an interest in procedural generation and always had a bit of a fascination for fantasy worlds and maps. So, I’ve decided to work on procedural world generation.

This is obviously going to be a fun project with much potential for interesting failures.^[1] Therefore, I have the best intentions of documenting my plans, progress and interesting problems here. With best intentions I do of course mean “force myself” and with documenting I mean “dumb my thoughts here and try to make sense of it all here”.

Without further ado: Welcome to this unwise cocktail of a forever project and a master thesis.

There already are quite a lot of inspiring projects that procedurally generate worlds and maps with impressive results — some of which I will briefly mention here. I’ve also uncovered some scientific papers, that I might use as a basis for my project. Although, unfortunately, most of these are sadly closed source projects.

Dwarf Fortress is arguably the first thing that comes to mind, when people think about the procedural generation of game worlds. Sadly, definitive information about the generation algorithms is a bit sparse. What is known and documented is, that the generation starts with layers of noise-based fractal maps for terrain/precipitation/..., that form the initial map and are then refined by simulation steps. The main focus (and most impressive part) is, of course, the history generation and simulation of the actual game world. In contrast, the terrain generation is sadly relatively unimpressive.

Amit Patel's Mapgen4 (as well as its previous iterations) is also quite interesting, especially since it's quite thoroughly documented on his blog. The fundamental data-structure used by Magpen4 are relaxed voronoi diagrams and their dual (delaunay triangulations). This allows it to generate interesting maps without the obvious artifacts often seen with uniform grids. Elevation and generation parameters can be edited quite intuitively in Mapgen4 --- with procedural generation of rivers, precipitation, and biomes. However, the most interesting part for me personally is the rendering. It utilizes a traditional rendering pipeline with an oblique projection and more artistic lighting, to achieve a style that is quite close to a hand-drawn look.

Scott Turner's Dragons Abound procedurally generates and draws fantasy maps, with quite beautiful and adaptable results that are already often near-indistinguishable from hand drawn maps. Although the main focus seems to be on drawing the maps, which informed some of the design decisions, there are also some simulation-based approaches to determine climate-zones, precipitation and rivers. There are some technical similarities to Amit Patel's approach (insofar as both use delaunay triangulations as their fundamental data-structure). In contrast, Dragons Abound seems to use a much larger number of vertices, which allows it to support smaller features and produce more natural shapes.

Azgaar's Fantasy Map Generator is another fascinating project, as it not only provides a working web application to interactively generate detailed fantasy maps but is also open source. Additionally, there is even a blog with interesting details about the generator’s design and innerworkings, which --- sadly --- is currently inactive. Similar to the previous two, this generator uses a voronoi diagram, but the focus seems to lie much more on the generation. The most impressive part of this project is probably the insane amount of possible customization and editing options of the generated maps.

JonathanCR's Undiscovered Worlds is a procedural world generation project, inspired by Dragons Abound. But this project focuses more on generating large complete worlds, instead of drawing maps with relatively small/local scale, which is especially interesting as its close to my current plans.

Wonderdraft is a quite powerful and easy to use editor to manually create fantasy maps. It doesn't really provide much in terms of procedural generation, but might be an interesting reference as far as user editing of the generated data is concerned. There might also be an interesting potential in integrating a more powerful procedural generation toolkit with it, but --- in the absence of any API or documented file format --- that seems to be unrealistic for now.

Miguel Cepero's Voxel Farm is another interesting project --- and his blog is one of the reasons I originally became interested in 3D graphics and procedural generation. In contrast to most projects on this list, it generates not just a map of a world, but an actual interactive 3D world. This is obviously far outside of any reasonable scope for my project, but some of the more abstract ideas might still be interesting.

On the academic side of things, Cortial et al.'s 2019 paper Procedural Tectonic Planets proposes a model to procedurally generate planets using a simplified simulation of plate tectonics. Although the authors sadly didn't provide their source code or an executable to reproduce their results, the provided images and video look quite promising.

Another study worth mentioning here is Large Scale Terrain Generation from Tectonic Uplift and Fluvial Erosion by Cordonnier et al. from 2017. It uses tectonic uplift and hydraulic erosion data to generate plausible terrains. Although the scale is more local than my current plans, this might be an interesting approach to simulate erosion and river formation at a relatively high level, too.

Project Aims

The attentive reader might wonder: what exactly is it that I’m trying to achieve here?

The main focus of my project is pretty similar to that of Undiscovered Worlds. I’m interested in generating plausible worlds, that can be explored, used and processed further by others. Of course, I’ll also have to visualize my results in the form of maps and provide some form of user input, but that probably won’t be anything to fancy.

Apart from that, I have three main aims for this project guiding my design decisions.

Simulation Instead of Noise

As I’m mostly interested in the world generation aspect, I want to try to reduce the amount of random input and noise to a minimum and rely on simulations instead. A model based on a large amount of complexly layered noise might generate interesting worlds, but that is entirely thanks to how that noise is modulated instead of any real meaningful capabilities of the system. And as an effect of this, the generational space of such models is inherently limited to the small subset for which the parameters have been hand-tuned. As John von Neumann famously said:

With four parameters I can fit an elephant, and with five I can make him wiggle his trunk.

My goal is to create a more generalized system that can generate a wide variety of interesting worlds.

“Interesting” of course is subjective and means many different things to different people. Personally, I think one intriguing way to try to measure “interesting” in this context is in terms of the entropy of the generated world, i.e. its information density, uncertainty or “surprisingness”^[2]. On one end of the spectrum, with an entropy near zero, we have an entirely flat featureless plane. Even if beige is your favorite color and your favorite ice cream flavor is “cold”, we can probably agree that this world wouldn’t be terribly “interesting”. On the other end, with a large entropy, we end up with a comprehensively incomprehensible world — where everything appears to be random noise because nothing is correlated.

Noise-based terrain (while often beautiful) would probably lie mostly on the low-entropy-end — think rolling hills, uniform mountains and general predictability — while our real world would be more on the high-end. The sweat spot I’m aiming for lies somewhere between these two — less predictable than Perlin noise, but also not as opaque and complex as the real world.

In other words, what I want to achieve here is a comprehensible amount of meaningful information in the generated worlds. Meaning every visible feature should have a cause that can be discovered by the user, e.g. matching coasts where continents split apart, canyons where rivers used to flow, settlements where they actually make sense with names based on their surroundings and history. Aside from the general technical difficulty, striking the right balance will also be a problem here: An unbroken chain of cause and effect is utterly meaningless if it’s too complex to be easily comprehensible. The generated world becomes no more interesting than one based purely on random noise.

Realistic Scale

My second central aim for this project is the scale at which I want to generate worlds. To support physically meaningful parameters and allow for an easier comparison with the real world, I’m planning to generate spherical worlds on roughly the same scale as the earth, i.e. a radius of about 6’000 km.

To support such a large scale with any amount of local details, I’m going to use a triangle mesh to store the elevation and other information. This should allow for a wide variety of resolutions based on local requirements (i.e., fewer vertices in the ocean and more near coasts and mountains). This should also solve most of the problems and artifacts, usually encountered when one tries to use uniform rectangular grids like bitmaps on a spherical surface.

I’m currently planning to develop my generator in a top-down fashion: starting with the largest terrain features (like tectonic plates and mountains) and moving on to smaller scale details like rivers, caves and settlements from there. Although the dynamic resolution of a triangle mesh should lend itself well to such a generation approach, I might come to a point in the future where I need to split the system into multiple generators for different scales (e.g., erosion at the scale of a continent or mountain range vs. the scale of a local river). However, that should also mesh quite well with the triangle mesh approach, as the small-scale-generator could use the vertices from the high-level generator, refine them further and generate new information matching the constraints determined by the existing vertices. There will also be many interesting problems there, like the usual problem with discontinuities at the border between cells, of course. But that is far enough in the future that I probably shouldn’t concern myself with it, just now. That is clearly future-me’s problem, who is much more experienced than me, anyway.

Reusability

My final aim for this project stems from an inkling that I might have bitten off more than I can chew here. Because of that, I want to build the project in a fashion that even in its incomplete state, parts of it should still be useful or at least interesting to others. To achieve this, I’ve not just open sourced (most) of the project but also plan to structure it as modular as possible.

I already laid the foundation for this with a basic C-API for the world-model and generation passes. While I’ll initially just work on a C++API-Wrapper to use in my code, the C-API core should also allow for future interoperability with other languages like Python or C#.

Based on this I plan to develop a simple graphical editor as a debugging tool and construct all the actual procedural generation passes as self-contained reusable modules, that can be loaded as plugins (.dll/.so) at runtime. So, others should (at least in theory) be able to modify (or salvage) any interesting parts, extend the system with new functionality or use it as a starting point for their own projects.

Outlook

With the goal in mind and the course set: what’s next?

While I would really like to dive directly into exploring ideas for procgen algorithms and interesting simulation approaches, I think I should document and discuss some of the groundwork, first. To do so, the next couple of posts will mostly focus on how the world is modeled, stored, and modified in the code^[3].

Having that down, there are some (hopefully a bit lighter) topics, I would like to explore:

Simulating plate tectonics to generate realistic high-level features (probably based on Procedural Tectonic Planets by Cortial et al.)
Extending and refining the current API
Creating a renderer to display the generated information in a compact way that is easy to decipher
Creating easy to use tools to modify the generated worlds, both for debugging and artistic inputs
Simulating large scale weather patterns to determine precipitation, average temperatures, and biomes
Model drainage basins and high-level water flow to generate river systems
Generate detail-maps for smaller areas, based on the high-level features from the coarser large-scale map
Simulate coarse erosion based on this (maybe similar to Large Scale Terrain Generation from Tectonic Uplift and Fluvial Erosion by Cordonnier et al.)
Simulate large scale changes in world climate (i.e., ice ages and glaciation) to reproduce some of the more interesting terrain features we have on earth: fjords, sunken landmasses, interesting features on continental shelves, …
…

SecondSystem

Plate Tectonics 3

Plate Motion

Step 2: Identify boundary-types

Step 4: Calculate all forces acting on the sub-plates

Boundary_type::joined

Boundary_type::ridge

Boundary_type::subducting_origin

Boundary_type::transform and Boundary_type::collision

Step 5: Simulate movement

Elevation

6. Update elevation

Boundary_type::collision

Boundary_type::subducting_*

9. Simulate Erosion

Conclusion

Plate Tectonics 2

Creating the mesh

Generating the first tectonic plates

Initialize seed vertices

Flood Fill

Plate Tectonics 1

Enough plate tectonics to be dangerous interesting

Plate-Interactions and the Wilson Cycle

Discretization of Space

Reduced Dimensionality

Simulation

Conclusion

Modifying Meshes

Edge Flip

Primal Mesh

Dual Mesh

Edge Split and Collapse

Preconditions for split()

Preconditions for collapse()

1. The Link Condition

2. Vertices Shared by Unconnected Faces

Handling Deletions

Handling Topological Changes in Data Layers

Deletion and Modification

Creation and Merging

Summary

World mesh creation

Creating a Sphere

Implementing add_face

Case 0: No Preexisting Edges

Case 1: One Preexisting Edge (two new Edges)

Case 2: Two Preexisting Edges (one new Edge)

Case 3: Three Preexisting Edges

The Edge-Case[7]

Conclusion

World Data Structure

Mesh Data Structure: Quad-Edges

Implementation

Operations

Higher Level Abstractions

Positions, Elevations and other Additional Information

World Class

Conclusion

Yggdrasill

Related Work

Project Aims

Simulation Instead of Noise

Realistic Scale

Reusability

Outlook

Preconditions for `split()`

Preconditions for `collapse()`

The Edge-Case^[7]