Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

Thread: Climatic Generation tool

  1. #11
    Administrator waldronate's Avatar
    Join Date
    Mar 2007
    Location
    The High Desert
    Posts
    3,607

    Default

    Assuming that you want to use a simple raster grid solver, surface currents can (to a first approximation) be calculated as the gradient of a distance field calculated from sea portion of the altitude field after a bit of blob-finding for large, deep-ocean areas. Clockwise gradient above the equator, counter-clockwise below. I recommend using an equal-area map projection for the calculations, but connectivity is a tough one for most projections. Note that I say "to a first approximation", because it doesn't account for things like splitting or merging currents. You might be able to feed the simple vector field above into something like a stable fluid simulator, but I suspect that it won't be stable long.
    Air currents are approximately the same, but you need to take into account the ITCZ and summer highs vs. winter lows. For moving heat, you need to have a sea<->air and land<->air interchange rates. For moving moisture (rain), the air parcels need to charge over water at a rate dependent on temperature and humidity, and discharge over land at a rate dependent on biome (humidity) and tempearture (including drops due to altitude).
    If you're using something like a Delaunay graph through points distributed worldwide, then I'm not sure that I can offer much in the way of suggestions except distance from shore and gradient of that distance. It's the same idea as above, but I'm not sure how to go about solving the distances easily.
    All of the heuristics aren't needed with detailed fluid sims drive by asymmetric solar heating and a spinning globe, but that's been pretty ugly historically. It might be tractable (at least coarsely) on some of the larger variants of today's systems. I've found that the choice of data representation is the hard part.

  2. #12

    Default

    I had moved the conversation to PM but waldronate correctly pointed out that it's likely still of value for everyone to see here. I'll post our latest exchange below.


    Quote Originally Posted by waldronate
    Quote Originally Posted by antillies
    I'll be the first to admit that I'm more of a hobbyist programmer, not so much a professional like yourself, so some of the math terms went a bit over my head. Am I correct in understanding though your idea is not to "trace" currents, but to identify what portions of what coastlines would be affected by currents and then go from there (based on distance from the ocean, like you said)? If so, I'm glad, because it's one of the approaches I've been mulling over. Frankly, I don't really even care about displaying the currents since it's an intermediary step that ultimately is more illustrative than functional (though still interesting when it comes to world-building).

    Would you mind expanding, however, on what you mean by "simple raster grid solver"? Do you mean simply computing values based one or more pixel grids?

    Would you also mind if I ran what I think would be my general approach for this past you?
    1. Find and eliminate blobs below a certain threshold to make sure we are only dealing with continents.
    2. For each remaining blob, identify the coasts (possibly with edge tracing, possibly with distance transform).
    3. Isolate coastlines that fall within specific latitudinal ranges (where currents would flow).
    4. For these remaining coastline segments, use their position on their continent (east, west, etc.) to determine the type of current that would affect it (hot, cold).

    I realize it's very simplistic, but a more robust simulation is outside my ability (and available time), plus I don't really think one is needed for the more generalized approach most of us are hoping to take.

    Thank you in advance for reading over the above, if you have the willingness and chance. I appreciate getting the perspective of someone who's made software in the world-building area.
    A grid solver in this case is basically just working with images (pixel grids). Those images might have vectors at each point (for example: a vector of red, green, blue, and opacity at each point for common color images or something like an XYZ direction vector for traditional vector fields) or simple scalar values (for example, a grayscale image interpreted as height values).

    I suggested using a distance transform because they are fairly common tools out there these days and it's fairly simple to roll your own if not. Once you have a distance field, it lets you do lots of useful things. By finding the steepest direction downward at each point, you have the direction in which things move out of the distance field. At right angles to that downward direction left or right (counterclockwise or clockwise) would be the direction of an ocean current in the northern and southern hemispheres. You'd need to separate the major ocean areas and put a slice across the equator to get things moving correctly across the equator, but that should be fairly simple. Getting good blobs to start with is the hard part, but you can usually get that with a blur and a threshold (sometimes a few in sequence).

    Edge tracing as you've described is probably a workable option if you're only interested in the one or two pixel distance along the coasts and are applying lots of simplifications like assuming earth-like worlds.

    What I was describing was a quick way to initialize wind and water flows for what would be akin to a cellular automaton system. For each cell, quantities like terrain height, temperature, amount of water in the cell, and so on are kept and rules based on direction of wind and water flow move humidity and temperature to adjacent cells at each time step. Steps repeat, with the time step doing things like controlling the winter-summer cycles (basically the direction of axial tilt with respect to the sun). Iterating this sort of system to get a semi-stable situation is what would take a huge amount of computational power and some clever data structures.



    Waldronate, I have a distance transform based on a general world map from some previous work (below).

    transformedOceanMap.png

    Do I understand correctly that when you say, "[b]y finding the steepest direction downward at each point, you have the direction in which things move out of the distance field. At right angles to that downward direction left or right (counterclockwise or clockwise) would be the direction of an ocean current in the northern and southern hemispheres[,]" you mean that if we follow the distance transform out X pixels from the furthest edge at each point, we'd essentially create an "outline" of the coastline, and thus the path a current might take? Something like the below?

    levelMap25.png

    It's obviously rough but just wanted to see if I was understanding your meaning.

  3. #13
    Administrator waldronate's Avatar
    Join Date
    Mar 2007
    Location
    The High Desert
    Posts
    3,607

    Default

    I'm not sure what stage you're processing here. It looks like the blob-finding stage. The distance metric image shows where the ocean blobs would be (the high parts). Simplifying the coastlines is a good idea to avoid things like the big block around Hawaii that's caused by the little island breaking the topology. A good way to simplify the coastlines is to blur the basic land mask image and then convert the image back to two colors to get the mask back. Another useful simplification is to treat the land masses as including their continental shelves, because currents tend not to push up into the shallows of the ocean too much. The simpler you make your coastline parts before you calculate the distance image, the simpler your distance image will be and the less likely you'll have weird holes like Hawaii.

    The blob-finding idea is to take the distance field, ideally from a simplified world image, put in latitude barriers (single pixel lines of land across the map) to separate the gyres, and only then calculate the distance field. You'll get nice blobs for oceans. The centers of the gyres will be approximately the high points of your ocean distance field. You can do the same sort of thing to get the continental highs and lows by season, but you'd need to calculate the heat equator as well, if I recall correctly.

    It looks like you're using Hammer as your projection here, so there would need to be a barrier at the edge of the world as well as having the latitude cell barriers follow the curve. The laziest way I've found to avoid the edges and borders problems is to use a projection with a rectangular shape and flat parallels (Equirectangular works, but it has other undesirable properties) and repeat half of the world on each side, so that the world tiles seamlessly across the horizontal edges. The topology of the middle part will be pretty much correct, but nothing's going to be perfect.

    All of that blob finding was to get a distance field that roughly approximates the major ocean gyres (and continental cells if you calculated those). If you look at the latitude of a point (to determine the cell #) and the direction of the distance field at the point, it will tell you if the nearby coast is the east or west coast (it also tells you the distance to the simplified coast, of course). This information can be used to calculate simple approximations for ocean temperature which feeds nicely into local continental biomes. You can also run a few particles downhill on the distance field over the ocean to pick up moisture and then keep going over land to drop moisture (they will get directed by the air currents around seasonal continental highs and lows). There are simple models that are just a lookup of average annual rainfall and temperature, and others that need to look at each season.

  4. #14
    Professional Artist Naima's Avatar
    Join Date
    Mar 2010
    Location
    Italy
    Posts
    1,583

    Default

    Quote Originally Posted by antillies View Post
    This is something I've actually been working on since 2019, in bits and spurts. The hardest part for me has been - and the stage that I've been stuck on - is how to generate currents. Most of the approaches I've tried are generalized and simplified (I'm not looking to make the tool overly robust in this particular area) but it seems I always run into exceptions that prevent my solutions from working. For example, I don't have any trouble placing the equatorial currents and "tracing" generally where the split currents go once the equatorials reach the coast, but in the instance of the current that travels south on the eastern coast of South America, I don't know how to make it split to both continue on eastward (towards Australia) and veer northward toward the western coast of Africa.

    Naima, waldronate, Azelor, and Charerg: If any of you (or anyone, really) would have suggestions for a generalized approach to place currents, I would very much appreciate any input.

    I have most things figured out well enough that if I can get this part of my tool implemented, I should be able to move quickly through the rest. Ultimately, I'd like the tool (which is currently nameless) to be able to take a very limited set of inputs from the user (including a monochrome land and ocean map) and return a map that is marked with climates, similar to the end results in Azelor's Köppen–Geiger thread.

    This is something that's been rolling around in my head for such a long time I'd love to make a breakthrough on it.
    are you programming in c++? have you made vectors over the sphere surface that slowly turn toward a common direction based on the distance from center of the sphere?

  5. #15
    Administrator Redrobes's Avatar
    Join Date
    Dec 2007
    Location
    England
    Posts
    7,245
    Blog Entries
    8

    Default

    Just a question I dont know the answer to but maybe someone can give some idea whether it might be correct or not... would Navier Stokes work at the sort of planetary scales ? I do know that Navier Stokes is based on incompressability of fluids with movements dictated by newtons motion laws all wrapped up in those complicated equations. But it seems to me that you would have a hard time calculating currents and gyres and so forth using a pixel grid basis.

    I did my GeoTerSys model using pixel grids and I think it works ok when you have rain fall from the sky and small amounts of water are washing down height maps and eroding the landscape. I think this is workable because each bit of water is mostly independent of what other bits of water is doing because its more about the terrain its flowing over. Where it breaks down more is on rivers, especially where they bend and meander, because the flow out of a part of river determines whats going on upstream because of the pressure differences and these pressure zones and then fluid speed is what causes erosion on the banks and then forms the meandering and oxbow lakes etc. All of which are not very present in my app nor any other that I have seen. If Navier Stokes had been used on the river flow then it would have produced a more accurate fluid flow, pushed up the water speed on the outsides of bends, and probably got better river bank erosion and therefore river location. Most of the rivers I was modelling were at a scale where they were only a few pixels wide and therefore did not have enough data or volume to have made using Navier Stokes modelling to give any kind of reasonable results anyway.

    But when thinking planetary scale, the seas are not a few pixels wide any more and it would seem to me that what is happening at one zone in the oceans drastically affects whats going on in another quite far away. The water in a pixel cell is not at all independent any more. This would also be true of atmopspheric fluids like jet streams etc. Since ocean currents directly affect atmospheric currents and the atmospheric current directly affect rain and the other important parts of climate modelling then I would have thought that its important to consider using something like Navier Stokes to model the flow going on. I think this problem is really difficult indeed and I would assume that its the one being solved by the meteorological institutes around the world on their super computers to give us the weather reports.

    So in some magical world where anything goes its all ok but if modelling such as to give earth climates then I am not sure there can be a simplified algorithm to roughly give the right answer. I think the complexity is required to be considered / computed to get anything approaching a realistic answer.

  6. #16
    Administrator waldronate's Avatar
    Join Date
    Mar 2007
    Location
    The High Desert
    Posts
    3,607

    Default

    You do need a fluid solver at some level, but the fancy stable fluids sims that you see running on GPUs don't have enough resolution to capture the really important elements of the atmosphere/oceans that we see and they are defined in a nice linear space, for the most part. The big drivers of air/ocean circulation here on Earth are differential heating of the sphere and rotation of the sphere. The emergent effects that are really important for local climates like the Gulf Stream and Deep Ocean Circulation don't show up until you start modeling at high resolution and multiple vertical layers in both air and sea.
    I am told that some pretty big weather models will run on a PC these days, but they are fairly slow. Weather is not quite the same thing as climate, but if you run weather long enough (and if the sim doesn't start to go stupid), you'll eventually be able to get enough information to generate climate. What I described above was some heuristics that could work quickly on a basic grid and cast in terms of simple graphics primitives that I already have available to me. I was also looking for something that can operate as a pretty simple cellular automaton. If you're sticking to a pure Earth-style model and not wanting a general model, then the latitude bands of Hadley and Ferrel circulation are roughly fixed. That gets you ballpark moisture amounts and mostly what's left is heat transport and inland-coast distances. If I had a few days, I'd code up something based on pure heuristics, but that doesn't seem likely any time soon.

  7. #17
    Professional Artist Naima's Avatar
    Join Date
    Mar 2010
    Location
    Italy
    Posts
    1,583

    Default

    Winds and coriolis affect sea currents , those with geography influence moisture , this with temperature influence climates , this would be enough I guess for most uses, for further detailing inclination can influence seasons and so temperature cycles and relative climates, the moisture can change too according to rainshadows or pressure zones.

  8. #18

    Default

    I recently figured out how to install and run ExoPlaSim, a middle-range research climate model that's just about in reach for home computers to run (full process here https://worldbuildingpasta.blogspot....h-part-vi.html) but it's hardly a quick or easy process.

    Regarding some of the other programs mentioned here:

    Clima-Sim does account for orography, but crucially it doesn't model precipitation. It's also not terribly flexible about the external conditions (orbit, rotation) that it'll allow, and it'll basically break if you put up eccentricity or axial tilt too high. (even for Earth's conditions it deviates from actual data by up to 15 C in some areas for lack of an ocean current model)

    The space calc one I wouldn't really call a model as such, more an attempt to build something that draws climate maps that coincidentally look Earth's. If you got it to account for seasons better it could probably get pretty good at that, but wouldn't have much flexibility for different parameters and you couldn't even guarantee it would work right for different topography.

    Lastly, I know the Song of the Eons devs are working on some kind of machine learning model to try to replicate climate models, but that'll take a while, I imagine, and it doesn't exactly fill me with confidence that they put out a public call on reddit for people to submit their own maps to train it.

    Regarding projections, pretty much every formal model I've seen uses a rectangular one split into a grid of cells, with the internal algorithms adjusted to account for the different areas and orientation of each latitudinal band of cells. Clima-sim does adjust the latitudinal width of cells to at least conserve the area of cells, but that doesn't seem to be too common.

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •