Geology Simulator -- Minerology and Petrology Systems

Part 1 of this series here!

Links to all posts organized by topic here!

In this post, I outline how the world will keep track of rocks, minerals and their properties, and why. I had to take a detour from plate tectonics to at least think about this issue, in order to make certain early database decisions.  And by "think" I mean "read several textbooks" (well no not yet, but I'm most of the way through one!):

Unlike a game like Minecraft, I don't want to store my material information in terms of only distinct categories with a small set of ID numbers. Whenever possible, I want to store CONTINUOUS information about things like chemical makeup, so that rocks for the most part vary smoothly and gradually across the world. ...Unless there's some reason for them not to, like in the case of a sudden magma tube or a fault line.

If I DID keep track of a fixed number of categorical rock types and then looked up their chemistry, it would lead to sudden, jarring jumps in rock types out of nowhere. These sudden jumps would then get worse over time as plates moved around and erosion occurred. It would also cause chemicals to pop in and out of existence, because if you change from potassium rich categories to potassium poor, the potassium just goes poof, which violates conservation of matter. If instead I keep track of element and mineral concentrations and then look up what type of rock it is if and when I need to name it, these problems don't happen.

These are all granite! 

Yet as you might imagine, they have very different properties,
ores, etc. One named category covers a lot of continuous ground
that I don't want to miss out on!

There are a couple major problems with this continuous approach, though. One, it adds up to a lot more memory space than a cheap little ID number (Minecraft style). I've run some test simulations that simply populate the world with goxels that have all the information, and it was already pushing 1.5 gigabytes or so with just a medium size world, just sitting there (I'm trying to stay within 2 gigs for 32 bit users).

The other problem is even more pressing: I don't know how to guess a material's hardness, for example, from scratch (unlike chemistry, see later in this post). Hardness is an example of a number that depends on complex things like crystal structure and bond strengths that I couldn't possibly keep track of reasonably.

To kill both birds with one stone, I will put things like hardness in pre-supplied text files for index rocks (that I look up in books), then on program startup, interpolate between those reference points for rocks in between and store this in lookup tables. Later I can go grab the interpolated numbers during simulation whenever I need them. So we have two types of data: the goxel and the lookup table type:

DATA DIVISION 

Data Type 1, Information we can carry around in each goxel

• Whether it is a rock at all -- goxels can be rocks, or other kinds of things like liquids, gases, biological data holders, sediments, and so on. Those things reinterpret the data below as they need, instead of wastefully keeping additional space in memory that would usually be empty.
• Rock class -- igneous extrusive and intrusive, sedimentary, metamorphic.
• Rock subclass -- clastic, chemical, and biological sedimentary rocks, and metamorphic rocks that keep track of their different original rock sources.
• Chemical makeup -- relative proportions of ~20 geologically relevant elements in the goxel.
• Texture -- i.e. whether the rock is made up of finer or coarser grains (several levels)
• Highest temperature reached in the past (for metamorphic rocks)
• Highest pressure reached in the past (for metamorphic rocks)
• Current temperature
• Current pressure
• How much rock there is left, out of one full goxel -- keeps track of erosion having removed material.
• How cracked and broken down the rock is -- this accelerates weathering, and acts as a path for aquifers and mineral veins and magma, etc. Also, if it reaches the maximum value (gravel sized bits), the goxel becomes a sediment goxel.
• The identities and proportions of the few most prevalent rock-building minerals (special subset of minerals) that we have determined are currently in a solid goxel.

by Marie-Lan Nguyen

Data Type 2, Information we look up from centralized reference sources only as needed

• Name of the NEAREST rock category for human flavor (not geologically important)
• Melting point
• Chemical resistance -- to weathering
• Hardness -- grinding resistance
• Mechanical resistance other than hardness -- bending, pulling, etc.
• Thermal expansion coefficient -- influences cracking in temperature cycles.
• Porosity -- High porosity creates vulnerability to frost and salt wedging even in solid rock.
• Density -- affects how heavy a goxel is for floating on the mantle.
• Specific heat -- affects thermodynamic calculations, of course.
• Individual properties of constituent minerals.

Most of the things in Type 1 are used often, can't be categorized validly, and can plausibly be condensed down into compact shorthand formats. Temperature, for example: we don't need to know the temperature of everything down to a degree. So for example I can actually store temperature more like just "steps of 100 degrees C at a time, covering only ranges relevant to rocks melting."

On the other hand, the things in Type 2 are there because they are used rarely and/or they change nonlinearly or in complex ways. But what do we do if we need to know a goxel's melting point right now? We use lookup tables to figure it out on the fly!

ROCK IDENTIFICATION AND INTERPOLATION 

The basic idea here is to choose the few critical variables for classifying rock types from amongst the stuff carried around by goxels, then make big tables of all the different possible combinations of those variables that hold the other data we want, just like we want it, ready to quickly read off.

Actual, known rocks are read from user text files (there will be defaults) placed at their respective reference positions in the tables. Then the remaining spots are all interpolated between their reference neighbors. So a spot 1/3 of the way from granite to diorite will store values averaged between those on file for granite and diorite, biased toward granite.

This is all calculated once at startup, using user-customizable entries in a text file for the reference rocks. This means that if you want to add your own rocks, you just say where, and the algorithm will automatically blend those properties into the local neighborhood when you start the program up. Then your new rock type will appear exactly where you would expect it to in your world at the very end, procedurally.

We can't just have one big dumb lookup table for everything, because it would take up like 20 gigabytes or something. But that's okay, because many dimensions are mutually exclusive anyway. Rocks formed in different environments can be delegated to their own smaller tables. Basically we end up with a flowchart of smaller tables that add up to only small peanuts of storage:

Some example reference rocks are listed by number on the chart above. You do need one rock type at least for each box, but after that, it's up to you how densely to fill in the space. For example, let's consider three versions of just the Igneous lookup table, with different reference rocks:

If you only have granite in that category in the custom text files, the game will treat all igneous rocks as identical to granite and call them all granite at the end. If you have granite and basalt, it will name some rocks one and some the other, with the dotted line showing the naming cutoff. The smooth color transition represents in-between rock material properties averaged across the space for in-between goxels. Adding in andesite makes the space more complex, and so on.

By having these tables precalculated, looking up information is very quick. Find your table, then look up your exact coordinates and just read the data off. There is no need for calculating distances or averaging any values during the actual simulation. The time saved this way should make up for the time calculating the tables many many times over, and goxels don't have to store as much info, either.

...So that's how we look up whole rocks, but I also mentioned minerals. What are those, exactly, and why do they also matter?

MINEROLOGY -- VERY BASICS

Rocks are usually just mixtures of a finite set of minerals. Minerals are consistent substances with specific chemical formulae that will tend to form crystals or other reliable formations. Granite has no chemical formula. If you look at a chunk of granite, you can clearly see different distinctly colored regions. Each of these is a coarse grained crystal of one of a variety of pure (or at least homogenous) minerals:

by Friman CC-BY-SA-3.0

In the case of this piece of granite, the pinkish crystals are probably some sort of feldspar, the white ones are quartz, and the black ones are either amphibole or biotite minerals. If you look much more closely, the crystals become quite striking in how distinct they are (not the same sample):

by Thomas Bresson CC-BY-SA-3.0

Why are these minerals so separated? Because granite is a rock formed by very slow cooling of magma trapped beneath the surface. As the magma passes gradually through different temperature ranges, specific minerals have a lot of time to crystallize out of solution all by themselves, because hotter crystallizing minerals already left solution and cooler ones aren't in range yet. And its different minerals don't blend very well, because they have different crystal structures. So all the crystals of each type end up relatively large and distinct.

By contrast, a rock that cools very quickly does not have visibly sized crystals, or has very small ones. This rhyolite rock below is probably almost chemically identical to the pink granite shown above, but cooled much more quickly (at the surface, in an eruption):

by Michael C. Rygel CC-BY-SA-3.0

Do I really care whether rock looks coarse or fine? Well no, I don't care how they LOOK, because I'm not modeling visual textures. But I do care VERY much about crystallization and minerals in general, for a few reasons. All of the reasons revolve around the same theme of minerals influencing how chemical elements move around in non-homogenous ways:

1. Different minerals are more or less stable against erosion and weathering. Generally, heavier minerals that form deeper down (like olivine) tend to be less stable at the surface than lighter minerals that form closer to the surface (like quartz). So olivine will weather away into small clays quickly, and quartz will weather more slowly into larger grains of sand. These then get separated out by wave actions, for example, and form their own entirely different types of sediments (shales and sandstones) in physically distant locations. Entire landscapes depend on different minerals eroding away at different rates!
2. If crystals are already tinier than sand, then they won't probably erode into sand, for example. This compounds with #1 above.
3. Crystallization of minerals from magma (and melting into magma in reverse) can have profound consequences for distribution of chemistry in the planet. Crystals can sink in their magma as they form, as just one example, which can concentrate heavy minerals lower down and concentrate lighter ones on top. This is no less important than the main driving force behind continents forming and persisting over eons!
4. Metamorphic rocks are partially a result of the shape and texture of rocks changing with temperature and pressure, but also partially a result of constituent minerals destabilizing and re-crystallizing in new forms with depth and heat. The minerals, not just a bag of loose elements, matter.

