Springs and valleys

It's been quite a while since the last post - real life has unfortunately rather dominated things recently and will probably continue to do so for quite a while. But I'm still tinkering with the planets when I can.

I've been working on refining the river simulation at the regional level, in particular making springs a bit more realistic. These are little rivers that flow into the main rivers, delivering the additional flow that the main rivers pick up in each tile. Previously, they were just random. But I thought it would make more sense if I could space them out a little so they flow into the main rivers in a more realistic way. To do this, I create imaginary zones around the rivers and start streams at the edges of these zones, spaced a bit from each other. That looks something like this:

All the rivers and springs here are shown the same shade, so it looks a bit overwhelming, but you can see in the more isolated sections how the springs flows nicely into their rivers. (The pink bit is a river valley.)

I've also enhanced the way that all rivers, including springs, carve the land beneath them, especially around mountains. That gives us pleasingly rugged landscapes like this:

There is still a lot of ironing out to do with this. I am thinking of implementing a simple hydrolic erosion system so that the shapes of the mountains interact more meaningfully with the valleys carved out by the rivers. That might mean I can make the mountains themselves a bit simpler, as the rivers will be doing more of the work of making the highland areas crinklier.

Rivers again

Just a quick update to show that things are moving. The process of converting all of the regional-level generation to the new spherical planets continues, though a lot more slowly than I'd like. This is partly because of dealing with the roundness, but also because I'm trying to improve the routines as I go and (crucially) speed them up wherever possible. Speed is more important than it was with the old version, because the engine needs to be able to generate and place regional areas on the globe in real-time as the user moves around.

Anyway, I've more or less got rivers and lakes working, which has been as difficult as ever. But I think the rivers are looking quite reasonable:

I've also found a way to do rift lakes a lot more simply than before. I've adapted my approach to non-rift large lakes. The idea is this: create an elevation map where all the seed heights (at the corners of the tiles) are above a certain elevation, and where all points where a large river runs through what will be rift lakes are well below that elevation. Diamond-square it, and then treat all areas that end up below that elevation as templates for rift lakes. That gives results like this:

As always, there are still lots of bugs to iron out. And I haven't been able to get deltas to work at all on the spherical maps, so I'm going to have to rethink those. But it's coming on!

Improving river simulation

I'm continuing with the process of converting the old region-drawing functions into the new globular context, and refactoring and improving them where possible.

While doing this I decided that the old way of tracking river flow wasn't accurate enough. At the moment, UW stores the January and July temperature and rainfall for every point on the global map. When needed, it can calculate the temperature and rainfall for other months by extrapolating them from that stored information (along with other relevant information such as the planet's obliquity, eccentricity, and so on). So far I've been doing the same thing with river flow: for every global cell, the program stores how much water is flowing in January and in July. The problem is that it's not possible to extrapolate the information for the other months from this information. This is because river flow is determined by more than just information about that point on the map. The water comes from elsewhere, and quite different climactic conditions might prevail in those other places. So we can't say (for example) that because there's less rain in March than in October there should be less river flow, because perhaps that isn't true of the place where most of the water is coming from.

So I've updated the program to track and store river flow for all twelve months. When the rivers are calculated, it goes through every cell on the globe and calculates how much water will be flowing for every month, and then adds that, month by month, to every downstream cell from that point. This means that the variation in flow can be shown quite accurately.

Here, for example, is a world with a very long river that travels through mostly desert and tundra:

(I've removed the clouds so it's easier to see.)

The information in the graphs to the top right are for a point on this river roughly in the middle of the image, where it passes through a pretty cold desert. There's significant variation in temperature, and no precipitation at all, but the river has a roughly constant flow throughout the year because its sources, far to the north, are in places with fairly even rainfall throughout the year.

Now compare this image:

You can see another large river which joins the first one near its southernmost point, in a darker area that indicates extensive wetlands. This river has its sources further south in the tundra and arctic mountains to the bottom right of the image. The graphs here are for a point on this new river near where it joins the first one. The temperatures and rainfall are similar to the previous one, but here you can see extreme variation in river flow: none at all for much of the year, and then a deluge in the brief summer as the snow melts in the sources of the river far to the southeast.

And, finally, we have this image:

This shows information for a point on the river near its mouth. Here, there is a bit more rainfall (not much!), but you can see that the variation in flow of the river follows an opposite pattern. For most of the year the river is moderately sized. This is the same flow that we saw in the first image. Then in the summer the river floods extensively, thanks to the meltwater coming from the second river that joined this one.

Since UW now displays variation in the seasons, the plan is that the sizes of rivers at the regional level will be shown dynamically, so you can see them swell and shrink as you move from month to month. Now that the program is storing flow information for every month, rivers like the one above should show this kind of variation in a way that adds a bit of believability to the simulation.

Zoom!

It's been quite a while since the last update. This is partly because there has been even more RL than usual to deal with, and partly because creating regional-level detail on spherical planets is hard!

To recap, in the previous version of Undiscovered Worlds you could view a world map, and then click on a point on that map to bring up a regional map, in much higher detail. The program creates the regional map afresh every time you visit it, but procedurally, so it's always the same. This creates the illusion of a vast and highly detailed world. But of course only one regional map is displayed at any time.

With the new version, we want to display regional maps directly on the globe. So instead of having separate global and regional displays, we just have a single display that shows the global images if you're far away and the regional ones if you're zoomed in, fading neatly between them. This means displaying multiple regional images at a time, since the user might be only halfway zoomed in and therefore able to see several at once. It also means being able to dynamically create the regional images as the user moves around, ideally without any gaps or pauses.

Well, I've got the basics of the system up and running. Although the new regions are 2D, like the old ones, it's still quite a lot of work to translate the generation functions given that they're now extrapolating information from a 3D global map rather than a 2D one. Along the way I'm trying to refactor the functions to be as efficient as possible, since speed is now even more important than it was before. So far I've done just the basic elevation with mountains, and rainfall and temperature. No lakes  or rivers or anything else fancy yet, but it's enough to give a pretty good idea of how it all works:

