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!
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:
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.
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.
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
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:
- 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!
- If crystals are already tinier than sand, then they won't probably erode into sand, for example. This compounds with #1 above.
- 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!
- 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.
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:
- How many substances are present
- 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." - 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.
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.)
(Update: Promise completely broken, but I do still plan to get back to this.)
Wow, this is really impressive stuff. I am looking up for the enxt post, I want to see your tectonic algorithm in action. It is one of the best tectonic algorithms I found on the web so far
ReplyDeleteI'm really impressed by your work and research on this topic so far. Though I have next to no C++ experience, I'd be happy to help you fill out the raws with data on minerals from Wikipedia, or fill in some hydrology related stuff (I have a textbook). I'd love to see this work incorporated in DF, Minecraft, or the next sandbox world game out there!
ReplyDelete