Monday, October 27, 2014

Geology Simulator -- Minerology and Petrology Systems

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 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!


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?


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:

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:


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.


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.)

Sunday, October 19, 2014

Acetone Vapor Baths for Smoothing 3D Printed Objects

Recently for my job, we've been developing some 3-D stimuli for children's psychology experiments. We found a 3-D printing service for rent at the university, and it works great, but the texture on the finished pieces is a bit distracting. In our case in particular, weird object textures might actually affect experimental results. We want to make the texture smoother, but without spending hours with sandpaper. So we decided to try out an acetone vapor bath solution.

This is what the initial texture looks like from my university 3-D printing service. It holds decent detail, but the lines of plastic laid down are still visible, and that texture is going to show through even if painted.

We can address this by exposing the piece to acetone vapor, which melts / reacts with the ABS plastic the 3-D printer uses, leaving a glassy finish. You can see the basic setup below. A large mason jar has a couple of tablespoons of acetone in the bottom of it. It is then also sitting in a hot water bath, which inceases the vapor pressure and speeds the reaction. I microwaved my water until it was boiling. The piece was then suspended from the lid inside the jar to bathe in the acetone vapors without touching the liquid directly:

It is very important that an airtight seal be achieved, one that is strong enough to withstand pressure inside the jar. In the above images, I was trying to use some paint to seal the gap where the screw goes through, but that didn't really work. Later I tried a similar setup with clay as a sealant, and it worked perfectly. This following setup also worked, using super glue, although I don't know how it will stand up long term to the acetone (I switched to clay after just two runs):

The yarn here is wool. If it were acrylic yarn, there's a pretty good chance it would have melted in the acetone fumes and dropped my piece into the drink. Paper clip chains would have worked, too. Double check that everything in your jar is acetone-proof, or test it with a junk piece (which you should probably do anyway), before you rely on it for something you care about.

When the seal is air tight and the water is hot enough, you should see acetone condensation on the side of the jar. That's an indication things are going quickly enough and that the seal is good. If the seal is leaking, you should be able to actually hear hissing if you listen closely, and won't see much condensation.

Here you can see it melting the surface. In the first image, notice that the bottom portion is smoothed out, but texture remains on top. In the second image, there is still some texture on the very inside top, but even that is looking glassy, and all the edges are done:

When the piece looks sufficiently smooth to you (up to an hour for me, and maybe a change of re-heated water bath), take the jar out of the bath and place it in a sink. Now, fill up a glass of water, and have it ready (or the faucet), THEN remove the lid just enough to be able to douse the piece in water.

Don't let it touch the sides of the jar yet, until it is doused. The plastic with acetone still on it is very sticky, like warm caramel, and it will stick to the walls and leave ugly marks on your piece. After dousing with water, it's much more resilient. Enough so to pull out and hang somewhere to dry.

The piece will also attract dust while it is "curing." If you have a spare jar available, you might want to reserve one for drying purposes, to cut down on dust that permanently sticks to the surface. I hung my pieces from the corner of the drop ceiling in my office, and they avoided dust pretty well.

Below is the finished piece. For about another day or so, it will be soft and easily damaged. Not so soft that you will leave fingerprints, but enough for a nail to easily scratch it. The dotted line I drew here was from minimal pressure with a bic pen. If you can, it's best to just leave it hanging somewhere and not touch it at all for a full day.

Notice that the corners definitely get gooey and rounded, so if you need precision, this is not for you. It's an aesthetic thing, like if you're 3D printing a piece of an artwork or similar. (Note: the side corners near the slots in the photo here were actually damaged by the piece being slightly too big for the jar, not by the process).

Here's another piece that shows how easily blemished fresh plastic is out of the bath - I was hanging it by the eye socket there, and just the weight of the piece itself pressing against a metal screw left that gouge mark. So be careful how you hang your piece!

If you prefer, and if you have a big enough glass container, you can also lay the piece into a platform in the bottom instead of hanging it. A piece of wood with nails works well - balance the piece on the tips of 3  nails, and the marks left behind will be minimal. Keep two things in mind, though:
  1. The distance from the piece to the acetone will affect how quickly it melts the top versus bottom relative to one another, because fumes are thicker near the liquid and the water bath.
  2. Try not to leave any large surface flat on top. Tilt it slightly instead. This prevents acetone pooling from condensation and leaving blisters on your piece. You can also do this when hanging the piece, by hanging it slightly off center if possible.

Saturday, October 11, 2014

Let's Build an Organ Pipe!

Part one here!

In this post, I'll go step by step through my process for creating an (unpainted) PVC organ pipe! An organ pipe has two parts: the resonator, which is most of the length of the pipe as a simple empty tube, and the fipple, which creates oscillations.


