Musings on a Realistic Tectonic Plate Model

Putting this here rather than in feature requests for reasons outlined in the “Conclusions” area of the below image. Just some thoughts I had while working on another fantasy map for a feature that could be incredibly fun and useful to some, but overall is probably not worth the time it would take to implement.

1 Like

Elaborating on certain aspects:

I would imagine that, in normal use, this device would be the first in a project. It would likely apply a default terrain (Maybe an option to decide what flavor of noise to use for the base terrain, or an input where a generator device could be plugged in?). The device would then define plate boundaries (Another possible area for improvement would be separating major plates and minor plates. For example, Earth has, if I recall correctly, 7 major plates and 8 minor plates, resulting in my 15 plate default) and densities based on user selection/input. The movement speed and simulation length could then be tweaked until a desirable world has started. This device could then be followed up with a normal World Machine workflow adding erosion, terracing, snow, etc.

Plate density would affect the likelihood of a plate to sublimate. For example, when a low density plate meets a high density plate, the higher density plate sinks below, causing a subduction zone near the coast, and the possibility for some lower inland mountains/hills.

Plate direction would be determined “behind-the-scenes” in the device, and would determine where and when plates converge and diverge. This would also inform plate rotation and movement, as a plate converging on the lower half of another plate would cause it to start rotating in that direction, increasing the complexity of the boundary zones.

I think the absolute biggest issue with this proposed device is the amount of cross and back referencing required. Each step would need to go back and refer to every other step, as well as every factor involved in the current step, which I could see very easily locking up even a high end processor for high resolution builds. Even with a simple two plate setup, it would have to constantly reference the convergent boundary to determine how high the mountains rise, and the divergent boundary to determine the width and depth of the trench/rift.

Beyond that, a weakness I only just now realized is that for a truly realistic terrain, erosion and tectonic shift would have to be happening simultaneously, as tectonic shift is generally measured in millions of years. To be calculating the tectonic shift as well as the erosion happening, especially with tectonic shift affecting erosion, might be outside the realm of what we’re technologically capable of right now at a consumer level.

I’ve been thinking of something similar! The biggest problem I see is the lack op 3D data in World Machine, as you cannot have two layers on top of each other with height maps. You can have the result of that terrain as a height map, but it is not possible to save the data of plate A going underneath plate B. This would be possible if World Machine were to support 3D data points, kinda like a particle system. That is quite a different approach from transforming heightmaps and would be the best for simulation, as you could give every particle different properties and so have more realistic erosion and such, but at a tremendous increase of computational cost.

I think it is better to create a tectonic plate system in something like Houdini, then create a height map out of it and import that to World Machine.

PS.
My idea is to have different hardness layers in your terrain (again, 3D data). This would make for more realistic erosion and especially “ease” the creation of canyons and such.

1 Like

As you might imagine, I’ve had a lot of musings on things along these lines over the years. :slight_smile:

As anyone who has created continent or world scale terrain before knows, the very thing that makes fractals so powerful (self-similarity) also is their weakness, as continent and orogenic-scale processes (tectonics, isostasy, etc) are quite different, and look quite different, than regional ones.

On the other hand, it doesn’t have to be as complicated as reality (“all models are wrong, some are useful”). For example, if the user was able to sketch ending plate positions and assign velocities to each, it would be possible to get a pretty neat continent-scale generator that puts mountain ranges, etc in places in a roughly controllable manner. For fully-automatic random continents, you could seed those initial plates and velocities from something like a cellular noise texture.

This is all far-off musings, but a lot of my personal interests come into play when looking at world-building and geological aspects of CG terrain so it is something I"m actively interested in for fun :slight_smile:

1 Like

@HYLK I fully agree, it would probably look better using something that worked in 3D space, although I don’t think it’s absolutely necessary. World Machine already excels at representing 3D processes with 2D data, so I believe you could still simulate the effects of subduction without actually having the 3D data of a plate going under another plate. That being said, yeah, a solution inside a 3D package would probably yield better, more realistic results.

@Stephen That’s a lot of the problem I’ve been having. As you’ve probably seen in a lot of my recent posts, I’ve been using World Machine for some world building in a tabletop RPG game I’ve been running, which I get is not at all the intended use case, but man, World Machine is still probably the best tool I know of for something like this (other than, you know, trying to hand draw realistic terrain).

I’ve actually been reading through a book I’ve had since middle school (though the book itself is almost as old as I am) about fractals, how they work, how to program them, and stuff like that. It was published only a few years after Perlin noise was “invented” (I don’t know if that’s the right word), and so far doesn’t make a mention of it. I’m hoping (possibly foolishly) to learn enough about fractal patterns and noise that I can start playing around with making my own algorithms. As much as self similarity isn’t as realistic for continent-scale things, maybe there’s an algorithm out there waiting to be discovered that at least works better! I’ll admit, though, I’m still on chapter one, so it’s like “Here, look, we made a line, then we put a line halfway through that line. Then we put a line halfway through that new line. Do that for infinity. Fractals!” So I may be a little too optimistic. I also seem to be in a weird period of my life where my first instinct when faced with a problem is “Make something to fix it!” no matter how unrealistic that is.

