I'm not sure I could do anything with your files to be honest. But there might be some more creative people than me who are able to recreate what you have worked out and use your process on other hex maps.aklanda wrote:First thing was to digitalize the map itself. For that I had to analyse the terrain-tiles of Thorf for the amount of black, red, green, blue, cyan, magenta, yellow and black pixels, which are typically for a given tile. The result of the analysis looked like the following excerpt (the last seven numbers do represent the amounts of dots of the named colors, as already stated, the third column holds the info about the average color, which is later used in the 3d map for coloring the hexes):Big Mac wrote:How did you infer height data from Thorf's original 2D map? Did you invent some sort of rules for terrain having slopes?
I can provide the full file, but if anybody is really interested, I can update the upload-link of the simulator, so that you can generate your own file(s).
Code: Select all
1 Capital &cB77944 3 1 1 183 121 68 45 54 0 0 0 41 58 2 Metropolis &c536F38 3 1 2 83 111 56 2 59 3 43 1 2 57 3 City &c58763B 3 1 3 88 118 59 2 62 2 40 1 1 60 4 Town &c496231 4 1 4 73 98 49 1 51 1 50 0 0 50 5 Village &c5A783C 5 1 5 90 120 60 2 63 3 38 1 2 61 6 Palace &c57743B 7 1 6 87 116 59 2 62 3 40 1 1 60
So does the TAB number represent your inferred height relative to Thyatis? Or is it a label that your program is creating for an individual hex, so that it can call on that number later? It looks like the former, as you have four 37s, six 38s and five 39s. That's a variation of 2 TABs over the area of the map.aklanda wrote:Afterwards I read in the pixel-map of Thorf. Then I entered the x and y-offsets in the software, so that the position I assume for Thyatis (x=0, y=0) equals the position, where you can find Thyatis on the map. Afterwards I had to try out several scaling factors, so that the hexes in the map equal the hex-size I assume in the software:
Then the computer had to read-in any single hex of the map (that is all the pixels in the map, that correspond with a hex). This takes some minutes, but can take up to a full hour with bigger maps (see my later postings).
The pc then compares the read-in amounts of read, green, blue ... with the stored amount for the tiles and thus assigns a tile to read-in hex.
The the pc stores the tile-number for the hex together with the position of the hex. This looks like that:
The hole map of central thyatis by thus can be store in a file not larger than 30kB.
Code: Select all
x-Position / y-Position TAB tile-number) 0/0 1 -30/-30 38 -28/-30 38 -26/-30 37 -24/-30 37 -22/-30 37 -20/-30 39 -18/-30 39 -16/-30 39 -14/-30 39 -12/-30 39 -31/-29 38 -30/-29 38 -29/-29 38 -28/-29 38 -27/-29 37
If TABs are a "unit of height" there is then the question of how much height 1 TAB is equal to.
I can see that you have a process here and that it works again and again, when you stick in more maps. If you are comparing hexes with other hexes to infer the height, I can see how adding more hexes would cause you to need to make more comparisons. And if the TAB numbers are generated from hex colours, I can see how a big map might cause potential disputes in the interpretation. So that might make the process take longer and longer, if areas are expanded and cause computing time to get bigger and bigger.aklanda wrote:As you may have noticed the file format let you extend you map to any given direction without any problems, as you only specify the koordinates in regard to Thyatis.
You might also extend the file format itself. I could imagine adding a third koordinate z for "highness" and you might also add additional info after the tile set, thus as the name of a city or village. I'd be glad to hear your suggestions to this matter.
But there are also limitations:
1. Without further developed tielset-recognition the recognition of tilesets is not fool-proof. I had to limit the amount of tileset the pc is able to distinguish to about 10 (grassland, hill, mountains, cities etc.). The pc is NOT able to differantiate between a city and a village, as the amount of black pixels is nearly the same in both tilesets.
2. Some maps don't scale well, especially, when you have bigger maps that are assembled from smaler maps
The last step was the making of the 3d map, which was quite simple. I just had to read-in the generated map, create for any given location the 6 points of the hex as 3d-points and elevate them accordingly to the tileset. I only had to make sure, that "sea" alwasy stays sea-level and add some random-alternation for the other tilesets.
Do you have problems with edges? On the edge a map, you have a cut-off of data, so if you are inferring TABs from their surroundings, I can imagine that the loss of data would potentially cause problems for edge hexes.
Do you get the same results if you rerun this process multiple times? And do you get similar results if you chop up maps in different ways, run your process and compare the results?
Thanks for the two offers. Like I said above I'm not sure I could do anything with your work.aklanda wrote:If you need any further info, like:
1. Some of the files stated above
2. The code-snippets for tileset-recognition or creating the 3d map
3. The created 3d-files (in obj-format, which is importable by blender. e.g.)
Just tell me.
If you want to make the process by yourself, just drop me a note. I can update the download link to my software, so that it also includes the part that allows the 3d- map-making.
But I do find this sort of thing interesting.
I've been following the work of Anna Meyer, who spent over ten years making a 3D model of Greyhawk. I've seen her map get bigger over time and I've seen the quality of her map get better over time.
I've also been following Thorf, when I can. He has been doing some amazing mathematical 3D work on figuring out the implications of the size and shape of the polar openings on Mystara and how the influence the Known World and Hollow World maps.
Now here you are doing something new. And it looks like you are still fairly close to the start of your process (so I've not missed all the fun) and you are learning stuff and making your process involve. I'm not sure exactly where you are going to go with this, but I can see it's got legs and it's galloping off in some sort of direction.
If you want to discuss potential formats for 3D mapping, that seems to be a separate topic to an individual map for a 3D Central Thyatis. It might even be something that goes beyond Mystara that could help fans of all RPGs. So you might want to consider making a separate topic.aklanda wrote:BTW: I would like to ask you some questions, as this seems the right place to ask them:
1. The file-format of the map-file seems rather natural to me. But maybe I missed something, should add something or anyone knows about a canonical file-format that is already present?
2. As stated, the recognition of the tilesets is not always reliable. Should I implement a way to modify the map after it was automaticly created by the pc (That is, modify/correct hexes)? This would take some time, but if anyone wants this feature, I can give it a try.
3. As stated, the height of the points in the 3d map is created by the pc in accordance to the tileset. I can try to make them editable (though this may be the toughest thing to implement), if there is need for it
4. I enumerated the tilesets, as the tilesets of Thorf suggest. That is "1" for "2" for metroplolis" and so on. Is this an acceptable way or is there already another enumeration?
Thanks in advance for helping with my questions!
I think that you need cartography experts to give you their opinion on this. I'll see if I can cast the Summon Cartographer spell on Anna Meyer and/or Thorf.