Results 1 to 7 of 7

Thread: Deserts in FT3

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1

    Default Deserts in FT3

    When I'm building a world in Fractal Terrains 3, it never seems to create deserts or plains. I think I'm using data close to earth-like, but it's all forest of one type or another. When I just drop rainfall across the board it gains me some grasslands and savannah, but my forests completely disappear. This seems to hold true no matter the geography of the map. Is this just a problem inherent in the software? My search for the topic indicated that FT does have some difficulty with climates.
    Last edited by galrionmartel; 04-16-2013 at 09:53 PM.

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

    Default

    FT doesn't do atmospheric moisture and temperature transport. As a result, the results are a bit unrealistic (to put it mildly). http://www.ridgenet.net/~jslayton/climateinfo.gif shows FT's internal average annual temperature/rainfall to climate type table. You'll note that it doesn't include things like "mountains", "hills", or "plains" because those can't be determined from the simple temperature/rainfall table. FT really ought to have a "physical geography" visible layer with mountains, hills, plains, shallow ocean, and so on and a "biomes" visible layer much like the current "climate" one.

    FT normally doesn't generate average annual rainfalls and temperatures that hits the "desert" spot on the table. FT really needs some toys for atmospheric transport (even just a latitude-based rainfall model would help) for good results. In the meantime, judicious use of the temperature and rainfall painting tools is your best bet for getting deserts to appear. You'll need to figure out where the deserts go and then (usually) lower rainfall until you get desert in those areas.

  3. #3

    Default

    Thank you! It's a little more work to paint it myself, but at least now I know some of the program's limits.

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

    Default

    If there's one thing that FT definitely has, it's limits!

  5. #5

    Default

    Well that sounds ominous. Is there a program that would give me a better foundation?

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

    Default

    Quote Originally Posted by galrionmartel View Post
    Well that sounds ominous. Is there a program that would give me a better foundation?
    Not that I have found, no. Then again, I wrote FT, so I'm a bit more aware of what it can't do than most people. As long as you stick moderately close to the intended purpose of FT, it does a reasonable job and it accretes more features over time. Admittedly, some of the accretion results in features that are a bit peculiar. Some of the limits are simply because I didn't know in 1998 what I know in 2013.

    The ProFantasy forum is another excellent place to ask questions about FT.

    As an example of bizarre features, FT has both a "pre-scale offset" and an "offset" adjustment layer. The pre-scale layer is defined in an odd space that's not really helpful to users, while the offset feature is defiend in the user's preferred editing units. The pre-scale layer gives better results, but didn't make its debut until later versions of FT. Many of the tools in FT don't work with the pre-scale layer, which is a shame. Again, it's one of those things where you learn new things and try to retrofit to the old.

    As examples of limits, FT is a purely software-based renderer that uses the elderly Windows GDI system for drawing. That means no antialiased lines, and very little in the way of hardware acceleration. FT didn't even become multithreaded until fairly recently. FT uses a brute-force approach to its computations, which slows things down quite a lot. It also uses several uncompressed, uniform-sized 32-bit floating-point surfaces for its workspaces, meaning that it's a memory hog. Those workspaces aren't defined very efficiently, either. The files store those surfaces in an uncompressed manner; people have been amazed when a 100+MB FT file compresses down to a few hundred KB. FT is also a 32-bit program, meaning that it hits memory limits far sooner than many people would like (there is an experimental and unreleased 64-bit version that bumps up the limits substantially).

    If I were starting development today, I would do a lot of things differently. The world is very much unlike it was when the Pentium II 450MHz machine with 128MB and running Windows 98 was king.

  7. #7
    Guild Novice
    Join Date
    Mar 2012
    Location
    Albuquerque, NM
    Posts
    17

    Default

    Trying to autogenerate biomes can be difficult. Average temperature and rainfall can only be generalized by latitude. Prevailing winds and ocean currents play a large part in determining those values. To my knowledge, FT does not take those variables into effect when calculating rainfall and temp. There are also other factors like soil type that affect the vegetation density of a location. That said, judicious use of FT's rainfall, and temp editors along coastlines and on the leeward side of mountain ranges and comparison to actual locations on earth that are at the same latitude and elevation yields pretty decent results.
    Also, "plains" are essentially areas of low topographic relief and generally short vegetation. But if you look through examples of biomes of the world youll find great variation, for example in savannah and grassland biomes, you'll also see some that are more heavily forested than you'd expect.

Posting Permissions

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