# Mapmaking Discussion & Philosophy (WIP/Critique) > Software Discussion >  Fractal Terrains 3 Upgrade just dropped...

## guyanonymous

It's $9.95 to upgrade for FT Pro 2 owners for the next week or so....

"Because you bought Fractal Terrains Pro world-building software from ProFantasy Software, you are entitled to an upgrade to the latest release - Fractal Terrains 3 - for only $9.95 / £7.50 - more than 60% off the retail price."

----------


## ravells

Yay, thanks guy, I'd missed that offer. Downloading FT3 now!

cheers

Ravs

----------


## ravells

Downloaded it and had a look at the new goodies. I guess the only two improvements which are of interest to me are the 16 bit png export and the better use of multi-cores (and possibly using a bitmap shader for the climate)...the upgrade looks a lot more like it was intended to bring FT Pro into line with CC3 products in terms of exporting to them.

----------


## Ramah

Yeah, I took a look at the new features on the update page and to be honest it seems more like a patched version than an actual update...

"Added normalize tool to manually fix problems with painting in earlier versions that could cause black areas to appear on the world."
"Many niggles and bugs fixed and export libraries updated."

They are listed as features. :S

----------


## guyanonymous

I'm just playing now - if it improves (actually fixes) exports and a few others stuff, I'll survive.  At $9.99, I can live with it, though I was hoping for more improved algorithms etc.  We'll see once I test it out. Regardless, it's got me interested again  :Very Happy: 

