Fantasy Planet Painter
Whole-planet-scale fictional world-building: continents, mountain ranges, rivers, valleys, and features as small as individual hills. Maybe eventually trees, buildings, houses, roads, and cities too?
That has always been roughly the idea behind Fantasy Planet Painter (FPP).
Making a good-looking fantasy map is one part of the goal, but the longer-term idea is more ambitious: making an entire fictional planet something you can actually author, organize, inspect, render, and use.
With the upcoming Fantasy Planet Painter 2.0, we are finally starting to build more seriously toward that idea.
The Beginning
FPP had a rather humble origin: I needed to create a world map.
Naturally, I started with GIS software. First ArcGIS, then QGIS, and along the way I learned my way through map projections, layers, coordinate systems, GeoServers, and all the other fun stuff that comes with GIS.
GIS is incredibly powerful, but for making a fictional planet from scratch, the workflow was not particularly efficient. I wasn't really trying to analyze an existing world; I wanted to sit down and make one.
Eventually I came across Torben Mogensen's planet program (planet.exe on Windows). It was rather eye-opening because the program works on an entire spherical planet at once instead of treating the world as just another flat image.
The underlying terrain generator uses recursive tetrahedral subdivision to produce planetary terrain, and it can render the generated planet using many different cartographic projections. That became the technical foundation from which FPP originally grew. We later ported the original code to C# and gradually modernized and extended it.
The Start
The first practical problem was obvious: planet.exe is essentially a command-line program, and custom maps are represented through text-based input.
That is powerful if you already know exactly what you want to type, but not particularly convenient if you are trying to draw a world.
Before FPP, I even made several small command-line utilities for operations such as moving and scaling cells around. It technically worked, but authoring by repeatedly modifying parameters, rendering an image, looking at the result, and trying again was painfully inefficient.
So the first major goal became exposing all of this through a much more usable graphical interface.
That took much longer than expected.
The original code is quite old and was never designed with this kind of interactive editing workflow in mind. Adding a GUI was therefore not simply a matter of putting some buttons around it. Rendering, state management, editing, visualization, save files, projections, cross-platform support, and eventually performance all had to be integrated around the original generator.
Version 1.0 was really the beginning of that process rather than its end.
Over time we added higher-resolution authoring, more output options, brushes, polygon editing, region selection, map themes, improved rendering controls, and substantial performance work. By v1.4, techniques we had been developing for Divooka - erosion, terrain processing, procedural coloring, texturing, and rendering - also started finding their way back into FPP.
The Road Map
Once you start thinking seriously about authoring an entire planet, a lot of other problems immediately appear.
Some of the major ones are:
- Location and region management
- Local and regional maps
- Countries, cultures, biomes, settlements, etc.
- Different levels of detail
- Map rendering and map serving
- Exporting the same world into other tools and applications
This is why I don't really think of FPP as only a procedural map generator.
A nice-looking map is important, of course. But a fictional world can easily contain thousands of named places and many completely different scales of information. A mountain range visible on a world map may contain hundreds of valleys, rivers, lakes, roads, towns, and individual terrain features that should not even exist at the resolution of the original world map.
That creates an interesting authoring problem.
A single giant bitmap is clearly not the answer. At the same time, splitting everything into unrelated maps loses the fact that they all belong to the same world.
Our original public roadmap already described Version 2 as Advanced World Editing, beginning with location management, followed eventually by better brushes, color control, biome editing, 3D worlds, roads, and cities. The exact implementation has changed quite a lot since that roadmap was written, but the overall direction has not.
The important part is that FPP needs to gradually move from "a program that generates a picture of a planet" toward "a program that understands the things making up that planet."
Feedback and Improvements
There haven't been many direct comments on the Steam community page so far. FPP is still a small and fairly niche product.
Refund information, however, gives us another source of feedback, and the pattern is fairly understandable: people want more power, more detailed editing, and more features.
None of those are particularly surprising.
They correspond closely to limitations we were already aware of in Version 1.x. FPP became quite good at quickly establishing the large-scale shape of a planet, but there is a substantial gap between sketching continents and actually authoring the world inside those continents.
That feedback has helped us decide which parts of the longer-term roadmap should move closer to the front.
Version 2.0
There are three big areas we want to address at the beginning of Version 2.0:
- World regions
- A new custom spherical tetrahedral-subdivision system with real-world physical units
- Major mapping, editing, theming, and rendering improvements
The first one is perhaps the most important structurally.
Regions give us a way to start treating parts of the world as actual objects rather than just pixels or height values. Once regions exist properly, a lot of other ideas become much easier to build around them: locations, countries, biome areas, local maps, selections, metadata, exports, and eventually much more detailed world-building information.
The second area goes much deeper into FPP's original foundation.
The new subdivision system is also closely tied to another important change in 2.0: the metric system. FPP now operates using real physical units, with distances and elevations represented in meters rather than abstract map values. A planet can have an Earth-scale radius, mountains can genuinely be several kilometres high, and distances between locations can be measured and discussed precisely.
This sounds like a relatively small change, but it makes world-building much more practical. Terrain, regions, local maps, roads, settlements, and eventually buildings can all exist within the same physical frame of reference instead of relying on arbitrary scales that change depending on context.
The tetrahedral subdivision approach has served FPP very well, but we are now experimenting with our own spherical subdivision implementation and data structures. Having control over this level of the system lets us build that real-world scale directly into the geometry while also making it easier to integrate editing, generation, resolution changes, region handling, and future algorithms without constantly working around assumptions inherited from the original renderer.
And finally there is everything users actually interact with every day: mapping, editing, theming, and rendering.
Version 1.x accumulated many useful features, sometimes rather experimentally. Version 2 gives us a chance to reorganize some of those ideas around a more coherent model instead of continuously extending what was originally a relatively simple world-map painter.
These three areas should provide a much better foundation for extending FPP going forward.
The W2B Project
A surprisingly useful side project in all of this has been World to Beyond, or W2B.
It was originally proposed mostly out of curiosity.
I sometimes play Beyond All Reason with my friend. Well, nowadays he is so good - even though I was the one who first got him into the game - that he no longer plays with me 😟.
At some point he looked at FPP and said that its maps kind of looked like BAR maps, so: couldn't FPP make one?
Visually, the answer seemed like it should be "yes."
Technically, of course, it was considerably more complicated.
BAR uses the Spring RTS engine, and producing an actual playable map means much more than exporting a nice-looking heightmap. Terrain needs to work from a gameplay perspective. You have textures, metal distribution, grass, water, features, map metadata, engine-specific formats, reachability, and all kinds of details that don't really matter when the final output is only an image.
So we made a first attempt, but never really published much around it.
People on Discord also quickly pointed out some obvious weaknesses, particularly the lack of convincing erosion and proper texturing.
Conveniently, those were exactly the kinds of problems we had independently started working on in Divooka.
Over the past year, our terrain work in Divooka has expanded from basic noise generation into erosion, hydrology analysis, masks, terrain coloration, texturing, and eventually PBR terrain rendering. FPP has already started benefiting from some of that work.
So when we returned to W2B, we were in a rather different position.
The new W2B has now been rewritten from scratch. Earlier prototypes required users to provide a template extracted from an existing map, which was awkward both technically and from a redistribution/licensing perspective. The current implementation writes the core Spring map files - .smf, .smt, and mapinfo.lua - itself.
The authoring process has also grown into several distinct stages: source terrain, terrain setup, metal, grass, water, features, and final output. In other words, it is slowly becoming an actual map-making pipeline rather than an FPP export button.
And this experiment is useful for FPP itself.
It forces us to deal with questions that don't appear when creating a world map purely for viewing: Is this terrain navigable? What happens when we look much closer? Where does vegetation belong? How do large-scale shapes survive when converted into local terrain? How should a procedural world turn into something another application can actually use?
Those questions are very relevant to where we want Fantasy Planet Painter to go.
With all the work that has gone into FPP, Divooka, procedural terrain generation, and the first W2B experiment, we are much better equipped this time around.
And the new W2B is already much more powerful - and, importantly, much prettier - than the original attempt.
Going Forward
Fantasy Planet Painter started from a relatively simple problem: I wanted a convenient way to draw a fictional world map.
That problem turned out to contain a surprisingly large number of smaller problems.
Some are mathematical. Some are GIS problems. Some are rendering problems. Some are UI problems. And increasingly, some are really data-modeling problems: how do you represent an entire fictional world in a way that remains editable from the scale of a planet down to individual regions - and where those scales correspond to actual physical measurements?
With 2.0, an Earth-sized world is actually Earth-sized, mountains can be described in kilometres, and distances between places have a concrete meaning. That gives the rest of the world-building system a much more practical foundation.
Version 1.x gave us a functional planet painter.
Version 2.0 is where we start taking the "world-building" part much more seriously.
There is still a lot to figure out, and some of the ideas described here will certainly change as we implement them. But the pieces developed over the past year - especially the work on terrain generation in Divooka and experiments such as World to Beyond - are starting to connect together rather nicely.
We will share more as 2.0 takes shape.
References