That's several regional areas all being displayed at once. Here's a video of the zoom (though it's a bit blurry!):

There are still a lot of bugs, as well as all of the other features to add, so it will be a while before this is done, but progress is being made!

Alpha update

Since the program is now running in a mostly stable way, I decided this might be a good time to update the code on github. It's definitely not ready for a proper release so I've not uploaded a built executable, but some people might like to have a look at how it's working. So consider this a sort of alpha preview.

It's uploaded here. The previous version of Undiscovered Worlds, with flat maps, is now Undiscovered Worlds Classic and can be found here, including the executable and instructions.

You don't get the jazzed-up GUI though, because those are changes I've made directly to the ImGui code, so I can't really upload them as part of this project.

Parrots everywhere

My spherical worlds are mostly working pretty well now (although for some reason I haven't been able to make river deltas work on them - I don't know why). So it's time to try to get regional-level maps working with these worlds.

As I've explained before, this will work differently from the original, flat-world version of UW. In that version you could view the global map, select a point on it, and zoom in to see the regional map of that part of the world, in a separate screen. But this wouldn't work very well for a spherical world, where we will instead display regional maps directly on the globe itself. As you zoom in, the details of the regional maps will become visible. So it should all operate seamlessly. That's the theory anyway!

This means we need the ability to generate and display multiple regional maps at once. It's not possible to store regional-scale information for the entire planet, since a large world has 16 x 16 regions on each face, making 1,536 regions in all. We can store only a fraction of these at once. So what we need is a system whereby the program can dynamically create new regions as the user moves around the world, deleting them when they're no longer visible.

After many false starts I've got the basics of this system up and running. We have a stable of threads dedicated to generating regions and drawing their maps. As the user views the globe, these threads work in the background to create regions roughly where the user is looking, with unused ones being discarded. Meanwhile, the main thread displays the regional textures where they exist, and the lower-resolution global textures where they do not. This way, if the user is zoomed in enough to make out details at the regional scale, they should be able to see only regional textures visible on the screen.

Now I haven't yet started translating the actual region creation functions so that they work with spherical worlds, because I wanted to get this system up and running first and then plug in the region creation functions as I convert them. So at the moment the region creating threads are just applying a placeholder texture (of parrots, because why not). But here is a pretty rough-and-ready (and somewhat nausea-inducing) video showing the system in action.

As you can see, as we move around the planet (or rotate the planet itself) the more distant regions are deleted and replaced with closer ones. If you zoom in closely, it creates the illusion that the entire world is covered with nothing but parrot images, because you can't see the edge of the patch of textures.

Now all I need to do is to convert the existing region-creation functions from the old version of UW. For the most part this should (I hope) involve changing them so they take their raw data from the spherical world object instead of a flat one. This will be tricky at the edges of faces, because the regions as generated are a bit larger than what you see. This is because some elements of the tiles that compose the regions overlap from tile to tile, so when we generate a region we need to generate the tiles along the edges of its neighbouring regions, in case anything from them overlaps onto our region. In a flat world this is fine, but here we're going to have regions along the edges of faces of the cubesphere, which means we have to take into account the fact that tiles from the next face along might be rotated relative to the active face, and that complicates matters.

That probably makes very little sense. Still, I'm glad to have the framework for regions set up now, so I can focus on getting back to map generation...

Sprucing up

My plan to create, replace, and delete regional maps on the fly means I need to use multi-threading, where a program basically splits itself into multiple concurrent programs. This is so that Undiscovered Worlds can get on with generating regional terrain while the user is moving around and viewing the world. I've never done this before, so I've been learning how, and fortunately it's not too hard, at least in principle. To practise, I've added a progress bar for world creation - one thread creates the world while another updates the progress bar - and it works quite nicely.

Adding the progress bar made me think again about the GUI. I'm using Dear ImGui, which is a very widely used library, but mostly for internal use rather than user-facing interfaces, because it's pretty simple to incorporate into one's code but doesn't look very fancy. (Also it's easily recognisable!) I certainly don't want to change to a different GUI again, but I thought it would be nice to try to change the appearance of Dear ImGui a little to make it a bit more distinctive and attractive.

So I've had a go at tinkering with the code of Dear ImGui. I've been shamelessly copying the style of NanoGUI, another library that I was using for a while in an earlier version of UW, but abandoned as it proved too tricky to port to Windows. My very rough hacks can't really reproduce its appearance, but I think the results look quite nice:

Hopefully it doesn't look quite so generic now. There is still some tweaking to be done, of course, but the next focus is on getting some version of the regional detail up and running.

Global details

It's time to think about adding detail to the planets. The ultimate aim is to create regional maps similar to those in the old version of Undiscovered Worlds, but wrapped onto the sphere. My initial thought was to generate an entire globe's worth of these while the user is looking at the globe, adding them on as they are generated - but that is too much detail to hold in memory at once. We need, then, a more dynamic system, which can generate new regional maps and delete old ones as the user moves around the globe, so we only store the ones we actually need.

This creates a problem though. Here again is how the cubesphere is constructed:

If this is a large world, then each of the small panels corresponds to a single regional map. (With small or medium-sized worlds, it's still constructed from the same number of panels, but a single regional map would be spread over several panels - four each for a medium-sized world, or sixteen for a small one.) So as the user moves around the globe, each panel will display either its portion of the global map texture or its own regional map, depending on how close it is to the viewer.

Clearly, for this to work well, we want to display regional maps only when they are pretty close to the viewer. Otherwise we would have to be generating masses of them every time the user scrolls around even a little bit.

The problem is that the global texture looks quite blocky quite quickly as you zoom in. It's just not highly detailed enough to let us get away with generating only very close regions.

The solution is to make the global texture more detailed. Rather than making the world object (that is, the data structure that holds all the information about the world) more detailed itself (as I did once before), I've created a much simpler data structure that only holds information needed to generate the map textures - basically elevation, temperature, rainfall, river flow, and one or two other things. Since it's much simpler than the "real" world object, it can be four times as detailed without taking up too much memory. Once the world is generated, we populate this "simple world" on the basis of the "real" one, mostly using a simple diamond-square algorithm similar to the one used for regional maps. Mountain ranges and rivers are drawn more directly on, to maintain their detail. Then we just use that to create the main world textures. Since the "simple world" is only used for generating those textures, and doesn't contain information that the user can access otherwise, we don't have to worry about details such as carving out river valleys and the like, so it's very quick to generate.

The "simple world" has a resolution of 4x4 the "real" world, which means that the global textures can now be 16 times as detailed. This only applies to the main textures, showing the world pseudo-realistically - the other textures, showing information such as elevation, temperature, etc., remain in the old resolution. So for example, here are some shots of a single area showing elevation, rivers, and basic terrain colours, all in the "true" resolution:

And here is the same area with the higher-detailed texture plus fancy shaders (and clouds dialled right down so you can see the details more clearly):

It's a pretty simple technique, and there are certainly a fair few wrinkles still to be ironed out, but I think the initial results are quite decent:

With this in place, we can now zoom in a fair way before the map looks too blocky. That means that, in theory, we can generate regional-scale maps and apply them to the appropriate parts of the globe only when the view is quite close - so we don't need to display many of them at the same time. Whether it will actually work like that, though, remains to be seen!

Stars and suns

I've been doing a fair bit of tinkering with the model, focusing on improving the algorithms connected with monthly changes. Seasonal temperatures and rainfall are now more realistic (more or less), and so is river flow. You can also pull up monthly river flow charts alongside those for temperatures and rainfall, to get a better idea of seasonal changes for any point on the globe.

Alongside this, I've removed some bugs with specular maps (rivers now reflect sunlight correctly) and improved the appearance of clouds.

After doing all that, I decided that my planets looked a little lonely floating in the void, so I've added procedurally generated starfields, galactic dust and nebulae, and some bloom effects on the sun, as well as simple lens flares. All of these can be adjusted in the settings. I wrote all the shaders from scratch, as I couldn't find anything quite like what I wanted. This was a pretty tough learning curve, but I'm glad to have managed it and am quite pleased with the final effects.

Here are a few shots showing how it looks now:

All of this means I've more or less run out of things to do before tackling the next big thing, which is adapting the regional map model to the new spherical layout. As I've mentioned before, this is inherently tricky. The ideal solution, if I can manage it, is to generate regional maps on the fly while the globe is displayed, and display them on the globe in the appropriate places as they're generated, if it's zoomed in enough to make it worthwhile. So this would involve keeping a lot of regional maps in memory at the same time, with hopefully a system intelligent enough to generate precisely the ones that are needed, depending on where the user is looking, and deleting the ones that aren't.

That's the plan anyway! If I can't get that to work then I may have to go for a less ambitious system where the regional maps are displayed in a different screen altogether, as with the 2D version.

The changing of the seasons

Translating my simulations into a spherical context has thrown up an issue that I've had at the back of my mind for a while: how to represent changes over an annual cycle? The colours on relief maps that Undiscovered Worlds creates are determined by rainfall, temperature, and so on, but it always draws the maps on the basis of annual averages. But the program does track variations in these things from month to month. So I've thought for some time it would be interesting to add the ability to generate monthly maps, so you could see, for example, the advance and retreat of the ice caps over the course of a year.

Now that I'm dealing with properly spherical worlds rather than flat maps, doing something about this has rather been forced upon me, because if I'm displaying the world as a sphere in space, with light coming from a particular direction, I need to make sure that it's the correct direction, based on the planet's orbital characteristics. But that will vary throughout the year. In other words, to display the world at all - at least in the pseudo-realistic fashion that I've been developing - I have to make a decision about what time of year it is. And that suggests (a) that the features on the world, such as sea ice, should reflect that time of year, and (b) that it should be possible to change the time of year and see how these things change.

So I've implemented this now. You can change the month, which will affect things such as the sun's angle and distance, the extent of ice on sea and land, how arid or lush the land appears (monsoon areas look desert-like in the dry season and green in the wet season), and even how big rivers are (they swell and dwindle to reflect precipitation, and can also show flooding in times of thaw). Cloud cover can also vary depending on precipitation, although it doesn't change otherwise.

For example, here is a world shown in January:

And here is the same world in July:

You can see how the features have changed to reflect the seasonal changes. Also note that the camera angle remains constant even as the planet shifts relative to the sun - you can set the camera to remain in the same place relative to the planet when making these changes, or you can detach it and watch the planet rotate beneath you.

Here is a more zoomed-in series of shots of another world, showing the changes month-by-month from January to July. I especially like how you can see the snow creeping down the mountains as winter approaches. Notice also how the bit of land in the bottom left-hand corner has a fringe of sea ice around it all year round - this is from the sheltering effect of the land itself, which encourages ice to form in temperatures where it wouldn't be possible in more open ocean. The same effect causes the ice cap to seem to reach up slightly towards the main continent as it moves north in the colder months.

[EDIT] I only realised after posting that the sun here is moving in the wrong direction - shining more directly on this hemisphere in winter! This is a bug only affecting some planets, which is why I hadn't noticed it - I've now corrected it (I think).

As that indicates, there are still quite a lot of bugs to sort out with this, but the basic functionality is working reasonably well and I think it adds a nicely dynamic element to the worlds, which makes them feel that much more believable.

Atmospheres

When I started this project, I didn't think I'd be spending much time simulating air, but here we are. My planets now have atmospheres:

I looked at a number of atmosphere shaders but couldn't find one that worked well with what I already had, so I wrote my own from scratch. As with most of what Undiscovered Worlds does, it aims for superficial believability rather than accuracy, but I think it looks reasonably decent. It doesn't actually calculate Rayleigh scattering and the like, but it pretends that it does. You can adjust atmospheric thickness, colour, specularity, etc. in the appearance settings.

The clouds are formed quite simply:

(1) Several fractal maps with different levels of detail are made and then combined. Then these are converted to the range -1 to +1, and then turned into their absolute values before being inverted. This gives the effect of wiggly lines. Finally, the resulting map is warped. This gives us the fairly large blobs of cloud with some stringy bits that you can see in the images.

(2) Then, another fractal map is made with a much smaller granularity. A map with larger granularity is used to remove large sections of this. This produces the smaller, puffier-looking areas of cloud.

(3) These two cloud maps are combined using yet another fractal, so that they merge into each other in a varying way.

(4) A simple swirl effect is added in places to give the effect of weather systems. Of course we make sure that these swirl in the correct direction, depending on hemisphere and overall planetary rotation direction.

(5) Clouds are removed in areas of low precipitation, to ensure that you don't get great big weather systems over deserts and the like.

Plus I've reduced the effect of the normal map, and made wetlands and large rivers visible (and specular) from space.

As always, it's not perfect, but I think it's looking reasonably decent. I shall probably continue to tinker with the clouds, but for now I'm happy to move on to the next bit, which will be some boring refactoring. I'm using a lot of three-dimensional vectors now, which are slow, resulting in annoyingly long planetary generation times. So I want to rewrite them all as one-dimensional ones to see if that speeds things up.

(Bonus shot: ocean worlds can now look quite dramatic:)

Shiny!

There's not been much activity here recently, but things have been moving behind the scenes. I've mostly been trying to work out how to improve the visuals for my planets. I was just using OpenGL to display them, and I wrote last time about wondering whether to change to a less low-level approach that might make it easier to get a few nice visual effects in. (I was particularly missing the fake 3D effect of my old maps.) After a lot of time alternating between digging deeper into OpenGL and trying alternatives, I decided to use raylib, which is not an engine so much as a library that keeps things pretty low-level, but without quite as much fuss as doing everything in OpenGL directly. Also it's easy to use ImGui with it, and I wasn't going to redo all the GUI at this stage.

There's still quite a lot of getting one's hands dirty with this. I've spent a lot of time tinkering with shaders, and have managed to generate some fairly simple effects, but I'm quite pleased with them:

Getting the normal map to work properly was very fiddly. For some reason I don't understand (a glitch in my cubesphere object, or a glitch in my shader?) the shadows on the top and bottom faces of the cubesphere vary incorrectly across the faces, even when the normal map is definitely correct. So I had to mess about with my normal map creating routine to vary them in the opposite way, to counteract this effect. It's still not perfect, but it looks mostly OK, so I'm sticking with it for now. It's certainly nice to see shading on my mountains again (even though, at this scale, it's probably too exaggerated).

Next I need to think about how to improve my shader - ideally by adding some basic atmospheric effects, as well as clouds, if possible. And then I'll need to think about how to integrate the regional map level into this system, which is where things will get tricky.

Another decision point

Time (at last) for a new update!

I have, more or less, managed to convert all of my existing terrain and climate routines to work with spherical planets. This has been quite fiddly to do. Some could be converted fairly straightforwardly, while others could not. In some cases I had to rewrite them from scratch, and in extreme cases I had to simply alter them to work with a giant 2D map which subsequently gets wrapped onto the sphere. In some cases I found that the rewritten versions were better than the original - e.g. my continent-generating routines now seem to throw up more varied terrain more often, including archipelagos, meaning that I don't need to use the Aegean-creating function.

I was particularly held up by a subtle but nasty bug in my routines for moving from one point on the sphere to the next, which caused inaccuracies when moving from one face to the next. Much of my time was spent writing workarounds to deal with the effects of this bug until I finally found it, after which I had to go through and remove some of those workarounds.

But it's done! Mostly. All four of the planetary types (small continents, large continents, oceanic, and non-tectonic) can now be in spherical form, and in all three planet sizes too. Most features such as mountains, dunes, lakes, wetlands, craters, etc. are present, as are the variable climates (including exotic climates). There are still some issues. Artefacts occasionally appear at the edges of faces, and occasionally the whole thing crashes. So there's still some work to be done smoothing it all.

Here's a typical continental world, showing some of these features:

Here are a couple of non-tectonic worlds that I thought looked interesting:

Some new terrain features are possible now. For example, rarely, ocean ridges on small worlds can create planet-wrapping archipelagos and islands:

This was unplanned, but I like the effect, so I've left it in as an occasional possibility.

And you can of course view things like rivers on the globe:

- and climate types:

So now there are two problems I need to consider.

First, what engine should I use to display all of this? At the moment I'm just using OpenGL directly. This is fine for displaying simple objects such as the facets of my globe, but doing more elaborate effects is probably beyond my abilities. So far I've not been bothering about this as I wanted to work out whether I could create the terrain etc. of the planets first, and worry about how to display them later. But obviously with this method I can't do things like apply shadows, which means that they don't look as nice as my 2D maps that have the faux shading effect. So I'm wondering whether to use an existing engine such as Irrlicht to render the globe, which might allow me to do more. But then of course I'd have to learn how to do that...

Second, what about the regional maps? As things stand, I haven't implemented them at all yet in this new version. The actual generation of them shouldn't be too tricky. (I know I will regret typing that! But at the moment I think it should be fairly straightforward to convert the existing regional map creation routines to work with the spheres.) The problem is how to display them. One option is to keep the system of a zoomed-in mode, where the region is displayed as a 2D map, just as it is now. That would be very straightforward. But consider again what each region represents:

Each tile here is a region (supposing this is an Earth-sized world). Now suppose we zoom in on one in the middle of the "face" that is facing us. All is fine - it can be displayed in the zoomed-in screen, and we can scroll around to north, south, east, and west. But suppose we keep going north and find ourselves on the "face" that's on the top of the cubesphere. Scrolling around here won't be taking us north, south, east, and west any more, at least not in any consistent way. Suppose we now scroll to the right and go down the "face" to the right of this image. When we started on the first face, the top of the map was pointing to the north. But now it's pointing east. Things get even worse if we try to navigate around one of the points where three "faces" meet.

All of this comes from the fact that the world isn't really a sphere at all, but a cube, and if we display the regional map in 2D form it's going to be very hard to conceal this fact.

So the alternative is not to do it that way at all. Instead, we could allow the user to zoom gradually in on the globe, generating the regional maps as they do so, and then display those maps directly on the globe itself. So as you zoom in on the map you would see the regional-level details popping in once it's close enough.

There are two problems with this. The first is that it's hard! We'd have to be able to generate regional terrain on the fly as the user is moving around the globe, and keep track of which regions have been generated, which ones need to be generated, and be able to paste them onto the right bit of the globe. All of this is theoretically possible but could be a nightmare to implement.

The second problem is that some tiles would get distorted. Look again at the image above, and in particular the regions at the corners. We get away with the distortion at these points at global scale, but I worry that at regional scale it would look pretty bad. Mountains and rivers, in particular, would look unnaturally stretched.

So I'm not sure what to do about this. The next job is therefore probably to convert the regional map generating parts of the program and try pasting the generated maps onto the globe to see how they look.

The blue marble

I've not had much of a chance to post any updates for a while. This is partly because I've been very preoccupied with real-life distractions (finishing the first draft of a book 😱) and partly because the process of translating everything into spherical form is pretty time-consuming.

Much of the difficulty comes from having to deal with multiple coordinate systems at once. The cube-sphere, as described in my last post, is really good for creating terrain that looks reasonably good from all angles, without the distortions you get from just wrapping a rectangle directly onto a sphere. From any given point on the cube-sphere you can easily move to the neighbouring points in a grid fashion, just like on a 2D plane (except at the corners of the faces, where it gets tricky). However, if you want to move due east or west, or north or south, it's much more complicated, because the grid doesn't line up with those directions unless you're right on the equator. To work those out you need to know the longitude and latitude of the points, and converting from cube-sphere coordinates to longitude and latitude (and back) is both fiddly and resource-intensive. And being able to specify directions of this kind is essential for the climate simulation.

Still, I've made some progress. I've converted most of the standard continental terrain generation to the spherical form, and made a good start on the climate model. Temperature and basic rainfall are in place, as well as wind directions and sea ice. Here are some pictures - they are all of the same world, which hopefully gives a sense of how the globe looks from different angles:

Here's the south pole, so you can see it's possible to have polar continents without distortion:

And here are the wind bands (red: westerly; cyan: easterly), which aren't very realistic, but I'm not going to try to change them:

There's a still a lot to do. I've been having a lot of difficulty getting the mountain generation methods to work well with the globe - in fact I've had to create an entirely new way of doing the mountains along continental edges, which is based on the functions I originally created to import user-generated mountain maps. But there's more work to be done with them (the world shown here is one of the most mountainous I've been able to generate, and it still looks very flat). Then I need to add the monsoon routines, before getting to grips with rivers and lakes, which is never much fun. But I think I've reached the point where it looks like converting this whole thing to spherical worlds can actually work, so I'm hoping the final results will be worth the effort...