I'm working on a custom terrain generator, and would like to be able to edit the .ter files directly, but i'm having problems finding any documentation on the file format. I've open it in a HEX editor, and think I understand what differentiate different pixels/point, but i'm not sure how to translate that to a height in meters... And the files seems to have some additional info too...
Making changes to the file, i've so far found that the height data, for a 1024x1024 map starts at offset 0x5, and ends at 0x200004 (inclusive). (This is not 1024x1024 meters playable map necessarily, but from the size of the original heightmap) This gives each point/pixel 2 bytes or 16bits of data. For example, replacing offset 5 and 6 with: "x9" or "78 39" or "01111000 00111001", will create a spike in the corner of the map (assuming is it flat or close to the bottom there), doing the same on the last two offsets will create a spike in the opposite corner. Max height can be changed on the terrain in the editor, this does not seem to change the terrain file, therefor I assume that the map is just stretched accordingly... for example, changing my input from x9 to x8 decreesed the height of the spike about 10-25cm from what I could tell, on a map with 150m max height. These seemed like quite large steps to me if one wants very smooth terrain, and there probably is some steps in-between that I haven't found yet. Not all inputs seems to be valid either, my game crashed a few times testing random inputs, so I'm guessing some bytes are reserved. Edit: This seems to be wrong, lowest possible point is 00 00, and highest is FF FF, however, the first byte are the small steps, and the last byte is big steps... kind of opposite of what one would expect.... So that means there is a total of 65536 steps, Smoothness It seems the first two bytes (offset 0x1, 0x2) or maybe just the second, has to do with the size of the map. 00 01 = 256x256 00 02 = 512x512 - Assumption, haven't found a 512 map to check 00 04 = 1024x1024 00 08 = 2048x2048 I'm still curious what the rest of the file includes, since the height data is just 30% of the file I'll get back to this later, but I'm sick, so it'll take some time i suspect... Any help would be appreciated
Wouldn’t it be easier to generate a heightmap programmatically and then import it with the method the world editor uses?
Sure. but that is manual, my end goal is something fully automated, and includes heightmap formats that beamng don't support, like laser point clouds and geotiff...
I saw this topic when you posted it but didn't have anything to say. I was interested in this as it is something I would like to try, too. Going back to working on a modded map of mine, I realised that the terrain format is actually stored with the terrain file. There should be a file called [terrain name].terrain.json and in it is the data relating to that terrain. The first entry in that json file is "binaryFormat". For my map (and probably for others), it reads: Code: "binaryFormat": "version(char), size(unsigned int), heightMap(heightMapSize * heightMapItemSize), layerMap(layerMapSize * layerMapItemSize), layerTextureMap(layerMapSize * layerMapItemSize), materialNames", So, the first byte is the version number. Bytes 0x01-0x04 are the size (32-bit int) After that is the height of every point in the terrain (this I don't have specifics on but I will assume it's 16-bit/2 bytes per point by looking in a hex editor) EDIT: I just tested it by making my own terrain reader and can confirm this is the case. I don't know what the layerMap and layerTextureMap are though one of which would be the terrain's material (I can't confirm yet but both are probably 2 bytes each). Finally are the material names, which are just written as plain text and separated by 1 byte (I don't know if this byte stores anything) EDIT: The numbers are stored as integers, little endian.
Yeah, thanks, I actually found that one too... but it still lacks some information, and it's not complete, but I have enough for now to use for my terrain generator. Here is the info I have so far: byte (represents version, not sure if this is meant to be used for the version of the map, or more likely it is the terrain format version) unsigned int (terrain size, "2048" for a 2048x2048 map) 2bytes * (2048*2048) heigthmap, 00 00 is lowest point FF FF heighest. 1byte *(2048*2048) layermap, (00 would be the first layer from the layer list at the end, 01 the second, and so on, FF makes a hole in the terrain) After this I have 4 more sets of 1byte*(2048*2048) That I don't have any idea what does at this point.... some of it seems to have to do with cover, like billboard flowers etc... int (the numbers of layer names to come) list of signedString (signed means they lead with an number telling how many letters are in each name, this is the 1byte seperation you talked about)