The erosion parts (#1-2) are pretty simple. Erosion just simply pays attention to minerals and then moves sediments in a biased fashion based on their properties, no big deal. The metamorphic issue (#4) I am going to ignore for now, because metamorphism isn't as important early on in my project. The crystallization (#3 above) is a lot more complicated and also important sooner, for igneous rocks:

IGNEOUS CRYSTALLIZATION

Crystallization can happen in a lot of different ways, and depending on which way it happens, it can make a huge difference for geology. There's three main variables as far as I understand it so far: 

1. How many substances are present
2. Hwo well they form a solid solution. This means a solid that can substitute ions out of its structure somewhat freely. Alloys of metals are solid solutions, but mineral crystals can be too. Usually this happens when two minerals have similar crystal structures except for a substitution of one element... often in the same element series, such as calcium <--> magnesium. The different ions can diffuse in and out and essentially "dissolve" two types of crystals together. If a solid solution doesn't form, you'll get different distinct crystals next to each other instead.
   
   Solid solutions are on a continuum, based on how WELL ions diffuse in a given situation. From perfectly, to not at all. Also, what matters is ACTUAL diffusion. Rate of cooling or density of crystals can get in the way even if a solid solution / diffusion would have occurred eventually otherwise. So "low diffusion" can mean "chemically won't ever diffuse" or it can mean "would if it could but cooled too quickly" or it can mean "Crystals sank and aren't physically there anymore to diffuse into even if they would have qualified."
3. Whether each crystal is heavier or lighter or the same density as the remaining liquid after crystallizing.

These can combine in different ways to yield very different outcomes. Below is a very simple (I know it doesn't look like it!) phase diagram and some outcomes from it in different situations:

Okay, so the graph is a diagram of how two substances will crystallize (or melt in the other direction) based on temperature in different mixtures. On extreme left or right, you have pure substance A or B, and melting or freezing happens at a single point: the melting points. In the middle, you have a slurry phase, where the substances are crystallizing together not all at once.

Given example initial composition M, as the temperature lowers: T(ime)0 will be pure liquid. T1 is when the first crystals begin to form, where it intersects the "liquidus line." At T2, we are in slurry form. At T3 OR T4 (depending if A and B can form solid solution together), everything has crystallized.

The circles lower in the diagram outline different chemical situations:

The top situation 

...has good ion diffusion and equal densities of everything, and the solid is a solid solution. Crystals are distinct temporarily, but eventually, ions diffuse evenly through the substance and the final solid is homogenous again, just like the liquid. (Sapphires are another example of this -- iron "dissolved" in a solid solution of corundum)

The middle situation 

...shows low solid diffusion and crystals that sink, but the materials can still form a solid solution at freezing time. As you can see, you end up with a "sunset" chemical gradient from the top to the bottom of the lava chamber. This is largely responsible for continents existing: the lighter weight crystals are less dense and concentrate on top, and thus top rocks float better on the mantle than the rock they came from.

The bottom situation 

...shows non-solid-solution (immiscible) crystal forms that do not sink or float very well, and it forms a patchwork of different solid crystals that looks like, say, granite.

The phase diagrams can get more complicated. In the following diagram, there is a solid mixture that is only a solid solution on the sides, and converts to distinct crystals in the middle., depending on concentrations of each substance and temperature. You also end up with two different sets of slurry curves, and a center "eutectic point" where both crystals form at once:

You can also have situations with more than two substances present, in which case the curves become planes instead, and you have more of a triangular prism (in the case of three substances here):

Start at some triple composition of A, B, and C near the top. Cool down gradually, following

a path as if a ball were rolling down the hills. When on one planar surface, only

crystallize that substance. When on a middling ridge, crystallize two. 

At the bottom point (Eabc), crystallize all 3 until solid.

Add in a whole bunch more materials, pressure as a variable, and the need to use shortcut formats since you can't draw an 8-dimensional space, and it gets almost incomprehensibly complicated and difficult to interpret by eye:

SIMULATING CRYSTALLIZATION

The good news is that I don't think all this is actually that hard to code, at the end of the day! 

First of all, I can simply restrict the crystallization calculations to be limited to 3 substances, so a triangular prism is the most complicated we can get. The goxels keep track of their 3 most prevalent minerals to aid in this. This is good enough for tons of realism.

Second, there are a limited number of common situations that occur. I showed you a simple binary phase diagram, and a "eutectic" diagram (the two-lobed one), for example. There are only 8 or so normal types of diagrams like these, all similar to one another. I could code explicit instructions for each, without having to have a program interpret diagrams procedurally. I'll actually probably start out with just the 2 or 3 most common situations, and even that might be good enough.

Third, the program doesn't have to consider full 2-D or 3-D diagrams. It only needs to know the equations for the curves or planes, because that's where things actually matter. Thus, all this data takes up very little space and it is actually pretty quick and easy to work with.  The rules are also the same for 1,2, or 3 dimensions, just pasting in a Y or Z variable as needed basically (sort of like a Euclidean distance equation).

Fourth, I don't need to have actual correct data for curves!! I will want to know which minerals actually form solid solutions and so on, but getting the actual curves exact is totally unnecessary. I can just encode the true melting points of different substances, and then have the program guesstimate a reasonable "almond shape" for the slurry phases, and nobody will be able to tell. I'm confident the geology will look fine at the end, at least that's how I'm going to write draft 1.

Fifth, I don't even need curves at all. I can estimate a curve as even just 2 or 3 flat lines or flat planes, and it will probably be good enough, and much faster to calculate and code up. So instead of almond zones, we will have polygons.

AND this diagram is only for your benefit.

The program just sees it as a list of simple information, such as:

0% B, slope = 0.7, liquidus

30% B, slope = 0.6, liquidus

70% B, slope = 0.1, liquidus

0% B, slope = 0.2, solidus

30% B, slope = 0.65, solidus

70% B, slope = 1.3, solidus

Melting point A = 21

Ion diffusion = 45%

Density A = 16 solid, 14 liquid

Density B = 20 solid, 15 liquid

Any elements / chemicals that get left out of the crystallization calculations? They are treated much more simply. For example, heavier ones might tend to sink a bit between goxels and lighter ones float up, but otherwise, whenever the crystallization is done, leftovers just get locked in, in an abstract sense, in that goxel. Rare ores and gems can wait to be calculated until the end of simulation.

NEXT

Anyway, that was a LOT of information! And still no demo code! This stuff is going more slowly than I hoped, and I keep running into side issues, but the tectonics and the functional demo march ever closer even in the meantime.

In my next post, I promise I'll have a down and dirty demo of simple tectonics in action!
(Update: Promise completely broken, but I do still plan to get back to this.)

Geology Simulator -- Plate Tectonics Algorithm

(Part 1 of the series here!)

It's time to talk about everybody's two favorite cocktail party conversation topics: plate tectonics and mantle convection currents. I'll also get to our first specific geology algorithm that simulates the planet's dynamic core and source of plate movement, as well as some basic methods of plate formation in the model.

Coding-wise, I've been busy in the meantime with some underlying framework: file input, graphics output, setting up utility functions, classes to store data on plates and columns, considering whether multithreading makes sense or not, etc. I won't bore you with those details right now, though. I'll get straight to the first interesting bits. We need to answer some basic questions about the simulation world:

1. Why do the tectonic plates in our world move?
2. What happens at the boundaries of plates?
3. How do we start building our earliest continents?

The most logical place to begin is by looking for the answers to these same question when it comes to our very own, real-life Earth.

CRASH COURSE ON TERRESTRIAL PLATE TECTONICS

WHAT MOVES THE CRUST?

The Earth is divided into several layers. The inner core is solid, as is the very outermost few miles of rock (crust). The rest ranges from sort-of-maybe-kind-of solid (very outer mantle/asthenosphere) to pretty much flat out liquid (middle portions), and so the outermost parts, to varying degrees, "float" around on top.

Why does it move around, though, instead of just floating perfectly still?  Well, primarily because of convection: the natural cycling pattern formed by fluids of different densities -- most commonly because of uneven heating. Take a look at this cartoon beaker of water on a stove top:

The hot fluid expands and become less dense, so it floats upward on top of the colder liquid above. The cold, dense fluid sinks to fill in its place nearby. The cold fluid then heats up closer to the source of heat, and the hot fluid cools off at the surface, so they begin cycling in orderly patterns. Depending on the shape of container, the rates of cooling and heating, etc., the cycles can take many shapes, from 3-D donuts to columns to rolling cylinders. A single modular pattern, whatever the shape, is called a "convection cell."

The Earth is heated from below, too. And I do mean actively HEATED: most of the Earth's internal temperature is from ongoing radioactivity converting nuclear bond energy to new thermal energy. It is also cooled on top as heat is lost to space. Since it is also partially liquid, it has convection currents.

Now imagine a skin on the surface of the beaker above: the currents from the convection would pull it apart and push it off toward the side walls. Sort of like these chia seed continents in my kitchen:

The plates on Earth move much like that, except there are no sides of the beaker or pot in a round world, so things are less static. I.e., instead of hitting the wall and staying, plates wrap around the planet and tend to keep bumping around and re-jostling into new positions continuously.

PLATE BOUNDARIES AND MANTLE / CRUST ALIGNMENT

It is often assumed that convection cells in the Earth's mantle line up with the joints between tectonic plates. Where plumes of heat are rising up in the convection cells, one theory suggests that that's where (and why) the new crust is forming, swelling, and sliding "downhill" away from the heat, usually in the sea floor. This is called a ridge or rift zone:

(by Wikid77)

Notice those light blue / yellow lines in the middles of the oceans? Those at the mid-ocean ridges and their elevation swells, where most new crust is formed. This might reasonably line up with the rising heat side of a convection cell.

On the other hand, where plates meet, usually one will "subduct" under the other one. Some of the higher-silica-content material will bubble back up through volcanoes, but a lot of the material will sink and remelt into the mantle. In the Earth map above, you can (just barely) see dark blue lines where subducting plates plunge under deep ocean trenches. Japan is an example where two ocean plates meet, one subducts, and volcanic islands and a trench are formed. Cartoon version:

This subducting rock cools the area of mantle it pushes into, and thus might line up with the other, sinking end of a convection cell. The convection would occur anyway just from losing heat to the crust by direct conduction, but the crust itself recycling from rift to subduction zones might nudge the system into lining up in the same way. So you could get an overall picture something like this:

Things wouldn't be anywhere near that neat and tidy in reality, but it may be a rough approximation. In the following picture and video, you can see two interpretations of what a more realistic mantle convection pattern might look like. One is a bit more... tame than the other. But in both cases, you can see reasonable convection cells where heat travels up and down again in a recognizable pattern. You can also imagine how crust might move on top of the video model.

(by Harroschmeling, CC-By-SA-3.0)

(by turbulenceteamm)

OCEANIC AND CONTINENTAL PLATES

Shifting gears a bit, it's also worth explaining an important distinction between two major types of crust that affect movement patterns: oceanic and continental. Both can exist together on the same plate. Oceanic crust is made out of denser, silica-poor rock (mainly basalt) and is thin. Continental crust is made out of relatively less dense, silica-rich rock (like granite), and is much thicker.

The continents float better, so when a continent and an ocean collide at a boundary, the ocean inevitably subducts under the continent. And when continents collide, sometimes one subducts, but sometimes they just crumple together like a car wreck. Since continents rarely subduct, they tend to stick around, and have been getting bigger over the ages as more of the silicon and lighter elements have settled out toward the surface over time and stayed. Whereas ocean crust comes and goes.

In my program, ocean and continental crust will both be important, but I'm not going to directly code them by fiat -- I hope to instead have these distinctions arise naturally from modeling actual thickness, density, and bouyancy of rock columns.

HOTSPOTS AND SUPERCONTINENT ISSUES

There are a couple problems with the above story so far:

1. There are places on Earth called hotspots (about 40 "official" ones) where volcanoes or hot thin sections of crust seem to stay in one place for a very long time, ignoring plate movements. Like Hawaii. It doesn't really make sense that hot fluid can travel up in a stationary line AND flow around in circles in the same space at the same time. Something doesn't add up, and there's disagreement among geologists about what that is. Best case scenario, though, this would be a whole extra layer of programming for me on top of the above model. Worst case, it means I have no idea what to program at all.
   
   
2. What happens when a continent gets too large? Remember, continents rarely subduct, so inevitably, they all pile up in a supercontinent. This would be very boring if they don't break up again. They do split, but geologists seem to disagree about what causes the breakup of supercontinents. Everyone agrees it has something to do with heat building up under the insulation, but the details for how this would work in the above model are a bit fuzzy.

Maybe I could soldier on anyway, maybe ignore hotspots entirely (and in fact I tried!). However, I think I may be able to leverage both issues to my advantage instead with a simpler overall system...

What if we theorize that the mantle convection cells essentially "don't care" about the crust? The crust moves and changes (in this theory) more slowly than mantle convection cells. They're rapidly churning away down below, and the crust and it's tiny features are just minor side effects.

• This allows for hotspots... of course they ignore plates, because ALL mantle convection does.
• This lets me use one of the simpler supercontinent theories -- which is that hotspots cause more damage under supercontinents as they move more slowly, and have time to burn through the thick continental crust. Eventually "unzipping" the supercontinents along the weakened connected dots.
• Ridges and subduction zones don't have to line up with convection cells all the time, which removes several awkward implications and restrictions from the basic model. Getting this to all agree was like herding cats or trying to organize bags full of magnets. Whereas plates sliding around semi-freely on top with minimal feedback is much simpler.
• This should still allow convincing, normal geology at the end product.

CONVECTION + TECTONICS ALGORITHM

Alright, so let's get down to brass tacks and implement this concept in an actual algorithm! I don't have a working demo yet, but this is the quasi-implemented plan:

1) Hotspots.
First, we generate some random dots on the surface, representing hot convection plumes from the core/deep mantle (how many can be a customizable parameter):

2) Convection Cells. 

