FT3 and the ToUM: Understanding the Lingo

This question is mostly for Remy, because I know he wrote the Tome of Ultimate Mapping, but of course anyone that understands can certainly answer!

I've been playing around with Fractal Terrains 3, to get a bit of an understanding of how it works. I've read through the basic guide, which gave me a 'simple' rundown of the most basic functions. I will admit that I didn't understand about half of what I read. A lot of the terms were too...technical... I guess that's the best explanation I can give. But I managed to get through the basest of functions, so that I can sort of get an idea of how to use the program.

So I opened the Tome to the section of Fractal Terrains 3, and I opened my program, so that I could start to learn how to use it. But for a lot of the explanations they might as well be written in a foreign language for all that I understand them. For example: In the New World generator it talks about a random seed. Now I've heard that term many times... but what is it?

Example number 2: I'm reading through the Secondary World Settings and I came across this for the Raw Height Field :

This indicates if the surface should be treated as a raw height field rather than a
fractal function.
A raw height field gets its data only from a linear interpolation of the offset channel;
it ignores any fractal data or scaling.
Using this option and an equirectangular projection makes FT3 perform like a
traditional height field tool.

I don't really know what a fractal function is, and I have no clue what a raw height field is, so the idea of treating something as one thing over the other is a bunch of gibberish to me. There are a lot of places in the FT3 users guide, and in the Tome that make about as much (or less) sense to me as this does.

Is there a technobabble translator/translation anywhere around?

Comments

  • LoopysueLoopysue ProFantasy 🖼️ 40 images Cartographer
    Random seed is just a random number generated by the software to 'seed' the fractal procedure that creates the lumps and bumps in the map. Each Random Seed will produce a unique map, and there are literally billions of numbers :)

    Its the random seed that gets changed whenever you click the next world button. Its regenerated each time - randomly.

    As for example 2?

    I have absolutely not a figgin of an idea what that's all about :)
  • I know fractals are used to draw Mandelbrot. sets. And world's in ft3. But that is as far as my knowledge goes. I'm sure Joe can explain it much better than me.
  • MonsenMonsen Administrator 🖼️ 81 images Cartographer
    edited November 2017
    I think Joe is actually the original author of that text (for FT Pro). I just updated it later for FT3.

    Generally, I recommend you just leave 'Raw Height Field" unchecked. There is a lot of technical stuff in FT3, and this is one of them.
    But basically, the fractal function is what's generating the world. It takes the seed (which, as Sue explained, is just a random number to make each world unique) and generates the world from it.
    The offset channel is basically a "list" of heights for each point of the world, and it is this you manipulate when you use the various drawing tools in FT. This then serves as a modifier against the random data the fractal function created, allowing you to edit the world. When the 'Raw height field' is checked it means that the fractal function isn't used, so unless you have already painted data to the offset channel, you will have a blank world.

    The FT3 chapter is probably the most technical chapter in the Tome, because there is so much of it in FT3. The tome is designed to help both intermediate users and experts, so sometime there will be a bit of difficult stuff in it. For the most part, I recommend just ignoring the too techy stuff in the beginning, since you usually don't have to understand all that immediately to be able to utilize the tutorials and the lessons learned from them, it might be better to return to it later.
  • That may be true. I just want to understand what it all means, so that when I go to make worlds in FT3, I understand the reasoning behind the choices I'm making. For example: Rainfall - I do understand that some areas on Earth receive more rainfall per year than others. For instance, North Carolina, where I live, gets a decent amount of Rainfall per year. The Mohave Desert (or any desert, for that matter) gets very little, if any at all. I know that rainfall factors into how the world is formed, mostly in lakes and rivers, but I don't know much of anything beyond that. But rainfall is something that's calculated in FT3. Why? why is it important? Or, more to the point, what do the numbers mean when imputing them into FT3? How will that change the world I'm creating? And how to I use those numbers to make the kind of world I want feaseable?

    I thought understanding the technobabble might give me some insights into these questions.
  • jslaytonjslayton Moderator, ProFantasy Mapmaker
    Ah, the arrogance of my youth. I usually made the assumption others knew what I knew.

    Random seed: Computers don't do random things, but there are some mathematical tricks that can be used to simulate a random sequence (it's generally very hard to generate a single random number in isolation). The idea is use limited mathematical precision and overflow to make a simple operation appear random. The typical simple random number generator is called a linear congruential generator and an example from the C standard looks like this:

    static unsigned long int next = 1;

    int rand(void) // RAND_MAX assumed to be 32767
    {
    next = next * 1103515245 + 12345;
    return (unsigned int)(next/65536) % 32768;
    }

    void srand(unsigned int seed)
    {
    next = seed;
    }

    The rand() function returns an apparently random number between 0 and 32767 every time it's called. Looking at the code, it's not random at all, but is just taking the previous result, multiplying it by a value, and then adding a value. The trick is that the multiply happens against a large number that overflows the amount of storage allocated. The overflow loses infoormation, ad over time that lost information makes things look random.
    The srand() function sets the seed value for the random sequence. As you can see, it just sets an initial value for all of the multiplies and adds. For any individual seed value, the sequence of random numbers will appear to be a unique random sequence. The rason that the seed is useful is that it allows you to have a program that produces the same sequence of random values for that seed, meaning that your program will produce the same output for every run (you don't want a different world every time you run the software, after all).



    FT is a little odd in how it generates altitudes for a world. It uses several images to let you paint information into the world and then adds high-detail random stuff to get the final result. The values of the high-detail random stuff are generally in the range of -1 to +1, so they need to be scaled into something that you want to see (your world minimum and maximum altitude values) and your edit needs to be added. The final altitude calculation looks like:

    altitude = (fractal + prescaleoffset) * roughness * altitudescale + offset

    This altitude is then compared to the water image and if the altitude is above the water, it's treated as land, and if it's below the water level, it's water.

    The fractal function is a special kind of random value generator that always returns the same value at a given position on the world. When the raw height field option is used, the fractal function, prescale offset, roughness, and altitudescale are all ignored in the above altitude calculation (only the offset image is used). Why would you want to do that? Normally, you wouldn't, because the fractal stuff is what makes FT interesting. However, if you are importing data and want to have data as close as possible to what you imported, you don't want to see all of that other stuff. There is also the problem of data filtering: because FT's editing data tends to be low resolution, it uses a smooth approximation of the edit data to make things look better. When the raw height field option is enabled, it also prevents FT from using the smoothing operation. In short, you'll probably never need to enable that checkbox or any of a number of rather specialized features.
  • jslaytonjslayton Moderator, ProFantasy Mapmaker
    Rainfall is calculated in FT3 for three reasons: pretty rainfall map, determination of climate type, and calculating rivers. It doesn't affect altitudes in any way.

    In FT, the climate type (technically a biome type in the way it's commonly used, but there are also elements on the climate list in FT that aren't really biomes like "mountains") is determined based on the average of annual rainfall and temperature. If you look at the Image Climate shader (Map>>Show Image Climate), the dialog pops up with an ugly and blocky image that is the default mapping from annual rainfall and annual temperature to climate type. The calculations for rainfall and temperature feed into the climate map.

    When FT calculates rivers, it starts by making an image that represents the amount of water available to flow at each point on the world (the size of this map is determined by "River Definition Resolution" value). This amount of water is the rainfall amount or (if the "potential river flow" box is checked) a constant value. The system then calculates an image of the total amount of water flowing at each point by tracing the downhill path, adding the amount of water at each point to the total flow. Then the flow image is processed to produce the preview image shown during the river length stage of the operation. Finally, the flow image is converted to vectors.

    The rainfall model in FT is extremely simplistic: it doesn't take into account any air or water movement (no rain shadows behind mountains, no reduction in rainfall with increasing distance from ocean, no Hadley circulation to give deserts at certain latitudes, and so on). Very approximately, FT's rainfall model is based on a basic overall initial value (the Base Value) adjusted by a fractally-modified Random amount and then adjusted by temperature (which in turn has a dependency on altitude and latitude). So, rainfall = (BaseValue + fractal * RandomValue) * temperatureModifier.
  • jslaytonjslayton Moderator, ProFantasy Mapmaker
    I don't know if my explanations in any way cleared things up, but I do recommend that playing with controls that have an unclear function is best done on worlds that are purely throwaway.
  • Okay, Joe - let me ask you some questions, and pick your brain a bit, if I may?

    Can I assume that FT uses the same basic principles for weather/climate temperature that we have on Earth? Meaning that closer to the Northern and Southern poles, the colder it gets, and the closer one gets to the Equator, the hotter it gets? But the temperature on any given planet is relative to it's orbital distance from the Sun. And the global climate is influenced heavily on how much of the sun's rays reach the planet to warm it. Are there any other factors, such as the planet's core?

    Also, is it always true that climate changes occur in a linear progression? For example, is it possible/feaseable for the climate progression to swoop lower in some areas (meaning a lower area where snow and ice form) and rise higher in others (where it generally stays warmer)? What could influence this effect? Is there anyway to make that determination in FT3? Is it even necessary to plug that information into the calculators for FT3?
  • jslaytonjslayton Moderator, ProFantasy Mapmaker
    FT very broadly uses the same sort of calculation for the very basic elements of temperature, but it's quite simplified (for example, it assumes a circular orbit and a spherical world). It also lacks many important dynamic features such as heat transfer via atmosphere and hydrosphere or coupling between atmosphere and hydrosphere. FT3 offers two basic models for determining the base planetary temperature: one where you enter the physical elements to figure temperature at the orbit (planetary reflectivity [albedo], solar input, and greenhouse feedback [atmospheric composition]) and the other where you just enter a base temperature. As with rainfall, there is a random fractal modifier. Unlike rainfall, there is also a variance value that indicates how much the temperature varies from equator to poles. FT doesn't model long-term effects of any sort (planetary core has a very an indirect effect on temperature in the sense that it affects tectonics, which affects atmospheric composition and albedo).

    https://socratic.org/questions/how-can-altitude-affect-biomes offers a nice diagram to help understand how temperature and rainfall affects climate type. It's possible to very much compress the sequence (for example, changing a desert into a forest) by having steep mountains or shift it one way or another by having glaciers to get cold winds down valleys or tall mountains to block rainfall. Generally, it's tougher to get colder local areas than it is to get warmer ones through natural processes and most of these effects tend to work on smaller areas than FT is good at displaying. For large areas on the world's surface, the general progression of climate type according to temperature and rainfall is fairly well described by the lookup table used in the Image Climate shader. As an example, you need a certain amount of water and a certain amount of not-cold to support trees. Some trees don't mind cold or hot as much as others (conifers are a good example of fairly temperature-tolerant trees, which is why they tend to dominate northern and higher-altitude forests).

    FT can show you the results of its temperature, rainfall, and climate models for any position on the globe using the View Properties toolbar.
Sign In or Register to comment.