Terminal Moraines

This is just a brief musing on the impact of glaciers on terrain.  I won't go getting into the science of it too much, but glaciers can create or alter terrain features in interesting ways - in addition to being terrain features in their own right.  One of the features they leave behind after they retreat are terminal moraines.

Moraines are masses of rock that the glaciers convey to their edge.  The rocks vary in size, all the way down to the size of gravel and sand, and they accumulate.  When the glaciers retreat, the accumulation that is left behind forms a hill or ridge.

On an otherwise relatively flat landscape, such a hill or ridge could stand out.  It need not be uniform, especially after erosion may have redistributed it.  So you can get irregular or lumpy ridges.  Or a collection of hills.  Or, if moraine was left in what is now a lake or sea, islands.  Many of the islands in Long Island Sound are the remnants of the terminal moraines from the last glacial maximum.  Some are not though, the Thimble Islands for example being the remnants of rocky hills that were partially ground away by glaciers.

JavaScript fun for 3D

Yesterday I wrote about a few of the JavaScript libraries I found that would help solve some needs at Day Job (tm).  Today I'll mention another one I played with yesterday evening that may be of some interest.  I'd heard of three.js before, as it was used in the web-based planet generator I've mentioned in the past, but this was the first time I really looked at in depth.

three.js is a JavaScript library for loading, displaying, and interacting with 3D graphics inside a web browser.  WebGL was introduced as a web version of the venerable OpenGL technology years ago, but OpenGL (and, by extension, WebGL) are very low level.  three.js provides a higher-level interface, with support for loading models in various formats.  The website offers a multitude of example web pages with working examples.  It even has a few examples using fractal methods to generate a terrain that can be moved around in.

Alas, there aren't built-in loaders for the formats I need for Day Job (tm), but that's simply a matter of writing a compatible loader, or a separate converter program to take models in the formats we have them in and convert them to formats three.js can load.

Beyond work, though, it has the potential to be useful as the display end for some of the other things I've been experimenting with for fun.  I wouldn't want to write the code to generate things in JavaScript, but a web page using three.js to display the results would be entirely feasible. 

Surprisingly, three.js even offers a web-based 3D scene editor.  It isn't Blender, SketchUp, 3D Max, or AutoCAD, and there's no real mesh modeling support, only primitives like box, sphere, cylinder, torus, etc.  Nevertheless, it can be used to create a 3D scene relatively easily, and does have import capabilities so that models in other formats, like OBJ, can be imported.  It can export to OBJ, STL, and its own JSON-based format.  It can even publish scenes and a web page to view the scene.  Pretty slick.

Anyhow, if you need 3D on your web page, this is worth checking out.

Geology-related Travelogue

Over at Cat Rotator's Quarterly, Alma Boykin has a couple recent posts on a trip between Amarillo, TX and Albuquerque, NM.  While the space in between is in many ways very boring, Ms. Boykin's post covers some of the interesting geology and terrain features of the region.

Downtown

Downtown. Center City. The Central Business District. Whatever it is called, most American towns of any size and age have an area where most of the businesses were concentrated. Suburbanization, interstates, consolidation, and globalization have often take their tolls on such districts, but most towns continue to have such districts. Usually, such districts are reasonably central to the city. But not always.

Most of the exceptions are found where there is a terrain feature influencing development. Rivers, lakes, and seas can present a formidable obstacle or outright block to extending development in some directions. Hills, mountains, and valleys can have a similar influence. Sometimes even the angle of a slope itself can affect patterns of development.

Take the city of Cincinnati, Ohio for one example. Downtown is roughly centered with respect to east and west, but north and south is another matter entirely. The broad expanse of the Ohio River, beyond which lies the state of Kentucky, meant that any expansion southwards was not part of the city. And hills to the north of downtown were largely restricted to residential development. So downtown Cincinnati exists at the extreme southern edge of the city proper.

Toledo, Ohio is flatter than Cincinnati, but the obstacle presented by the width of the lower Maumee River slowed development to the east. Toledo's downtown is closer to centered than Cincinnati's, but it still isn't precisely balanced.

An extreme example of such a lack of balance in the position of a downtown can be found in the large village of Montpelier, Ohio. As a town of nearly five thousand, Montpelier has a nice little concentrated business district. Despite the relatively-flat terrain, this district is nevertheless located almost at the extreme northwest of the village's development. The vast majority of residential development extends south and east from the downtown. Why? I've got no clue, but it is a bit noticeable when looking at overhead imagery of the area.