Next, we simulate what the convection cells for these hotspots might be. I'm going to use Voronoi cells to represent the convection cells. Voronoi cells are shapes drawn between a set of points indicating the regions of space that are closest to each individual point. This makes sense for convection, because these would be the boundaries at which hot fluids sliding along the surface from different plumes would hit each other and stop having anywhere to go but down.

In real life, convection currents often do take on Voronoi cell shapes under the right conditions, which can easily be MY conditions, because I can invoke any depth of planet, any age of planet, any amount of radiation in the core, etc. Here's two actual videos of Voronoi-like cells convecting in a hot fluid, followed by a hand-drawn Voronoi algorithm applied to my hotspot dots above, representing something similar:

(by Jennifer Liang and csegal0)

3) Plate Formation.

These cells radiate heat outward to the shared edges (below, I show this as a circle of heat, but it may actually work better if irregularly shaped due to different speeds of fluid flow within a cell). The heat will change the crust above it: weakening, blistering and thinning the rock, sometimes breaking through like in Hawaii or Yellowstone. These hot, thin, weak areas can rip open into a new crust-producing rift zone.

At the same time, cold (and therefore dense / heavy) crust at the furthest edges of cells wants to sink down. And especially if it happens to be thin crust that can break easily, it might just crack and do so, and one side can begin subducting.