The resonator takes vibrations (or perhaps more accurately, oscillating air vortices that I don't entirely understand) from the fipple and resonates at a fixed, controllable wavelength, allowing specific tones for music. Each pipe is going to produce one fundamental tone, just like individual strings in a piano. A single pipe will create several other tones at once when sounded, equaling integer multiples of the fundamental frequency (harmonics). The smaller the pipe, the more prominent the harmonics, but the fundamental is always the strongest.

Here are some different harmonics fitting into a single pipe (top three waves) and a fundamental of a longer pipe (bottom), with distance from midline being relative min and max pressure for each one:

However, less so than composers, we don't need to concern ourselves much with harmonics for building the organ. The pipe will sound like the fundamental frequency when you play it. So what matters more for us is the bottom of the image above: When you make a longer pipe, it will naturally resonate at a longer fundamental frequency. Longer waves are heard as lower tones. So by making different length pipes, we make different notes.  One half the length of pipe = one octave lower, and other notes vary by even logarithmic steps in between. In other words, human perception varies logarithmically with frequency.

So the resonator, at the end  of the day, is just an empty tube of the correctly calculated length. I'm making mine out of PVC pipe. For tuning purposes, I also have slightly larger pieces of pipe on top that can slide up or down to make fine adjustments to the lengths for tuning.

Middle C is an open pipe of about 2 feet in length, as a point of reference. A concert tuner of the A above middle C at 440Hz is about 1.28 feet long. 

Closed pipes (with a stopper at the end) have twice as long of waves, roughly, because the wave has to "reflect" the length of the tube then back again from the fipple. A closed pipe sounds one octave lower than it normally would, so middle C would be about a 1 foot long closed pipe. This is useful if you want to fit big pipes in an apartment building.


The fipple is the vibration producing part of the pipe. I'm going to be routing air to my pipes by plastic tubing, so it needs to convert a stream of pressurized air from a circular tube into a consistent vibration. The fipple is much harder to make than the resonator.

Briefly, the concept of a basic flue pipe fipple (meant to sound something like a flute) is:
  1. You somehow shape incoming air into a laminar air flow (a flat, non turbulent sheet of air).
  2. You get that flow to pass right into a thin knife of rigid material, which will then vibrate.
  3. The vibration resonates in the resonating chamber.
The way we make those things happen is by building something like this:

The pipe (red) has a cap on the end (black) with a hole for the air hose (green). There's also a plug in the pipe (orange). Air comes into the cavity in the back and has nowhere to go, except for a narrow section of pipe cut away at the top. This forces the air into a sheet, which passes over and under a knife shape cut in the pipe (red also). This vibrates, which then causes resonation in the pipe (left off the edge of this image). Again, I think it is more like oscillations of swirling air systems in a much more complicated way than just vibrating, but that's close enough for me to build it.

So without further ado, let's build it! We begin with a PVC plumbing pipe:

First, we need to cut a notch out of the end. The width of the notch is related to the diameter of the pipe, something around 2/5 the diameter. The depth of the notch depends on the system you're using for a cap. I used this tool here, a dremel with a grinding fiber/ceramic/something wheel:

Here's the notch cut out:

Then I used a much wider grinding stone (seen below), 100 grit sanding drum (not shown) and finally manual 220 grit sandpaper (not shown) to grind a sharp, gradual "knife edge" on the inside of the notch. Grinding stone:

Knife edge after all the dremeling work:

Knife edge after hand sanding:

We need a laminar sheet of air now. I achieved this by using the thickness of the PVC pipe wall itself as a guide for a sheet of air. So I need to block off the inside diameter, AND the outside diameter. The inner diameter is blocked using this section of a solid plastic dowel rod:

The corner is sanded down to aid aerodynamics (the air needs to be smoothly guided toward the knife). The plug fits into the pipe snugly. Notice how the pipe walls stick above the plug, so that when the cap goes on later, there will be a thin slice of opening:

A hole is drilled in the middle of the pipe cap. This is where plastic tubing will go to deliver the air supply:

And finally, the cap is attached. If you look closely, you will be able to see the thin slice of empty black space in between the plug and the cap nearest the camera. This is the guide for the airflow to make it into a sheet of air. It will then pass right into the knife edge, creating the musical vibrations, which resonate in the remainder of the organ pipe:

Again, here's the schematic now that you've seen the real thing:


In the next installment of this series, I will explain how the air system works, and I think I'm going to actually try out a new idea, different than my original plan, for how to activate air flow to individual pipes. I will try experimenting with homemade electric solenoids, versus the alternative of manual springs and levers and things.  If the electric version works, then the whole organ could be played either manually OR by computer program, potentially!

Saturday, October 4, 2014

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.



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.


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 turbulenceteamm)


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.


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.


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.


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.