Plate Tectonics - 13

I decided to take a brief break from wrapping up the Plat Tectonics simulator work to actually play with it and see about using the generated elevation data in other programs.

Graphical output from Plate Tectonics simulator.
Single-precision floating-point data is actually used for interchange.

First off, I modified my C# port of Amit Patel's polygon map generator to support imported elevation data. There's still some incomplete features in this program, especially with my "Tolkien-esque" rendering mode. When using imported elevation data, sometimes the river networks have anomalies, caused by low spots - "dips" or "holes" - within continental interiors.  This could be addressed either within the Plate Tectonics simulator or within the map program.

Elevation data from Plate Tectonics simulator was the data source for
this image in a polygonal map generator.

Close-up of the northwestern continent, in Biome view.

Close-up of part of the map, in "Tolkien" view

I've also implemented an import mode for the planet generator I've mentioned in posts past. For terrestrial planets, it usually uses 3D Perlin noise to create the elevation map of the world.  With the import, it uses the imported elevation data instead of the noise.

Map created from importing the elevation data into Planets program

The map wrapped around a globe, with some fractal clouds partially shrouding the planet.

Plate Tectonics - 12

It is all over but the cleanup.  The algorithms are all working about as I'd like.  I understand the erosion algorithms a lot more now.  The original version of PlaTec from several years ago used a modified image smoothing algorithm for erosion.  The 2015 version incorporated, in sequence, a hydraulic erosion model (rain drop method), the adding of some random noise to the elevation, and then a super-simplified but effective approximation of thermal erosion.  Run it too frequently, and the continent would erode away to sea level, but often in the interior before along the coasts.

Example 1

Because of some of the abnormalities (the "caterpillars" and eroded mountains) and that tendency, I added a coastal erosion process that lessens the elevation of cells adjacent to water, and run the main erosion algorithm less frequently.  I also increased the threshold for the main erosion algorithm, reducing over-erosion of the continental land masses.

Example 2

About my only complaint is the high degree of variability in the "quality" of the results for a given set of parameters (other than the random number generator seed).  The majority of results are acceptable, but some oddities can show up, and you never know if you'll get them or not.  So this isn't greatly amenable to fully automated operation; a person should definitely review results for suitability.

Example 3

So what's left before release? Just the cleanup. I have a variety of debug outputs that need to removed. There are a handful of functions that should ideally be made members of classes if possible - in one case, I'm not sure its possible due to how FLTK callbacks work. I guess I'll find out. I drastically increased the number of simulation parameters that were exposed. However, the export code only currently writes out the few parameters that were originally exposed. So that will need to be updated. I suppose it could also use a quick document describing the simulation parameters and how to accomplish different basic goals with them can be accomplished. Then to GitHub with the lot of it.

Parameters - these should all be written to file when exporting image or elevation data

Plate Tectonics - 11

Well, never mind then.  I understand where the problems I'm running into with non-power-of-two dimensions comes from.  It comes from the multitude of bit-wise operations that depend upon the width or height of the map being a power of two.  One less than a power of two results in a "mask" with all the bits below the bit for that power being set to one.  That is, if the value is 8, the binary is 1000, but if the value is 7, the binary is 0111.  So a bit-wise AND operation of a coordinate and the length of a side of the map would result in a value that was always within the range of the map side's length - but only if the side (width or height) is a power of two.  If the dimension was seven, the binary would be 0111, but  binary for one less would be 0110.  That screws things up.

The code is riddled with statements like

if (area[i].lft == ((lft + 1) & (map_width-1)))

and

size_t k = (y & (map_height - 1)) * map_width + (x & (map_width - 1));

They are short, terse, and computationally inexpensive, but they fail to work properly when the map_width and map_height values are not powers-of-two.  I started to rewrite code to address it, and was making a little progress. Unfortunately the end product is several extra lines of code for each such instance, and involves more computationally expensive (costly) operations than a simple bit-wise AND and a subtraction operation. After 90 minutes of work, it was almost right in one function, as shown below.

512x384 map of the plates.  Almost right, but still seeing red, which indicates plate is missing.
768x384 and 768x768 show similar problems.  512x256, 512x512, 512x1024, and 1024x256 maps do NOT.  

