Monday, September 15, 2014

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.

No comments:

Post a Comment