[Fractal Terrains 3] How can I import and generate a planet from a preexisting map?
So I have put a ton of effort into this map here. I would love to use the features available in my purchased fractale terrains software to set climates, rivers and other miscellaneous (read tedious) features. However I have having a very hard time of it trying to import my map. It is an equilrectangular plates cairre projection already.
I think I need to somehow convert what I have to a .acf file so I can import it as a greyscale and apply it with the image overlay, but I cannot figure out a way how to do that, and even if I could I don't know if a general .acf could work. I would seriously love to get some help with this issue.
Here is a link to the equirectangular map I initially made http://i.imgur.com/PA4oF73.jpg
Here is a link to the equirectangular map that is a bit more seamless http://i.imgur.com/cpToCBM.jpg
Here is a link to the map in 2-tone http://i.imgur.com/i3MZLFm.png
Here is a link to the map in it's first initial form http://i.imgur.com/MnOONEI.png
And lastly here is a link to a web-app for looking at the map as a navigable globe https://www.maptoglobe.com/
I think I need to somehow convert what I have to a .acf file so I can import it as a greyscale and apply it with the image overlay, but I cannot figure out a way how to do that, and even if I could I don't know if a general .acf could work. I would seriously love to get some help with this issue.
Here is a link to the equirectangular map I initially made http://i.imgur.com/PA4oF73.jpg
Here is a link to the equirectangular map that is a bit more seamless http://i.imgur.com/cpToCBM.jpg
Here is a link to the map in 2-tone http://i.imgur.com/i3MZLFm.png
Here is a link to the map in it's first initial form http://i.imgur.com/MnOONEI.png
And lastly here is a link to a web-app for looking at the map as a navigable globe https://www.maptoglobe.com/
Comments
How did you generate the http://i.imgur.com/MnOONEI.png file? If you can modify the color ramp to grayscale rather than the green-to-orange ramp, then you can probably import that file directly into FT3 as a binary world file.
I generated the image you mention using about five or six maps generated on that map to globe site on the highest settings then patched them together manually.
I made this grey scale http://i.imgur.com/9MsViPT.png for importing, but I can't figure out how to make it a binary world file.
There are a number of ways to convert the grayscale image into a binary file that FT3 can use, but the simplest is probably via Wilbur ( http://www.fracterra.com/software.html ).
In Wilbur:
1) Use File>>Open to load your PNG file as a grayscale image file
2) Use Filter>>Mathematical>>Offset with a value of -128 to drop the oceans below sea level. Your terrain is now ranging from about -128 to about +127.
3) Use Filter>>Mathematical>>Scale with a value of 70 to scale your terrain from about -9000 to +9000 (assume meters for units in FT).
4) Use Surface>>Rotate>>Flip Vertically to account for a bug in the Wilbur to FT transfer process
5) Use File>>Save As with file type MDR Surface to save your file. Accept the default parameters.
In FT:
a) Use File>>New to bring up the new world wizard
b) Select Binary File and click Next to bring up the Binary Data page
c) Click Choose Elevation File to bring up the Binary Data dialog
d) Click the ... button to bring up a file picker
e) Select your MDR file saved in step 5 of the Wilbur process and click OK. You should see information about your world
f) Set the Map Edges to Top=90, Left=-180, Right=180, and Bottom=-90
g) Click OK to accept the data definition and dismiss the Binary Data dialog
h) Click Next to bring up the Summary page
i) Click Finish to finish the world operation
j) Enjoy your new world
If you would like to eliminate the external dependence on the binary file:
Use Map>>World Setting to bring up the World Settings property sheet.
Select the Editing page.
Select Custom and enter 6000 (your world's editing resolution) as the value.
Click Apply to accept the new editing value.
Use Tools>>Actions>>Burn Into Surface to convert the altitude into offset editing values.
You can now use normal FT editing operations.
If you're not strongly married to the way that the internal elements of the map are laid out (or even if you are), you might be able to get good results using Wilbur to rough in the terrain from your basic map outline and some information about mountains. The attached image shows what such a result might look like in FT after following the processes suggested at https://cartographersguild.com/showthread.php?t=29412 (the PDF almost at the bottom of the topic).
There are many tools that let you reproject images, including most GIS tools (QGIS being a popular one). I wrote ReprojectImage to be easy to use as a front end for reprojecting images for use with FT and with things like raytracing software. ReprojectImage suffers from some limitations and assumes that your input will be square to the image edges.
As a quick note, I just updated the ReprojectImage file to a build that includes aspect information. Due to an oversimplified UI in ReprojectImage (including the unpleasant feature that you must enter numbers for sizing), you'll need this operation to make things work correctly for the AE hemispheres kind of map. The example image shows a quick chop on the image of your Myirandos map. I was a little sloppy in placing the source grids and scaling, which makes the output look a little glitchy around the edges. The same technique will work for a grayscale height map, where it would be less likely to have issues with wobbly grid lines.
I am not the original poster, but I tried this several times and it did not work. it either outputted a file that is entirely underwater-at the lowest possible elevation-or one that was entirely ice-highest possible elevation. I tried again and got entirely water but with what appeared to be random noise at the top instead of water. Is there something I am doing wrong?
What image are you starting from? Is it posted somewhere that I could take a look at it to see the problem?
Does the image look correct after loading into Wilbur? If not, then this process won't work.
In Wilbur, if you use Window>>Histogram after step 1, what are the low and high values? What is the shape of the histogram? A histogram that has a very negative low value, a very large high value, and what looks like a spike in the middle indicates a file that has some corrupting noise in it. You can often correct this problem by using Filter>>Other>>Kill Outliers. Set a "Percent to Kill" value of about 2 to get rid of the highest and lowest few altitudes on the map, which are likely the cause of the problems. The important part of Kill Outliers is that it gets rid of NaN (not a number) corruption in the file. The percent to kill part is a convenience because corrupted data often has data that you're not interested in at the far ends of the histogram. If you get flat spots on the mountains or ocean basins, you can undo and try Kill Outliers again with a smaller Percent to Kill value (a value of 0 here doesn't kill any high or low values, just eliminates NaNs).
Ok, after a day, I figured out the problem:
when i exported with wilbur, i typed (filename).mdr, but didnt switch the wilbur export type below to say mdr. that meant it was exporting the mdr like a png, which caused loads of problems further down the lane.
Still, thank you for the advice! and sorry for the inconvenience!
I'm posting my question here to avoid starting a new discussion.
I have a heightmap created with Rock 3 (Image 1), which I converted to greyscale. In the process, I removed the mask that was hiding the seabed, also generated by Rock 3 (Image 2).
I then imported this map into Wilbur (Image 3), and this is probably where my problem starts.
The values weren't right, so I tried to correct them with various tools, including “Filter -> Mathematical -> Span.” I fiddled around a bit until the result looked visually consistent to me (Image 4, Already flipped as said in the guide).
Then I followed the guide in this post, which works very well, as I can open my map in FT3+ without any problems. The only issue is that the elevation is considerably high despite the other tips I've been able to follow (from here and elsewhere).
Does anyone have any ideas? Thanks in advance!
A brief check of The One Day Worldbuilder pdf shows me that while FT works with Feet and Miles, Wilbur works in metres.
Could that be the problem?
(If you are wondering what 30,000 feet is in metres, I use 9,144m)
I don't know enough to confirm or deny this idea, but from what I've seen, on the one hand it's possible to change the FT metric system, and on the other hand, if there was an error in the conversion, I imagine the problem would be the opposite (in the sense that if the transmitted values weren't converted, I would have an elevation of 9000 ft, I imagine).
I didn't know that - about being able to change FT from imperial to metric units. It is a long time since I played with FT, though. How do you do that?
However it happened, can you (or anyone else reading this thread) reproduce this problem?
It would be handy to know what process you used in more detail.
You can change them by going to “World setting > Secondary > Metric Units.”
It's a checkbox.
As for reproducing this bug, I can do it as many times as I want, but the process is described quite accurately in my previous message:
Create a map with the Rock 3 software (Steam), retrieve the heightmap (in RGB A, convert it to Greyscale), and import it into Wilbur.
Adjust the heights in Wilbur, and export to MDR for FT3.
Open the MDR file in FT3.
And no matter which map I use, following this process always gives the same result. The only variation seems to depend on the values I enter in Wilbur's mathematical span. Since this is the part I do most randomly, and the only one that varies, I deduce that my problem comes from there, but I don't know how to fix it.
Thanks for the tip :)
I don't know anything about Rock 3, so I'm way out of my depth now. You might be better off waiting for @jslayton to respond if he is available.
By the way - we don't have a problem with you starting your own threads at all. Adding to really old ones like this makes it harder for others to find whatever solution we discover for your specific issue.
I have an afterthought here.
Looking at the heightmap output from Rock 3 (I assume that is the black and white image second in the several you posted above) it looks very different to the bump map I would expect of a world. I will use a world I sculpted in FT and eroded in Wilbur using the One Day Worldbuilder pdf as an example.
Here is Jerion's altitude map.
And here is the bump map (I used the Show Bump Map option in the Map menu, which is a simple heightmap)
Although you can see from the colourful altitude view of Jerion (top) that there is a full 60,000 f00t range of altitudes from the -30,000ft bottom of the ocean right up to the top of the 30,000 ft tallest peak, the bump map (bottom) only shows the detail of the upper range of those heights. That's because we, as humans, can't tell the difference between shades of grey below about 60% black.
It is incredibly difficult sculpting a world as a heightmap alone because of that fact, and while I have no idea how Rock 3 works it might just be that the heightmap it has produced for you isn't responding well to being re-spanned in software the likes of which the developers of Rock 3 never envisaged the output being used in. What I'm saying is that the output is probably excellent for Rock 3, but it might not work well in FT or Wilbur.
I will of course bow to Joe's (jslayton) greater understanding of these things, but I thought the difference was startling enough to mention it and show you what I meant.
****
EDIT: Oops! I made a mistake. I realise just now that the bump map only showed bumps above sea level, so the sea really was all black. Here it is again as an altitude colour scheme with black as the bottom of the ocean and white as the top of the highest mountain.
However, it does still look very different to the heightmap produced by Rock 3.
FT can be configured using metres - it is on one of the World options.
Wilbur uses "height units" for its heights and doesn't really know anything about this "feet" or "meters" stuff except for a few fringe cases (Wilbur is a simple piece of image processing software with some weird filters and very biased opinions about certain things). FT is also a bit of image processing software (again with the weird filters and biased opinions) that uses meters internally for heights and distances as well as in the saved files, but has the option to show quantities as imperial units in the user interface. If I recall correctly, FT's importers want the data files to be in meters. So... When going from Wilbur to FT, make sure that the data in Wilbur is scaled to be 1 height unit = 1 meter or you'll have altitudes in FT that are off by a factor of 3.28ish.
If you forget to do the scaling in Wilbur, you should be able to do it directly in FT using Tools>>Global Math Tool if you've burned the data into the surface (this trick won't work if you're keeping the binary data in an external file):
That example assumes that you've pulled the Wilbur data into the offset channel, of course. If there's some other scaling factor that's crept in, you should be able to manually locate the highest point in FT and then scale by a factor of the desired highest point divided by the measured high point value.
Thanks @jslayton for the very technical answer. I'm not sure I understand all the theory, but broadly speaking, I need to align Wilbur's scale with FT's.
The manipulation doesn't seem to work directly from FT (probably because I exported to .mdr very clumsily without thinking too much about it...
So, starting again more cleanly from the “beginning” with Wilbur, how do I make “the data in Wilbur scaled to be 1 height unit = 1 meter”?
The heights shown in Wilbur will be treated as meters when imported into ft. If you have scaled your grayscale image as feet in Wilbur (the values shown in Wilbur look like feet), the scale the surface by 0.3048 to convert it to meters before saving to the mdr file. I'm not in front of Wilbur at the moment, but I think it's filters-mathematical-scale.
Oh yes, I understand (sorry, I'm not a native English speaker, I need a little more time).
I'll try a few things on my end, taking all that into consideration, and let you know how it goes.
[EDIT]
So, taking everything you've told me into consideration, I understand a little better how it all works. Indeed, changing the scale in Wilbur allows you to better level the heightmap.
But, because there's always a but, it's now very flat. Not abnormally so, just that the mountains that stand out particularly on the heightmap become fairly modest mountains when multiplied by 0.3048.
I think this part of the problem relates a little more to what Loopysue said earlier. The heightmap is strange and doesn't show the mountains as a “gradient” but as blocks, and I think the heightmap is difficult for the software to read.
It's annoying, I thought Rock 3 would make it easier to create a more realistic heightmap, but I feel like it's causing more problems than anything else.
If it's not too much trouble, do you have any suggestions for using this heightmap more effectively, or should I prepare to rework it by hand?
In any case, thanks again to everyone for your help, it's really nice of you.
In Wilbur, use File>>Open to open the heightmap of interest.
Window>>Histogram to see how altitudes are distributed. An earthlike world will show one peak at lower colors for the abyssal plain and another at higher colors for the continental shelf/continents. For this particular map, that turns out to be about 93 on the 0-255 scale. That means we need an offset of -93 to get the continental shelf/continental edge at 0 (sea level). Doing that turns everything into a set of little islands that doesn't look anything like your shown map, but using -64 does.
Filter>>Mathematical>>Offset -64
Window>>Histogram again shows low -64 and high 191 (as expected from a 0-255 grayscale image with a -64 offset). Assuming that we want the highest altitude at 9144 meters (30000 feet), we scale by 9144/191=47.87
Filter>>Mathematical>>Scale 47.87
To use an MDR from Wilbur in FT, it needs to be flipped vertically because Joe once changed an assumption, but didn't document it in the system and now it's way too late!
Surface>>Rotate>>Flip Vertically
The map really ought to correctly set its edges, so Surface>>Map Info can use used to set top=90, left=-180, right=180, and bottom=-90.
Save as an MDR file to give a save point in case you do something that you don't like.
Process the height as desired (select land, fill basins, incise flow, precipiton erosion, fill basins, resample to larger size, run processing loop above until you get the desired output size). Save as the MDR file to output to FT
In FT, Load the MDR file as a new binary world.
Map>>World Settings to change the Editing resolution to be at least as large as the binary file.
Tools>>Actions>>Burn In To Surface to bring all of the binary data into the offset channel.
Save the ftw file just in case.
Edit and export as desired.
Following what you said, I realized something interesting, which is probably responsible for a large part of the problem.
In my histogram, the values did not range from 0 to 255 at all, but from 1,800 to 65,000.
Trying to understand why you were getting different results with the same map, I realized that I had shared a screenshot here and not the original image, so I started comparing the two, and try to find the difference.
The original image has a “16-bit Greyscale” color profile, whereas the screenshot is in “8-bit Greyscale.”
After checking, changing the color profile seems to have fixed everything, so I conclude that this was definitely the source of the problem. I'm sharing this information in case anyone else encounters a similar issue in the future.
Everything seems to be resolved, so thank you again. I can now move on to the next steps!
I'm glad you were able to resolve the issue.