But not quite right.  And that was in only one function among several, and many of those functions made far heavier use of those AND operations.  So I made up my mind.  Rather then go through the many hundreds of lines of code that use such statements, and rewrite them into more computationally expensive (costly) operations and adding many news lines of and taking perhaps another dozen hours, I shall give up on non-power-of-two dimensions for this release.  Maybe someday in the future.  So no 1024x768 or 640x480 or 512x384 output for now, but 1024x1024, 1024x512, etc. should work just fine.  I'll make some comments in the code, remove the non-power-of-two dimensions from the GUI, and move on.

Integration of parameters from the GUI into the simulation will likely be my last thing to accomplish before I release this, unless I uncover additional problems.

Plate Tectonics - 10

It is well after midnight.  My first approach at getting the erosion situation ("caterpillars" vs. worn-down mountains) resolved did not work nearly so well as I had hoped.  Careful tuning was not enough.  Either it was ineffective or it eroded land down to shoals.

Not cutting it

So I decided upon a new approach. The erosion algorithm has been split into two.  One is the "wave erosion" for coastal and island erosion. That's my very crude but rather effective method. The other part is the rain drop algorithm implemented by the original PlaTec developer, Lauri Viitanen.  Wave erosion runs more frequently than the regular erosion.  This is a fairly effective approach, although different parameters can yield different results.

Decent mountains, island chains, few "caterpillars"

I'm still not quite happy with this outcome. Some of the simulation parameters are still hard-coded constants.  I have another few hours to go integrating all the parameters shown in the GUI as true parameters that can be passed into the main simulation class.  The restart and aggregation overlap settings can really improve the compactness of the continental masses that form.  Likewise, having the fractal parameters driven from the UI (or later, a settings file) will be quite nice - as it is, I currently have to make changes to hard coded constants.  Ugh.

Parameters organized

I was testing non-power-of-two dimensions for the map and discovered a problems.  I can use whatever aspect ratio I want, but if any dimension is not an exact power of two (two raised to an integral positive power), problems ensue.  I am currently debugging this, which yielded the colorful image below.  Each of the grayscale rectangles represents the bounding box of a plate, while the red represents areas that plates have moved away from.  Those lines?  They represent an indicator that I have problems. So, either a bit more work, or forget about non-power-of-two dimensions for now.

Seeing red

Plate Tectonics - 9

As I mentioned in my last post on this topic, I believe the erosion algorithm for the Plate Tectonics simulator needs to be tweaked.  I've been analyzing the current erosion code and discovered that unlike the original version of PlaTec I worked with that basically used a smoothing algorithm, the version I'm working with now looks to be using the water drop erosion algorithm, akin to what is described as hydraulic erosion in Musgrave's work. In addition to the erosion proper, the function that implements the erosion also introduces some random noise (variations in elevation) every time the erosion function is called. The difference is "splotchy" without random variation vs. "grainy" with random variation, as seen in the image below.  Have I discovered the need for yet another parameter?

The current set of parameters is already pretty large. I'm still working all of these parameters into the code base. A lot of them are currently constants. Now they need to go into/come out of the parameters window and get passed to the simulation code.

Parameter chaos.  Perhaps grouping them into labelled groups and changing some into sliders will improve things?
In many case, many times just leaving the values as-is works great.  But not always.  It depends on your goal.

And I still need to back and fix the problem that I posted about previously, the "caterpillars" and over-eroded mountains.  That's why I started looking at the erosion code in the first place.  I basically want the land bordering on ocean to erode faster than the mountains.  The "caterpillar" islands form from too little erosion of islands in the oceans formed by plate movement.  Attempting to prevent the "caterpillars" by increasing the frequency with which erosion is applied causes the mountains to erode too quickly instead.

Conceptually, I think it is as simple as a scalar factor for the amount of material to move when the erosion algorithm moves material from a "high" cell to neighboring "low" cell(s).  My first approach would be that the scalar could equal the sum the number of neighbor cells that are below sea level, divide by four (von Neumann neighborhoold, not Moore), plus 0.5.  Hence a "high" cell that was inland would erode at half the nominal rate, a single-cell island would erode at 1.5 times the nominal rate, and cells belonging to larger islands or on the coast would erode at an intermediate rate. This actually makes some sense within the context of the simulation, as well, as wave action and rainfall would result in more erosion than rainfall alone. We'll see what it takes to implement that once I fully understand the existing implementation of the erosion algorithm, then how well it works in practice.

Plate Tectonics - 8