Later, these cracks will be harder to form, but right now the whole world is just brand new, thin basaltic ocean crust everywhere and the first few plates form more easily using some simple pathfinding algorithms that use heat levels and thickness as "pathing costs:"

(red = rift, blue = subduction zone)

4) Plate Drift.

Due to our torus-world, we need at least two cracks to make two plates, since things wrap around. So here we now have two plates. Where do they move? Well, remember the strategy here is that the crust is just a side-effect of a much more powerful mantle. So the mantle convection flows don't care about our new fault lines. They just do their thing, and the plates respond dependently.

Therefore, the movement of each plate will be pretty much purely the resultant vector of the convection currents moving underneath it. So what we do is add up the resultant vectors for all the cells that are part of them:

And so we end up with two overall vectors for plate movement, appropriately moving toward the subduction zone and away from the ridge. 

5) New and Old Crust and Continents.

One of the plates will subduct under the other (coin flip at this point, since both are equally thin, cold, and chemically identical. Later, these factors will make one outcome more likely), causing volcanic island chains in the upper plate, which are then lighter weight than basalt and will stick around, forming the nucleus of our very first continents. And of course, where the plates spread apart leaving no data, new crust gets added on in the simulator. In the model for now, this is simply deleting some cells at overlaps, adding others at gapes (after movement), and keeping track of thickness and volcanism changes, etc.