Anyway, I still think it’s interesting to talk about, and if anyone also has any more ideas on “faking” a tectonic model, or other real world features it would be interesting, though wholly unrealistic, to see in World Machine, I’m all ears! I do like @HYLK’s idea of varying rock hardness in layers for more realistic erosion. I think an interesting first step to that kind of thing inside a program like World Machine would be the ability to have two greyscale maps apply to the resulting terrain. You’d have the current top-down heightmap we’re all used to, but then you could have a second map from the side showing the hardness. Obviously not a super elegant solution, and could pretty much be faked right now by essentially applying a custom greyscale gradient to a heightmap, since the mentioned method would really only work by elevation, but it’s a thought ahaha.
I also keep getting ads on Facebook for a software called Clarisse that apparently can output/import images with depth information. It seems to be intended for compositing, but it got me thinking on what kind of implications that technology could have for heightmaps. I’d imagine that you could use that depth information in a heightmap to represent the distance to bedrock, which, while you wouldn’t be able to have soft layers under hard layers of rock, would allow for interesting erosion where the base level of the terrain isn’t uniform across the map.

A possibility would be to have a 3D noise representing the hardness, and intersect that with the surface of the current terrain based of the heightmap. You then get a slice of the 3D noise as and slap the values of each point on a 2D hardness mask and input that into the erosion device. The erosion device’s internals do need to change, as for every iteration you need to “re-slice” the 3D hardness noise (because the height of the eroded terrain changes and therefore the hardness of the terrain’s top layer changes). The advantage is you’d only need to calculate the 3D noise one time.

I was thinking about that, but I came to the conclusion that at that point, we’re essentially dealing with voxels instead of pixels, at least with my understanding of 3D noise, which I think would cause enough of a change to how the current model works that at that point, it’d probably make more sense to just convert the entire program to using voxels, and then we’re just dealing with a 3D program geared towards terrain. Which isn’t a terrible idea at all, especially since that would allow for things like overhangs and caves and the like, but would essentially be an entirely new program.

Honestly, thinking about it from that angle, since Terragen already uses 3D noise (and I think it technically uses 4D noise for clouds), it’s kind of a shame that it’s not nearly as robust or intuitive as World Machine for creating the terrain, in my opinion.

The 3D noise does not have to be voxels, but can just be a collection of vertices. Think of it as a huge 3D array and you check the hardness value for a given point on the heightmap in that gigantic 3D array.

For example, at coord x5 and y8, we have a pixel with brightness value 233. We then go into the 3D array, check for the value stored at 5,8,233 and use that value for the new point in the hardness map. Let’s say the value is 125, then at x5 and y8 on the hardness map, the brightness of that pixel would be set to 125.

I think we may be discussing semantics on that, at this point, then ahaha! My understanding of voxel was that it is literally the three dimensional form of a pixel, ie, a pixel that is defined by 3 values (height, width, depth) rather than a pixel’s normal 2. If that’s incorrect, I gladly retract my previous statement.

Editing to add that I was thinking in terms of pixels/voxels because each point would have a position and color/brightness value.

Well I could be wrong as well, so don’t worry! :wink: And I see your point to call it a voxel. I mean, if the 3D noise were to be displayed, it would use voxels I suppose?

Fair enough! In any case, I like the idea, though I feel it would have to be a bit more uniform than random noise. I feel with fully random/fractal noise, you wouldn’t get many, if any, large areas of homogeneous hardness, and the terrain would instead act more like a wheelbarrow full of sand with a bunch of gravel mixed in. I think the noise would have to start out as distinct layers, where each “slice” of the noise is a uniform hardness, and then the resulting block would then have the positions distorted, so that their layer-like structure would be preserved, despite having differing altitudes.

Edit to illustrate, though it’s a bit difficult to show what I mean with 2D images. Essentially, what I’m saying is (using Photoshop cloud noise and some distortion filters), the noise would have to look like this:


Rather than like this:

1 Like

The more I think about this, the more I like it! With this new form of erosion, the way I envision it, at least, the hardness value of a given voxel/pixel would be a measurement of how much/how many years of erosion it can endure before being carried away. When combined with water systems and a precipitation map, this could also solve some of the problems with hydraulic erosion we talked about in another thread. When the erosion reaches a hard layer, the surrounding land may be more susceptible to erosion, causing a river to widen until the harder layer has been broken through. And now I’m wondering; with that change in the erosion device, would we even need the noise to be 3D from the start? If we start with a 2D noise with layers like the one in my above example, but without the distortion, as a side view of the terrain, you could then use something like an advanced perlin device to drive the vertical distortion (as well as the resulting surface shape), which would essentially create a 3D noise field with minimal input data/processing. The starting hardness layer map could literally be a single pixel width, with a height proportional to how many different layers of hardness you want in your terrain.

Yes, I still think that is needed! If not, every layer is a homogenous sheet of the same hardness.

I do agree just putting in a perlin noise would be a bad idea and agree with the distorted layers! The only problem, again, is that you’d then only have variation in one axis, probably making for some strange artefacts.

That’s a very good point! I still feel we’d want the 3D noise to be biased towards horizontal, rather than vertical, similarity, but there would definitely have to be variation in all three dimensions.

Man! The more I try to work this out in my head, the more completely I realize how insanely complex and amazing planets are! So many different factors coming together, sometimes in surprising ways, to make this thing that, too often, gets referred to as just a ball of rock and water.

2 Likes

In researching, I came across this relatively recent (just over a year old) research paper on this specific topic. It’s a bit dense and math heavy, so I’m still working my way through it, just thought it might be an interesting read for anyone else interested (if you haven’t seen it already)!

1 Like

Interesting read! If only I could download that program, would like to see it the planets generated with it.

I can highly recommend this article as well. It’s about erosion and vegetation and how both influence each other and how to combine them.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.