So close, yet so far.  That's the best description of the current state of the Plate Tectonics code.  I've got a decent feel for the parameters now, and will be exposing them through the UI so different effects can be achieved.  However, there's two different artifacts caused by the erosion period parameter.  Run erosion too frequently, and the mountains erode down from something like the Rockies, Alps, and Himalayas, to something more like the lesser portions of the Appalachians or Catskills.  Run it too infrequently, and you get long "fuzzy" islands or island chains that remind me of caterpillars. Hours of running simulations show it is almost impossible to find a "happy medium" by simply adjusting the erosion period. I think the erosion algorithm needs to be tweaked to increase the level of erosion for sea-exposed cells and/or decrease it for land-bound cells.  Perhaps a scaling factor calculated from the percentage of neighbor cells that are below sea level?

An example terrain mapped onto a globe

Examples of "caterpillar" islands arising from too little erosion

Examples of heavily eroded mountains, from too much erosion

Reading, Writing, and Plate Tectonics

I made more progress yesterday with the Plate Tectonics simulator, almost finishing it.  I tweaked the variables and all worked well at a 256x256, 512x256 and 512x512 resolution.  Alas, I discovered that when the resolution is increased to 1024x512, certain parameters that are currently constants need to be changed, otherwise the results look clunky.  So I need to go back and turn six constants into variables, expose them, and update the UI so they can be altered by the user.  Probably another few days for release, because I'll want to run a lot of simulation cycles to be able to set decent defaults and provide recommendations for different setting levels.

My writing of The Forbidden Valley bogged down temporarily, but as I sit drinking hot cocoa, I think I know how to resolve the problem in the scene I'm working on.  I'd written ahead of that point, but hadn't been able to resolve the problem in that scene.  I think I have now, though, so snippets may be forthcoming again soon.

I read three novels yesterday: Loose Ends by John van Stry, and Scout's Law and The Fugitive Heir by Henry Vogel.  All three were a lot of fun and I intend to write reviews when I have a chance - including brief ones on Amazon.  I am also continuing with reading Lincoln Paine's The Sea & Civilization, a non-fiction maritime history, and have made it to just short of the one-third mark.  This is a long but engrossing work, but is definitely a slower read than the romps provided by the novels I mentioned at the start of the this paragraph.

Plate Tectonics - 7

Rectangular maps!  At last, I have them.  Alas, I must also do a lot of parameter tweaking.  One of the peculiarities I'm running into is large numbers of enclosed basins.  Initial land masses are formed using fractional Brownian motion (fBm) algorithm that uses OpenSimplex noise as its basis function.  Aside from resulting in some enclosed basins (low points) in the land masses to start with, it also results in a number of islands and peninsulas that can result in basins when portions of land masses collide and there isn't enough subduction for the basin to be closed.

This is not totally unrealistic.  There are a number of inland seas and massive lakes on Earth.  The Caspian and Aral Seas are good examples of the former, and the Great Lakes of the latter.  However, they do seem more prevalent in these maps.  Perhaps reducing the number of "octaves" for the fBm will reduce that.  I'm not sure yet.  It will require some experimentation.

So, to summarize, more progress, but not quite done.

Plate Tectonics - 6

The replacement of the square-diamond algorithm for initial land mass generation has been completed.  The OpenSimplex algorithm is now in use instead.  It may need some parameter tweaking to achieve quite the right effect, but is providing mostly-satisfactory effects already. Two examples are shown below.  So what's left before release?  Code-wise, the last alteration is supporting arbitrary map dimensions.  The current code base assumes a square map, and there are well over a hundred references to variable map_side.  I'm going to have to go through all of them and figure out if each reference needs to be replaced by map_width or map_height.  Joy.  Hopefully that will be the last of the changes, and then I can look at putting this up on GitHub and figuring out how to distribute the executable.

Example output from Plate Tectonics simulation

Another example output from Plate Tectonics simulation

C++ integration with .NET Framework

I was making a bit more progress on the Plate Tectonics simulator when a thought occurred to me. The simulator is written in C++ and I'm compiling it as an executable with a relatively-recent edition of Microsoft Visual Studio.  The simulator, and some of the other libraries it relies upon, are LGPL licensed.  I can wrap the C++ code for compatibility with the .NET Framework, and produce a DLL, licensed under LGPL. Then I can use it from other software with more or less restrictive licenses (MIT, BSD, or something proprietary) without problems, because it is a library.