This is hugely simplifying things. But for now, I need to keep things simple until I can get a working model of SOME sort, at least. Later though:

6) Increasing Complexity

Over time and with future features, this picture will get much more interesting:

• The plates will slide over the hotspots, which tend to weaken crust above them and maybe even break through, leaving a sort of perforated line of weakness which is then liable to crack to make more plates later, and more interesting dynamics. 
• At the same time, plates will sometimes fuse if jammed together particularly violently. 
• The plumes will slowly shift and rearrange.
• Continents will build up and alter the patterns of subduction. 
• Sometimes oceans may get gobbled up entirely.
• Thicker plates will be harder to break through for hotspot volcanoes.
• And plenty of other geologically-relevant things I haven't talked about at all yet: erosion (waves, wind, rivers), sediment deposition, rock metamorphism from heat and pressure, life forms, changing atmosphere (oxygen rusts minerals...), details of volcanoes, and more.

NEXT TIME

My focus now is on finishing up a few straggling bits of basic engine framework, Then implementing steps 1-5 of the above algorithm. Hopefully I'll have a working demo next time, along with tales to tell about whatever is bound to go wrong along the way! Or I may have to make a short detour into discussing multithreading or simialr. We'll see.

Geology Simulator - The Shape of the World

(Part 1 HERE)

THE SHAPE OF THE WORLD

Earth is a sphere. Due to their inability to fit rectangular grids, spheres are really difficult to work with in a program, though. Also, I'm making this geology engine for games that use rectangular environments anyway. So I'm not going to use a spherical planet. Instead, I need a different shape that satisfies the following criteria:

1. Easy to translate neatly into a rectangle or rectangular prism
2. Convenient to write code for (well defined, orthogonal dimensions)
3. Only one continuous surface, so that plates can smoothly glide anywhere and LOOK like they developed on a familiar spherical world

The best shape I've discovered to fit the bill is a "torus." It looks like the image below. Notice that it has rectangular grid cells all the way around, nice perpendicular dimensions, no annoying poles where everything comes to a point, minimal distortion of the cells (which I can just ignore), and a single smooth surface:

(image by Dave Burke)

You can also turn a torus into a rectangle easily. Just slice along where the red arrow is and where the blue arrow is, unfold, and you have a rectangle of surface, or a rectangular prism if you keep the thickness. In fact, we don't even really have to run our program as a torus, we can just use a regular 2-dimensional matrix, where things that go off the edge are assumed to show up on the opposite side. This is just a another way of looking at (projecting) the skin of a torus:

There are a few differences from a sphere for world simulating purposes. For one thing, cutting around either entire circumference (red or blue arrow or similar), unlike a sphere, does NOT divide the world into two plates. You need to make two cuts like that (red vs. blue plates below). Alternatively, you can carve out a chunk with one single border that does not wrap all the way around (green plate below):

Rectangular and toroidal versions of the same

tectonic plate situation (sorry the number of

cells changes, ignore that)

Another difference is that north and south are not destinations like on Earth, where you're as north or south as you can get. Instead, they are just like east and west: they're just directions of travel only, that go forever, looping around. The red arrows in the first image represent north and south, the blue arrows east and west.

CLIMATE

Finally, climate would be very different than on a spherical world, and climate matters for geology (glaciers, frost wedging rocks apart, etc.). I should only take this into account, though, if the game world is actually supposed to be a torus, not if I'm just trying to simulate a sphere. So I will probably just cheat and overlay a sphere's climate. But if it were actually supposed to be a torus, I believe it would look something like this:

The inner portion hardly ever gets sun, and is permanently iced over. The top and bottom of the planet suffer extreme temperature swings, with the sun never setting for half the year, and in darkness the other (if tilted like Earth is). Temperatures might be near boiling and then a hundred below across seasons. Plants can't live here, so the rocks are barren (migratory species might spend some time in the area to breed or similar, and sealife is sustainable. Very hardy annual plants might survive). On the very outer edge, the climate would be similar to Earth's temperate zones (like Europe), but with a double speed cycle of seasons. This is easily survivable year-round, and plant life is sustained here.

I'm no meteorologist, but the weather should also be different. The seasonal instead of daily temperature fluctuation would either make more extreme weather (due to the larger difference) or less (due to less turnover/mixing things up), I'm not sure. This is something to keep in mind if I want to simulate an actual torus world later when I get to erosion parts of the model.