Edit: I'm curious about the multicore and memory use.  For the procedural stuff I've done so far, I can see it's using multiple cores, but it's not using any of them fully, rarely going above 30%.  The rivers, for example (at 8090 setting) are taking quite a while to process - is this just the nature of it asking each core to do one thing and another core the next (and why they're all not at 100% as it goes 3x faster than currently)?  And for memory - will this version use more than 4GB ram or is it still stuck with that limitation?

As a plus - no crashing yet!

----------


## Mateus090985

I had the FTPro instaled but I deleted yesterday. I have the FT3 upgrate for free (my copy of FTPro has a litle more than 1 month). Do I simple download the single arquive form my account or I do have to reinstall all things from FTPro and then install the "upgrade"? And I dont see manuals or Terraformers links for the FT3...

----------


## guyanonymous

It was a fresh install for me, by the looks of things - just asked for the new key.

And the rivers - despite taking a while - look far better than in the previous version. I used an old FT2 map, and the rivers I generated looked more realistic, and I didn't end up with strangely straight rivers all over the place. Yay!

----------


## Mateus090985

And the Terraformer? It's included on the single archive provided or is a separeted download?

From the FT3 page: "Terraformer is a free, unsupported add-on to Fractal Terrains created by user Bill Roach. It's available as a download for registered users."

----------


## ravells

Yes! The rivers do look much, much better!

----------


## Ramah

> Yes! The rivers do look much, much better!


Well that is something I can finally get on board with. I'll wait for more views though before committing.

----------


## chimpster

Can anyone comment on whether or not FT3 solves:

(a) The sine-wave shaped "ribbon" that went around the planet in FTPro and looked like it'd been scratched with a cheese grater.
(b) The mountains-always-in-the-exact-middle-of-continents issue.
(b) The interior-lakes-are-always-at-sea-level issue

Trying to decide whether or not to upgrade, and these are my main gripes with FTPro. Cheers!

----------


## Mateus090985

As long as I can tell the "mountains on the midle" is still there. I also want a updated manual and to know where is the new Terraformer...

----------


## ravells

Terraformer has to be downloaded separately.....if you do a search in the CG you will find a link to it. 

Ah....here is the thread

@chimpster: as far as I can tell all those issues are still there.

----------


## Mateus090985

> Terraformer has to be downloaded separately.....if you do a search in the CG you will find a link to it. 
> 
> Ah....here is the thread
> 
> @chimpster: as far as I can tell all those issues are still there.


So there is no new version of these material? I simple use the files from Fractal Terrains Pro: Terrain Data and Terraformer Package v0.50? So basically FT3 is FTPro with better compatbility with CC3? ... I spected more...

----------


## ravells

As far as I know, terraformer has not been updated since version 0.50. Also terraformer is free, so one can't really complain too much  :Smile:  

As guy said, the cost of upgrading is not much - about US$10 so I guess you need to look at the updates and decide whether it is worth it for you.

----------


## guyanonymous

I did have my first crash in trying to save a 30000x16xxx png file outright.

I didn't try anything smaller, so I'll try to figure out the limits over the next few days. 

I've also gotta try the multi-file output and see if you get inconsistencies at edges (one pixel of rivers missing etc).


EDIT: 

1. First test of multi-file output - still no png option, and must hold down ctrl-shift (or just one of them?) to get the bmp option to appear.  
2. Multi-file - I tried a 4x2 output (7500 res) and it flaked out (aborted the save, but didn't crash)
3. Multi-file - I tried a 4x2 output (6000 res) and it appeared to be working, but as I don' use this (I prefer a final 30000 pix res) I stopped it after checking the first 6000x____ output of the whole map
4. Multi-file - I tried a 6x3 output (5000 res) and the whole image (5000x____) was fine. The separate images, however, show rivers ending 1-2 pixels from the edge, which means, when pasted back together, I'll have to manually fix the missing 2-4 pixels for every river that crosses the border of one of the 18 images that make up the entire thing. GRRR.
___
5. The maximum filesize limitation is still in place for saved files (2.x GB files) which seems to be calculated before any compression for png/jpg files, at least.  I wish they'd add .psb so that we could save files at full resolution or by avoiding the multi-file cut&paste approach. It would save a lot of time and stress. Stitiching together 18 pics is one thing, doing it for the 3-4 layers I use (land, water, texture, climate combos, river layer) is tedious and frustrating.

6. the maximum file size (in round numbers) that it seems to let me save is 8000x4401 or so.

----------


## Mateus090985

I am having little problems exporting files biger than +- 5000 x 5000 in the spin-view.

----------


## guyanonymous

> I am having little problems exporting files bigger than +- 5000 x 5000 in the spin-view.


It's still a 32bit program, and limits itself to, well, not much memory as well as file saving.  It's frustrating and means they still haven't updated things to deal with some of the bigger (pun intended) complaints I, at least, had about the old version.  Let me use all my RAM to work with files, and let me save them in one step at resolutions that roughly reflect what it currently can deal with.  (for me that's 30000x16000 or so).


EDIT: OK, I'm now seeing the good old crashes from the last version. While I'm not seeing them in saving files (it stops the save with an error message with some info this time), I've had it crash when raising terrain amongst other tools use.  Right now I'm thinking that I paid $10 for better rivers (which to me is a bug fix) and an improved interface.  Beyond that, I've not yet encountered any real benefits to upgrading.

----------


## waldronate

30000x16000 images require 480Msamples. At a minimum 8 bytes per sample (4 bytes for terrain and 4 bytes for color), that's 3.84GB before allowing room for the program or for the operating system. That's just for holding the output data. The working data takes much more than that for handling the editing data (4 bytes per sample for each of offset, scale, climate, water, ). 32-bit Windows programs get 2GB to work with per process (3 GB if you do ultra-special things behind the scenes to windows and the programs). Assuming that the full 2 GB of process space is available (which it really isn't), then that would give you a maximum output size on the order of 10000x5000 or so. FT isn't hugely efficient, so you'll probably get a little less than that.

Implementing a good virtual memory system was a bit outside the scope of the planned FT development. FT originally made some assumptions about maximum data sizes and further assumed that everything would fit into memory (yes, I was sloppy). Rewriting the system to work with a paged system would be a bit non-trivial because it would require rewrites of huge chunks of the system, with the attendant new bugs and likely breaking changes in some areas. Add in the performance wall when you run out of physical memory and it was just a bit risky for FT3 in my opinion.

----------


## Mateus090985

I cant find where I modify the streght and widt of the tools... I cant find it neither on the interface nor the manual .

----------


## waldronate

Try View>>Toolbars and Docking Windows>>Tool Options to bring up the Tool Options bar and it will let you set the tool options for tools as they are selected.

----------


## waldronate

The algorithms for generating terrain haven't changed from FT2 to FT3. As far as the interior lakes thing goes, those are artifacts of the basic terrain generation algorithm in the sense that they are areas below the base water level (0). You can paint water to raise or lower the lakes. Tools>>Actions>>Fill Basins as Lakes will fill the terrain with lakes at all altitudes, not just at 0.

----------


## Mateus090985

> Try View>>Toolbars and Docking Windows>>Tool Options to bring up the Tool Options bar and it will let you set the tool options for tools as they are selected.


Thanks a lot! I would never find then there =)

----------


## guyanonymous

> 30000x16000 images require 480Msamples. At a minimum 8 bytes per sample (4 bytes for terrain and 4 bytes for color), that's 3.84GB before allowing room for the program or for the operating system. That's just for holding the output data. The working data takes much more than that for handling the editing data (4 bytes per sample for each of offset, scale, climate, water, ). 32-bit Windows programs get 2GB to work with per process (3 GB if you do ultra-special things behind the scenes to windows and the programs). Assuming that the full 2 GB of process space is available (which it really isn't), then that would give you a maximum output size on the order of 10000x5000 or so. FT isn't hugely efficient, so you'll probably get a little less than that.
> 
> Implementing a good virtual memory system was a bit outside the scope of the planned FT development. FT originally made some assumptions about maximum data sizes and further assumed that everything would fit into memory (yes, I was sloppy). Rewriting the system to work with a paged system would be a bit non-trivial because it would require rewrites of huge chunks of the system, with the attendant new bugs and likely breaking changes in some areas. Add in the performance wall when you run out of physical memory and it was just a bit risky for FT3 in my opinion.


I hear what you're saying (and understand it to an extent)...I was just hoping for something 64-bit based that could allow me to use my computer setup to capacity.  With most new computers having 4-8GB of ram these days, and coming with 64bit windows by default (at least the one's I've seen friends/family picking up), I'd like to see more programs able to take advantage of that capacity.  I do appreciate that instead of crashing, now, it tells me about memory limitations in the error message - but I'm still frustrated.  I do know that I'm an extreme case in that I'm using FT Pro for art rather than role-playing, but that's just how I roll  :Wink: 

I think I settled on 30000x______ because it was the maximum file size that Photoshop handled gracefully and that other programs could open when saved as bmp for use in the google-maps-ifier program I was using. It also corresponded, nicely, to the maximum zoom I was able to attain in FT Pro before the terrain pattern became more noticeable than the terrain shading it was providing (does that make sense?).  When I zoomed more in FT Pro, the pattern used for terrain shading was more obviously a pattern, and less obviously shaded terrain. 

I tend to go to extremes when doing things, but that said, I don't think outputting an image of the map at more than 7500 pixels in width is that extreme.

Do you think there's an easy fix/patch possible so that rivers don't get cut off 1-2 pixels from the edge of all multi-image outputs?

----------


## waldronate

There may or may not be a 64-bit version of FT one of these days. The reason I phrase it that way is that it's eays to make a mistake and create FTW files that aren't compatible between versions.




> Do you think there's an easy fix/patch possible so that rivers don't get cut off 1-2 pixels from the edge of all multi-image outputs?


I have not observed this particular problem. It might be due to line clipping at the edge of the image, though. Example images might be helpful.

----------


## Ramah

Would you say that enough has changed in this version to warrant a new version number and having to pay again, Waldronate?

I guess you cannot say other than yes really but it does seem more update than upgrade. I would have thought the problems you mentioned through tackling virtual memory and paged system would be exactly the kind of thing tackled for a new version.

----------


## waldronate

This FT release was a little thinner than I had planned due to personal reasons that have made it a couple of years late already. As far as value for the dollar, I think that it is a fairly good ratio. It brings the FT product into line with the rest of ProFantasy's product set and avoids the issue with having to translate CC2 files into CC3 files (that's the primary justification for FT3 instead of something in the FT Pro group). It offers a number of useful upgrades and a few hidden features (for example, holding down Shift when doing Create on the Campaign Cartographer Export window allows output to SVG format - it's not fully-functional compared to the CC3 export, but it will get the basic contours out).

The textured climate shader is fun to play with and the addition of 16-bit PNG output is highly useful to certain folks. The Cosmographer export was updated (holding down Shift when picking the menu item will get you the older one, just in case). A whole lot of effort was put into making the program more stable and better able to handle low-memory conditions (something on the order of 100 user-reported issues were resolved).

A fair amount of time went into taking advantage of features of the newer compiler and windowing framework. Multiple rendering threads give a more responsive main window repaint on more capable hardware. It's compiled for SSE2, meaning what the code has crawled up the way up to the Pentium 4 era, at the cost of compatibility with some older hardware.

The $10 for upgrade isn't a bad deal and it will allow you to get the FT3 updates as they come out. I won't promise anything with regards to timing, but historically there have been significant new features that appear between paid upgrades (something on the order of ten official updates over the last ten years with a total of now two paid upgrades).

----------


## ravells

> (for example, holding down Shift when doing Create on the Campaign  Cartographer Export window allows output to SVG format - it's not  fully-functional compared to the CC3 export, but it will get the basic  contours out).


Wow, this alone is worth the upgrade for me! Only problem is that when I tried it, I came to this error message after going through the menu choices after pressing 'shift - create'. Any help would be muchly appreciated!

----------


## waldronate

Even though FT may want to install to the program files directory, it's generally been a good idea to not install it there because the system protections prevent programs from writing to that directory (it's a defect in FT from long ago that seems to have made it through the net). This particular problem may or may not be related to that, but I personally recommend installation other than in program files (or program files (x86) for you 64-bit users).

I'll put this one on the bug list. As much as I was hoping that most of the bugs were expunged before release, there are always a few after delivery.

----------


## ravells

Thanks Joe! uninstalled and reinstalled to the root of the C drive and it works fine now!

Thanks again!

----------


## guyanonymous

I'd agree that the $10 isn't a big hardship, and I'm pleased for better looking rivers, for sure.  The additional climate maps etc. are also welcome.  I also like the new streamlined interface.  :Very Happy: 

___

I've attached a psd file showing the multi-image allignment issues I've noticed. EDIT: I couldn't attach because of file size, so I've uploaded a zip file to mediafire.  It contains the .ftw, the .psd multi-layer crop which uses two .bmp exports, and four full-sized .bmp export files (6000x6000) which fit together in a square and show what I call the 'dark line' (inverse tones?) issue, and 'river-gap' issue which.  Here's the link: http://www.mediafire.com/file/dbot44...20right%29.zip

For the PSD: As each image is 6000x6000 pixels, I've just taken a slice of two of them on the sides they meet.  The bottom layer is on the left and includes the dark line (that's part of the saved .bmp file).  The top layer is on the right.  There is no space between the images.  

Re: Rivers: If you scroll down, you'll find several examples of rivers that cross the border, and notice there's a 1-2 pixel game on each side of the border (the land is there).  I've circled several in red to make this easy  :Very Happy:   The 'river-gap' problem occurs at the top/bottom of images as well.

Re: 'Dark Line' issue: You'll also notice on the right edge of the left image (bottom layer) and on both images at the bottom most edge, there is a one-pixel line that appears to have an inverse light-dark value;  the colours are correct,  but what's light is dark and vice versa.

In the past, I've just moved the right image over to the left one extra pixel, to overlap the 'dark line' artifact of the left image, it tends to look better (still with river gaps), but not perfect.  There is enough of a pattern that becomes apparent as you scroll up and down, as there appears to be one missing pixel. I've not tried inversing the height map for that single pixel yet to see if that's what it actually represents. I believe the bottom right pixel on every image, though, is normal, because the right line and bottom line overlap there, producing a double inverse, or normal pixel.

I saved these, originally, in bmp to avoid compression artifacts. 

I'll also upload the original .ftw file I'm using.  I output at 6x3, with a resolution of 5000.  This, in theory, will let me make a 30000x15000px image, though it's always a couple pixels off because of the 'dark line' artifact.  I think it's appearing on the right and bottom of each saved image.

Thanks for taking a look at all this...if this was fixed, it would save me a LOT of time when I merge the multi-files back together, and actually let me automate the process.

p.s., with respect to your comment about 32/64 bit saves not working in the opposite version, it's likely that anyone using a 64 bit version would only use that, and vice versa (unless you end up with a plug-in situation like photoshop with some plugins only working in 32bit and others only in 64).

p.p.s., Is it possible to feather the tools in this release? Or use a different brush (other than a circle/oval of your dimensions)?  If not (and I don't think it is), please consider those features for the future if they can be worked in.

----------


## waldronate

The dark edge at bottom and right has been there since day one (the first bug report is from 2000). It's not to say that it's correct behavior, but it's unlikely to go away any time soon.

The gaps in the river is a buglet caused by the river hitting the edge of the map. It's supposed to be clipped at the edge, but it seems that FT is just dropping the last segment. Grids have the same issue, but in that case it can be eliminated by turning off adaptive grid resolution and bumping up the number of segments. These issues are easy enough to correct onscreen in FT, but those tricks don't work on export to CCx.

If you're using the multiple file export feature, have you tried using a bit of overlap between images (say 10% or so)? That way the rivers at the edge won't have a problem with missing their last segment and the black line can be eliminated fairly simply. Not ideal, I understand.

I would rather just export a huge single image, but the problem is that FT would have to compute a strip of the image, draw the raster overlays, draw the vector overlays, and then write out that strip. The clipping issue can cause problems with this operation, unfortunately.

A suggestion was made to have a different file format for the 64-bit and 32-bit versions that would incompatible with each other, but I am of the opinion that there should at least be an upgrade path from 32-bit to 64-bit. Making that work would result in a file format that was compatible between the two versions with the possible exception of data sizes.

The tools should already be feathered. The circular painting tools should start at 0 at their edge and rise to the user-specified value at the center. For the more advanced users who want to try something different, FT offers the brush preset file. If you save a brush preset file and then open that file in Notepad, you may find that it's a simple text field that contains a number of interesting values. If you've ever used the Edit Paintbrush Settings dialog in Wilbur and saves a preset, then this set of features will look familiar (FT and Wilbur share a brush engine). The part that might be of most interest to you is the "FileName" field that lets you specify an image file to use as a brush. I recommend setting up a brush you like in Wilbur and saving the brush preset into the FT folder. Then you should be able to use that brush in Wilbur. I forgot to port over the UI for the brush parts into FT, but the engine is there and it works the same (I think brushes are upside-down in FT realtive to Wilbur, but that's a minor thing).

----------


## guyanonymous

Thanks for considering things.

I'd thought about the overlap, but then I've still got to manually move the images exacting number of pixels rather than just align them beside each other.  Is it possible to change this from a % to an absolute value (e.g., 5 pixels)?

Is the dark edge (bottom & right) actually a valid row of the exported image tile? Or is it an extra row of pixels that can safely be deleted?  The visual pattern (an obvious line) that appears when I just delete those single rows, suggests to me that it was supposed to be a 'real' line.

I agree 100% about exporting a huge single image being the ideal.

I'm glad to hear some feathering is already there. I'll check out the brush preset file, though I've never used it in Wilbur. When using an image as a brush, does it have to be b/w, or can it be grey scale and have transparency?  I'm envisioning painting on a pattern of mountains ripped from reality.

----------


## waldronate

The dark edge is an artifact of a lack of data at the edges of the map (there's nothing to the right of the map to compute a normal from and the computation seems to get the wrong sign in those places). It may also be caused by a curved projection hitting the edge of the map data and coming into uninitialized data. The altitude data should be valid data, but the intensity computation for the shading is wrong.

The brush image can be any file. It will be interpreted as a grayscale raster ranging from 0 (0 intensity) to the specified altitude value (255 intensity). Real images of mountains and craters are usable as stamps. I don't recommend dragging the brushes, though. I don't recall if it properly handles transparency/alpha channels or if it's just a straight intensity computation, though.

I tried a 64-bit build, but Visual Studio was not being cooperative. I'll probably have to completely rebuild the project from scratch with VS2010 in order to get it to work. That sort of thing is somewhat low on the priority list at the moment, though.

----------


## Redrobes

Was it a VS issue with the x64 build or something about the app code that is the issue. I'm using VS compiler (cl V 14 as part of the x64 SDK) to build all my x64 stuff and its as stable as rock. In fact I would say that its more so than the x86 and that's not bad either.

----------


## waldronate

There's something in the project files for FT that the environment doesn't seem to like. The x64 build of Wilbur comes out of the same compiler just fine and a lot of that code is the same.

----------


## Redrobes

Ok. I have to admit I run my compiler from a short cut to a bat file which sets up the environment for 64 bit building and I have another to run up the x86 compiler. So I run with separate environments. Well, if its something you want to chat about in PM or on the user convo or something then let me know and ill go through what I have or do if it would help out get it sorted. Oh I should say also that I dont use the VS projects as I run out of makefiles so maybe I bypass those kinds of project and settings issues as well. I just use the VS IDE to kick off the make and use its editor which I still think is the best out there. But I always think that the VS project format really sucks. It seems to need updating all the time and you cant go back to an earlier format without pulling it out of some code repository or something. I like to see all the settings I am using instead of the dialog panels with them all on.

----------


## guyanonymous

I'd be more than happy to beta test a 64 bit version...  :Very Happy:  just sayin'  :Wink:

----------


## guyanonymous

My quick experiments with: 6x3 at 5500, w/ 10% overlap allowed me to crop each image down to 5000, and they but up together nicely at first glance. I'll do more experiments later.  Doing this for 18 images for each of 5-6 layers, though, is very time consuming.

----------


## guyanonymous

Is anyone else having issues when defining the colours to use for altitude rendering?  In the previous version, I could select, for land, the highest peak colour and the lowest peak colour, and (for the most part) it would create a range of colours in between.  Usually this was done with white as the high-point, and black as the low point.  Now, however, it fails miserably; things tend to just get filled in with black despite colours being chosen.

----------


## Mateus090985

Yes, I am also struggling with it...

----------


## guyanonymous

Thanks - hopefully that'll get cleared up quickly.

----------