It seems like it should be fairly simple, technically speaking, but I've never done it before. I found a nice tutorial. The only sticking point is I haven't figured out how structs can be translated/marshaled between managed and unmanaged (native C++) code. For passing the ever-growing list of parameters for the simulation, I'll have to either do so or else make them available as properties of the main simulation class (not my preferred approach). I'll worry about it once I've got the Plate Tectonics simulator otherwise finished.

You may wonder why I'd want to do this.  The main reason is because while the simulator is a good starting point for planet generation, it is a poor stopping point.  Additional terrain generation, or even just pretty maps, should follow from it.  This is one approach to that goal.

Small fantasy map generator

I ran across an interesting web page on fantasy map generation.  It's actually pretty neat, is open source, and can generate small map on the web page itself.  If you're looking for a Tolkien-esque map of a small portion of randomly-generated world, this could be useful.

Example of a map generated on the linked web page

Note that it only creates a coastline, rivers, city locations, borders, and crude hills/mountains.  There are no forests, swamps, etc.  Maps are limited to the small square image shown above.  But it could still be useful - and for programmers, the techniques could be useful in other contexts beyond the simple web page they're shown on.

Orographic effects

Over at Cat Rotator's Quaterly, Alma T.C. Boykin has a post that mentions fog resulting from orographic lifting.  This got me thinking.  (Dangerous, I know.)  Orographic effects abound.  Ground fog in the Texas Panhandle is the least of it.  Orographic clouds form when moisture in the air rises and cools.  This is why clouds are so often observed near the peaks of island mountains in warm waters; the air is most from the surrounding waters, and as that air is pushed up and over the mountains, the clouds form.

When rain then falls from orographic clouds it is known as orographic rainfall.  Such rainfall can cause more than just a spot of bad weather, but can impact climate and topography as well. The rain shadow effect of tall mountains, and the often lush environment on the opposite side of the mountain, are a prime example.  More rainfall will also typically cause more erosion, which is reflected in more erosional land forms (gullies, ravines, streambeds, etc.) on the wet side than the dry side of the mountains.

Just something to keep in mind when designing a world, be it for a game or a story.  And something to account for when writing programs to create worlds, too.

Plate Tectonics - 4

I didn't accomplish as much as I'd hoped today, courtesy of Real Life.  In any case, I made a bit more progress on the Plate Tectonics simulator.  Alas, I also decided to finish up a few things I'd originally though to leave for the future, so I'm not sure I'm actually any closer to completion.  [sigh]

In a post yesterday, I mentioned I'd found code for a more recent version of the PlaTec simulator.  I've incorporated most of that updated code and done some minor refactoring to better modularize the program.  Previously, the simulation and the UI had been a bit too intertwined, legacy of my not having done anything much in C++ for ages, and only second time using the GUI framework in question (FLKT).

Updated parameters dialog box

So what did that get me?  The updated PlaTec code brought better erosion algorithm, fewer visual anomalies, and slightly slower simulation.  The refactoring will eventually allow console-based execution as well as the current interactive GUI mode.  And I've made a few more parameters accessible via the GUI.  However, two parameters that are the GUI no longer accomplish anything.  I have to modify the updated PlaTec code to permit the parameters in question to be supplied via code, rather than treating them as hard-coded constants.  One of the other features I'd originally considered for a future enhancement, a parameters file, I have decided to at least completed the code for writing to file.  Reading in is likely still a future enhancement, but I'd like to know what parameters I used to create any given map.

Map generated using updated (2015) PlaTec code.
Note the greater variation in elevation, as depicted by color variation, as compared to earlier examples.
Note also that there are fewer high plateaus.  
The number of strange islands is also reduced, replaced by more coherent islands.

Map created with earlier PlaTec code.  Note lesser variation in elevation/color, and greater number of high plateaus.

Plate Tectonics - 3

In preparation for releasing the plate tectonics simulator, I went to the site hosting the repository for the original PlaTec simulator, in order to confirm the license was LGPL as I'd thought.  I was correct, it was under the GNU Library General Public License.  However, I also discovered there was an update to the code two years ago, including some sort of Java-based GUI, and a C API to the code.  I'm going to look at incorporating the updated simulation code into my release.

I overslept, then spent a bit of time today helping a friend.  As a result, not much progress was made on this project today.  However, here's another pair of planets generated with slightly different parameters than yesterday.  Increasing the "restart speed limit" parameter from the default 5.2 value generally allows less time for the simulation to run per cycle.  Both were generated with nearly identical parameters to each other, but notice the difference one cycle vs. two cycles makes.  There are more mountains, and more larger mountains, with two cycles.

