FT Pro Issues
I have tried every program out there to dynamically generate somewhat realistic looking planets, and it appears that FT is the best overall, and gives me some cool stuff others don't like rain/temperature.
However, I need access to the data from a 3rd party application so I can use those maps within other software. I export the BMP's fine, but even though only 250 levels for altitude were setup, I get over 1600 unique colors within the file due to antiasliasing. Is there any way to turn this feature off so I can get just the 250 colors in the exported file? I'd like to be able to specify say 1000 levels of altitude, and have it not anti-alias them, perhaps give me a key for each color, and then I can programatically determine the altitude based on the color from the image. Same with temperature/climate/etc.
I'd be happy with a way to utilize the FTW file, but don't want to spend the time to try to reverse engineer it.
Basically I need the "view properties" window data in FT Pro accessible from outside the application, using either the generated files or FTW file.
Without that, the program is essentially worthless to me, even though it generates pretty maps, to a computer they are gibberish
The ability to use FT Pro as a DLL reference within an application would *rock* as well, that way I can generate more than 1 map per hour without having to sit in front of the computer.
Thanks,
Bad Syntax
However, I need access to the data from a 3rd party application so I can use those maps within other software. I export the BMP's fine, but even though only 250 levels for altitude were setup, I get over 1600 unique colors within the file due to antiasliasing. Is there any way to turn this feature off so I can get just the 250 colors in the exported file? I'd like to be able to specify say 1000 levels of altitude, and have it not anti-alias them, perhaps give me a key for each color, and then I can programatically determine the altitude based on the color from the image. Same with temperature/climate/etc.
I'd be happy with a way to utilize the FTW file, but don't want to spend the time to try to reverse engineer it.
Basically I need the "view properties" window data in FT Pro accessible from outside the application, using either the generated files or FTW file.
Without that, the program is essentially worthless to me, even though it generates pretty maps, to a computer they are gibberish
The ability to use FT Pro as a DLL reference within an application would *rock* as well, that way I can generate more than 1 map per hour without having to sit in front of the computer.
Thanks,
Bad Syntax
Comments
You can also use the MDR format, which stores the height data as a floating-point raster (giving you billions of possible elevation values) and has some information stored in its header. With MDR you don't have to try to interpret anything - the values stored in the file are the values calculated for the world areas. If you contact the author of Wilbur and FT you can get information on interpreting this file format. It might be in the original FT documentation, but I don't have that handy so I can't say for sure.
FT even has an option to generate the entire world at arbitrary size in MDR format and Plate Carree projection so that you can get as much information as you'd like.
Using the FTW file isn't really an option as it's just a bunch of modifiers for the procedural generation algorithms at the heart of Wilbur - without those algorithms you aren't going to be generating the same worlds.
There are some command-line parameters for FT that can be used to automate its performance as Astrosynthesis does. Basically you call FT with the appropriate parameters and it generates your requested images without ever showing its main window. The same person that has the MDR information can get you the command-line parameter information.
BUT, once I did that and programatically went through the files they ended up looking really bad. The shape is correct (so I know I'm reading it right) but the colors are really screwed up, they look kinda like tie-die or a plasma screen saver sorta look. I tried various ways of loading the colors, and only rendering one particular color byte (red, green, blue), but nothing seems functional. If I use raw for example, and read each 32 bytes from left to right with an altitude map, the image is mostly yellow, and all the land completely black. MDR format, skipping the first 1024 bytes and reading it like raw has the same results. If I read the bytes as unsigned they are just black maps.
Based on the output it kinda looks like a bug in FT, and since its probably a VERY unused feature to save in these other formats it may have never came up before.
After installing the latest wilbur and trying to load the exported MDR files, wilbur can't do it (no error, just no load) so I'm definately leaning towards bug in FT Pro.
Take the climate map, it has 17 (I think) different climate regions/biomes. Each has a specific color. When I save that image, regardless of format, and try to get a particular color and match it to the specified colors it is configured to use, it doesn't work.
If I set say 250 levels, from 0,0,0 to 0,0,255 colors, the colors should be 0,0,1.... 0,0,250, but instead they are all over the place.
Perhaps if I could figure out how to associate a particular color integer or RGB value to a value as configured in FT that'd be fine, but since I configure 250 colors and get over 1600 in the saved file, its obvious that won't work. Maybe there is a way I can get the "nearest" color value in FT a particular color in a saved file has? I'm not sure how to do that if its the solution
I'm using .NET and getpixel to determine RGB values at a particular location within the file btw.
There are a number of likely failure modes when dealing with the RAW file format and they are described in the attached image. The MDR file format has the same issues, but it also has a 1024-byte header at the beginning of the file. Note that RAW and MDR do not store anything other than altitude data. For other types of data you'll need to save a color image format such as BMP or PNG. I do not recommend JPG for this purpose as it does not preserve the original image information in a useful way for external processing.
A possible problem that you're encountering with something like the climate map is that the image shading that modulates that basic color map will throw off your RGB values. To remove this shading, use Map>>Lighting and Color to bring up the Lighting and Color property sheet. Select the Intensity tab and move the Shadows slider all the way to None (setting the Vertical Exaggeration value to 0 also works for this purpose). Images written will now be just the basic colors you want without the intensity modulation that causes the RGB values to vary significantly from pixel to pixel. Again, save as BMP or PNG, never JPG when trying to process the information with an external program.
To get the rainfall/altitude/temperature I had to take each byte, divide by 255, total them, divide by 3, and then multiply by the maximum. This gave me a valid result.
Climate on the other hand wasn't so easy. I ended up using irfanview to reduce the color count to a more acceptable level. Then I went in with paint.net lasso tool and selected the "near" colors, the ones that were aliased, and set them to the colors as setup in FT. It was a bit of a pain, but once I figured it out it seems to work pretty good.
The rivers are going to kinda suck, as occasionally on the map they actually break, I'll probably leave them off anyway as 10km per pixel would make a pretty darned wide river
I appreciate the clarification on everything, and it looks like I can use FT finally. Yaaaay!
Anybody happen to know the command line parameters for it?
I gotta go write an app that randomly creates some 10km "submaps" so I can dynamically move around an entire world