PROGRAMMING STUFF
(Non-programmers: worth skimming, but don't worry about the details too much)

Organization

I'm writing this in C++, so in order to define the world's shape and behavior, we also have to start thinking about the world's major object classes. As of right now, I'm carving the physical world into the following organizational classes (there are also custom vector classes and things not mentioned):

WORLD: The whole world stores the plates in it and its dimensions. It also keeps track of the time. It has many important methods involving interactions between plates, like actually determining how far plates move together, which boundaries subduct versus crumple, and how much pressure and resistance plates get from the direction they try to move in. 

VOXEL: A voxel is a 3D cube that is the smallest size that would be seen during eventual gameplay. Such as a single block in Minecraft. These are not actually simulated during geological timescales.

GOXEL: A goxel (geological voxel) is a 3D cube that is the smallest size considered during geological simulation. I'm likely to change how many voxels make one goxel as I go, and have it later be a user-defined parameter. 16x16x16 voxels is a good starting point. Goxels don't do much, they mainly just store information about material types, temperature, pressure, etc. and get pushed around by other methods.

COLUMN: A column is the smallest size unit in the 2-dimensional rectangular projection of the world. It is a stack of some number of goxels (the thickness of the crust changes in different places around the world). Columns do various things as a unit that makes them a useful class. For example, they float on the mantle of the planet, and this can cause stresses that cause them to crack away from neighboring columns and cause fault lines. They're also convenient for erosion and other things, like efficiently swapping real estate between plates.

PLATE: A plate is a collection of columns. It gets moved by the world object, but it does various other things itself, like checking the buildup of pressure under the crust to calculate the likelihood of splitting into two plates (more likely the bigger it is) it also checks for whether columns have managed to create so many fault lines that they have effectively made a new plate.

REGION: Possibly a generic "region" superclass that has methods and variables relevant to keeping track of areas of the world that have other areas inside of them (i.e. all of the above except voxels).

Input

Whenever possible, I am going to attempt to make every constant number in the whole program come from a user-variable text file, which will be the main source of control and input, for a good combination of user friendliess and coder friendliness (I hate GUIs, especially in C++).

Output

I'm probably going to output as color coded image files or ASCII for now. One of my design principles is definitely to have all of the output be modularly separate from the simulation code, though, so other people could swap it all out later.

NEXT TIME

I'm going to try to tackle just plate tectonics alone first. Plates splitting, moving due to new rock in ocean ridges, slowing down as they smash into things, deciding to subduct or not, etc. I will keep track of crumpling or uplifting of rocks as just numbers for now stored in columns ("7" = more crumpled rock is sitting here than "3," etc.). Same for volcanism. I can use these to output colorful pictures and get an idea of whether it looks reasonable or not. Actually storing more useful versions of that information can come later.

A Geology Simulator for Game Worlds

THE STATE OF THE ART IN SANDBOX WORLD GENERATION

Unless you've been living under a rock for the last several years, I'm sure you've at least heard of the game Minecraft (and if you have been living under a rock, don't worry: you've been getting a very similar experience). 

The game uses a procedurally generated 3D world of blocks. You run around freely in a world that looks like the one below (default Minecraft) and dig and rearrange blocks to build things, such as the luxurious dirt hovel I put together especially for this blog post.

(Terrain generator by Markus "Notch" Persson)

(Built by yours truly! I also made this, by the way.)

I played minecraft for several years, as part of a server full of 20-40 year old nerds (the Voxelbox). We were not terribly impressed by the default gameplay, controls, or creative options. However, we did recognize an excellent core concept and a very modifiable set of bones to the game. We went about making a variety of tools to ease the creative process, allowing of course infinite free blocks, building from a distance, boolean shape logic, smoothing operations over thousands of blocks at a time, etc. Basically, the goal was 3D multiplayer photoshop. We eventually ended up being able to make landscapes like this:

or

BUT CAN I PLAY IN IT?

As nice as these end up looking (for a voxel engine), they doesn't really function as anything more than essentially a 3D painting on the wall. What if we still want to play the actual game?

• The custom landscaping is only a thin veneer for looks. You could never play an actual game on this landscape that involved any sort of digging under the surface. It's all just solid gray down there.
• It still takes hours of hand sculpting to make a section of land like this. It's fine for a proscribed experience like Skyrim, but not procedural games.
• They're made by fantasy artists, not people who actually know anything about geology (or biology), so these scenes still tend to lack a lot of realism even at the surface, something a mining sandbox game should probably care about.

What if we just forget it when we want to play the game, and use the vanilla terrain generator? Well, even though Minecraft does a somewhat decent job of procedural surface terrain, its underground situation is just plain terrible. When you cut open the world, it's little more than a random jumble of uniform gray "stone" and caves and such. Clearly this has no geological realism to it:

Considering that the game involves spending a huge amount of your time underground--you know, mining--this becomes a serious drawback of game design.  Other games, like Dwarf Fortress also heavily focus on 3D procedural worlds. Dwarf fortress does a better job of realism, including some layers and stone types in somewhat reasonable locations:

(Terrain engine compliments of Tarn Adams)

...But we are still looking at completely flat, fairly random jumbles of rock types, mostly shallow, rounded, boring mountains, perfectly straight vertical volcanoes/tubes pasted abruptly into the landscape with only 3 feet of obsidian around them, and no correspondence to any broader geological history, other than putting the broadest categories of rock in roughly the right order.

A significant improvement is needed. I plan to attempt this by making a terrain generator that simulates actual geology, rather than faking an end product with simple fractals like these games do. If successful, this should exceed the realism, variety, and gameplay richness of the current leading games in the sandbox genre for world generation, both above and below ground.

TO MAKE A REALISTIC GEOLOGY ENGINE FOR GAME WORLDS

I am planning on implementing the following features for a geology simulator:

• Proper plate tectonic-based continental history. Actual world plates will move around in a simulated history, collide, subduct, join together, break apart again, etc., forming realistic mountain ranges and continental shapes and compositions.
• Bouyancy of plates causing bending, uplift, and fault lines.
• Rock strata that curve in 3D when appropriate, for example when plates crumple together.
• All continents come from somewhere. The world begins as all oceanic plates, and any continent can trace its history back to simulated volcanism, uplift, etc.
• Realistic volcanism, with volcanoes of different types appropriately existing along corresponding plate boundaries. 
• Magma is modeled underground and may not reach the surface, instead bubbling up in intrusive plutons that solidify into granite for example.
• Metamorphism occurs from actual simulated pressure or heat from geological events.
• Erosion follows (simplified) watercourses, weather patterns, and frost wedging.
• Different rock types weather differently, leading to certain interesting and realistic features like Yosemite's Half Dome.
• A rough simulation of life as it is relevant to geological history at first (for iron oxidation, mass extinction coal and oil layers, limestone formation, etc.), as well as more detailed climate and biome types added at the very end of the simulation.

The goal is to get cross sections that look more like the below image, with obvious geological features like this old, solidified lava tube, volcanic cone, sedimentary rocks filling in above over time, and the oldest rock strata down below pushed apart into curved blisters when the ancient magma forced its way between them:

(pixelated version: this is lower resolution than would be used)

NEXT UP IN THIS PROJECT

I'll lay out my plans for the basic framework of the world (and of the program, written in C++), including the main data storage types, the shape of the planet, and some other high level planning.

Later on, I'll dive into large scale plate tectonics by themselves as the first major benchmark to get working.