Result from seed 53, 1 cycle, 15 plates, sea level 0.75, restart speed 9

Result from seed 53, 2 cycles, 15 plates, sea level 0.75, restart speed 9

Plate Tectonics - 2

In yesterday's post, I mentioned my efforts to convert Lauri Viitanen's 2012 thesis project, an open-sourced plate tectonics simulator, into something with a GUI that would run on a Windows platform.  One of the items I thought still was required was a "centering" feature, to minimize the amount of land wrapping at the edges of the map.  I managed to do so tonight, though I will need to make some changes to integrate it better.  Still, you can see the results in the examples below. In my (not so) humble opinion, the centered maps on right look far better than the ones on the left, but the only difference is positioning.  

Anyhow, aside from integrating the centering code, I would also like to complete the JPEG export. And then I think I shall call this project complete and put it up on GitHub.  There's a lot more that could be done with this.  In terms of features, it could use some better erosion algorithms. As it stands now, "erosion" is simply a smoothing algorithm applied every so many iterations, and at the end of each cycle.  An erosion algorithm that operated on the islands and seacoasts periodically would help reduce some of the odd island growth that is sometimes seen.  Additional output formats (image and elevation) might be nice, but probably aren't essential.  A header file to accompany the current elevation export would be nice, specifying at minimum the map dimensions and sea level, but possibly the full set of parameters used to generate the map.  Really nice would be a different initial landmass generation algorithm, so as to allow non-square, non-power-of-two map sizes.    

In terms of the code itself, it could also use some work.  When I originally worked on port this program three years ago, it was only the second time I'd used FLTK, and the first time I'd used C++ in years.  I'd organize the code a bit differently, especially in terms of classes and how I integrated the output from FLTK's GUI designer, FLUID.  Maybe add support for running from command line, too.  It wouldn't hurt if I were to write some documentation for this, at least a readme file.  That's all for the future, if ever.

And as I wrote that previous sentence, another idea popped into my head.  These algorithms take a long time to run the simulation.  Perhaps if a large number of maps were generated, the resulting islands and continents (land masses) could be extracted and stored.  Then when a new map is required, it could be assembled by random placement of several random selections from the stored land masses.  Just thinking aloud here.

Plate Tectonics

I've mentioned before PlaTec, a simple plate tectonics simulation program.  This evening a spent a little bit of time working on my old port of it to a Windows environment with an FLTK GUI.  I've fixed a few problems, and have added some basic export capabilities.  It's pretty basic, really.

First you enter some parameters.  Because the initial landmass is generated using the diamond square algorithm, the map must be square, and the dimensions must be powers of two.  The cycles indicates the number of cycles - splitting of the world into plates and moving them - that should be performed. The plates indicates the number of plates.  Sea level is a number between 0 and 1 approximating how much of the world should be sea.  The random seed determines the initial landmass shape as well as coordinates for the plate origins.  Restart energy ratio and restart speed limit determine how slow plate movement gets before a cycle ends; IIRC lower numbers tend to let the simulation drag on for longer.

Parameters for plate tectonics simulation

Once the OK button is clicked in the parameters window, the simulation begins.  The initial land mass is created, the world is split into plates, and movement begins.

Simulation GUI

Below are some examples of output.  Because the simulation works on a 2D basis and wraps vertically and horizontally, I think a centering feature to be applied upon completion would be useful. As you can see in the examples, the land masses in the end result are often wrapping across the edges; centering would make for more attractive maps.  They'd also be more realistic if the north polar region and south polar region didn't wrap.  :)  Centering accomplishes that in many cases.

I'm going to put in a bit more work to finish up the export - write now it does PNG and RAW images, and a raw elevation dump in floating point - but I also want JPEG support.  Also, I think the program needs a centering feature.  At that point I'll probably put it up on GitHub.  The original version of this simulation was originally a computer science student's thesis project back in 2012, and there's a paper on it. He released the code under an LGPL license and placed the source code on Source Forge.  All I've done really is provide a GUI that will work with Windows.

This simulation can produce some nice crude planet maps, but it is slow.  Tens of minutes may go by for completion using the 512x512 and only a single cycle.

Seed 44 with 1 cycle

Seed 44 with 2 cycles

Seed 45 with 1 cycle