3d central Thyatis

[Big Mac]

How did you infer height data from Thorf's original 2D map? Did you invent some sort of rules for terrain having slopes?

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):

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

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).

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.

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:

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

The hole map of central thyatis by thus can be store in a file not larger than 30kB.

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.

If TABs are a "unit of height" there is then the question of how much height 1 TAB is equal to.

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.

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.

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?

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.

Thanks for the two offers. Like I said above I'm not sure I could do anything with your work.

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.

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!

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.

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.

[aklanda]

Hello Big Mac,

thanks for your interest. Before writing more about it, I first have to say, that I am no native speaker, so my answers might not be as precise as they could, as I sometimes don´t know how to express myself. But I will try my best.

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.

Well, to be fair, I tried to explain it very technically and didn´t even supply all the info you need to understand it. I will try to make it better right now:

Pixel-maps (as the ones of Thorfin are) look extremly good as they are a piece of art and they are also extremly helpful for human beeings, as a human brain can easily extract lots of information out of them, like:
"What kind of terrain is over there, right next to a mountain?"

Unfortunatly to the computer it is much more complicated to extract this kind of information out of a pixel map, as a computer doesn´t have such a good picture-recognition-system as our human brain is.

So, if you want your computer to be able to "work" with the terrain of a map (like modifying the terrain, calculating how long it takes a player to move on this terrain, calculation how much gold the ruler of the dominion, to which this terrain belongs, gets out of the terrain) you first have to teach your computer to identify certain terrain-types (forest, mash, grassland,...).

You probably already knew this, but I posted it anyways, as there might be other who are interested in. So let´s move on:

I am not a professional programmer, but I have fun trying out algorythms and so I tested a rather simply approach to this problem:

The idea was, to teach the computer to recognize terrain-types in a pixel-map by either

- let the user "click" on some hexes in the pixel-map and let the user tell the computer which kind of terrain this hex stands for or
- by providing the computer with terrain-tiles (small pictures in hex-form, which show a forest or a grassland or a desert,...) together with the info, which terrain-tile (for example: the green picture with trees) represents which terrain-type (in this kind: forest).

Afterward we let the computer determine, which aspects of the provided terrain-tile are specific to it.

For example the terrain-tile for forest might have a high amount of dark green pixels, probably not so much blue pixels and even less red pixels.

We do this for every terrain-tile/terrain-type and thus get a database, which holds informations for the computer, how it could recognize terrain. This database might look like this:

Code: Select all

Name	LongName	Terrain	Material	Vegetation	Resources	rCount	gCount	bCount
1	Clear, Farmland	Flatland	loam	agricultural land		0	100	0
2	Hills	Hills	silt	grassland		100	0	0
3	Mountains	mountains	rock	tundra		100	0	0
4	Light Forest (Predominantly Deciduous)	Flatland	silt	forest light		0	100	0

As you may see in the tables, a hex in the pixel-map, which contains 100% "mostly green" pixels (gCount!) will be assumed to be a terrain of type "clear, farmland".
A hex in the pixel-map, which contains 100% "mostly red" pixels (rCount!) will be assumed to be a terrain of type "Hills".

At this point you might object, that hills aren´t red at all (which is true), but all the pixels in the hex in a pixel-map, that represents the terrain "hill" have lots of red in them, as they are brown (and in brown there is red).

You might also object, that by this way there is no way to differentiate between a hex of "hills" and a hex of "mountains", as both have 100% "mostly red" pixels, because the first is brown and the other one dark brown.
This is true and it is the reason why I also had to include other markers, as there are:

- average percentage of red in the pixels
- average percentage of green in the pixels
- average percentage of blue in the pixels
- average color of all the hex
- amount of "mostly black" pixels
- amount of "mostly cyan" pixels
- amount of "mostly magenta" pixels
- amount of "mostly yellow" pixels
- contrast of the pixel-colors
- brightness of the pixels


So an entry for the "grassland-terrain" in the database actually looks like this:

Code: Select all

Name	LongName	Terrain	Material	Vegetation	testR0	testG0	testB0	AverageColor	rCount	gCount	bCount	blCount	cCount	mCount	yCount	contrast	brightCount
1	Clear, Farmland	Flatland	loam	agricultural land	60	80	40	&c96C864	0	100	0	0	0	0	100	0	100
2	Hills	Hills	silt	grassland	84	75	33	&cD2BB52	100	0	0	0	0	0	100	84	100
3	Mountains	mountains	rock	tundra	62	48	21	&c9B7834	100	0	0	0	0	0	100	146	99
4	Light Forest (Predominantly Deciduous)	Flatland	silt	forest light	57	77	37	&c8EC05C	0	100	0	0	0	0	100	55	100

Once, this database is created, the computer can apply it to any other hex of the given pixel-map, simply by comparing the amount of "mostly red" pixels in the hex in question (and the amount of "mostly green" pixels,...) with the entries in the database. If the result of the comparison shows, that the amounts of "mostly red" pixels (and so on) of the hex of the given pixel-map are not too far away from the entry for "Hills" in the database, it would be fair to assume, that the hex in question is representing the terrain "hills".

Sometimes a picture is better then thousands of words:

[img]http://fs5.directupload.net/images/170926/gv8pw7qe.png[/img]|[img]http://fs5.directupload.net/images/170926/au5eb982.png[/img] This is the pixel-map we would like to "scan" in. That is, we want the computer to know, which hex is of terrain-type "grasland", which is of terrain-type "hill" and which is of terrain-type "mountain".|So we have a look at all of the hexes. And for each hex we look at all of the the pixels in the inner-part of the hex (I just marked them red to illustrate what I mean. The pixel-map itself is normally not changed), count, how many of them are "mostly green", "mostly blue" and so on and compare the result for each hex to the stored result in the database. If it is best resembled by the entry for "hill" in the database, the hex is probably of terrain-type "hill".

Once you have done this for all the hexes of the pixel-map, the computer now "knows" the terrain.

You can then "save" the map by simply storing the koordinates of the hex, followed by the number (in this example: 1,2,3 or 4) of the terrain.

Let´s have a look at the file-format of the thus stored map:

Code: Select all

x/y/z	terrainTileNr	terrainMaterial	terrainVegetation	terrainResources	terrainInfluencer	height	settlementName	settlementSubtype	Country	Dominion
-31/-30/0	3									
-30/-30/0	1									
-29/-30/0	3									

So does the TAB number represent your inferred height relative to Thyatis? If TABs are a "unit of height" there is then the question of how much height 1 TAB is equal to.

No, this info is stored in the newly created column "height", which I don´t use right now, but which will make it easy to alter the height of a hex by the user. Thanks for the idea! And yes, you are right, there is the question about the measure of the height. I choose a rather intuitive approach to this, but someone already pointed out, that the mountains are far too high if you assume the hexes to be 8-miles-hexes.

Or is it a label that your program is creating for an individual hex, so that it can call on that number later?

No, the key/label to an individual hex are it´s koordinates x/y/z (which are, as you already assumed, relative to a fixed place, let´s say a special capital).
Even the z-koordinate isn´t the normal "height" of the hex as in "height of a mountain". I introduced it to be able to create several levels of maps (let´s say an underground map, a map for the upper world and a map up on a flying island in the sky). So the meaning of z would be:
z=-1: underground
z=0: upper world
z=1: flying island
By thus you can create literally "infinite" numbers of maps at different levels, each of them positioned above another...

In case I understand your questions well, the "TAB numbers" (which are the numbers 3,1,3 in the above example, right?) represent the terrain-type.
To simplify things you could say that "3" stands for "mountains" and "1" stands for "Clear, Farmland", but this is not the full truth. I can explain this in another reply, if you are interested in, but I can already "reveal", that I have another approach on "terrain" (as you might already guess by looking at the colums "terrainMaterial" or "terrainVegetation" ).

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.

I probably didn´t explain that right in the first place, so I will try to do better:

The progresses of "reading in a pixel-map" and "creating a 3d-map" are totally different progresses. You can read in a pixel-map (or one pixel-map after the other, "scanning in" more and more terrain) and store it (in the file-format described above).
Month later you can restart the software, load the stored map and choose to create a 3d-map out of it.

The progress of "reading in a pixel-map" is NOT error-prone, as the computer might easily not be able to differentiate between a hex with "forest" and an hex with "light forest" in the pixel-map, as the amounts of "mostly green" pixels and so on might not be very different. So you will get interpretation-errors.

A totally different thing is the creation of the 3d-map. This part is error-prone as the software simply has to create a 3d-model for every stored hex and add up these models to one huge 3d-model of the map.

But there´s another problem in here:

The computer has no information about the height of a hex, as this information is simply not available in the (flat) pixel-maps.

So what the computer does while creating a 3d-map: it is making assumptions about the height of every hex:
Mountains should be high, hills a bit lower, grassland lowest (but still above sea-level) and sea of course at sea-level.
So it does apply a height to each hex (or better to say: to the six edges of a hex) according to the terrain-type of the hex and modifies this height just a bit with random values.

You are right, that for to infere the height I have to compare the height of one hex with the height of the hexes around this one. But as I only compare with the nearby hexes, the time, that this algorythm needs, is only proportional to the total numbers of hexes (and not overproportionatly). But, of course, it takes more time to convert a big map into a 3d-map than to convert a small map, as you already stated.
(Actually this part of the algorythm caused me some headaches, not because it´s difficult to calculate the medium of two heights, but because I choose some funny approach to it and made it more complicated as it might be. Might choose to revise this part, but as the saying goes: "never change a runnning system").

Your implied idea, to not only compare with the nearby hexes, sounds good, as this might result in higher mountains in the centry of a mountain chain, but time prevents me from covering this aspect and as you already stated, this might lead to much longer conversion-times.

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.

Yes, you are right, the edges doesn´t look well, especially when the terrain at the edges is "mountains". I assume it is simply because one "side" of the mountain is missing, or to speak in 3d-models: the "face" on this side of the mountain is missing, which makes the mountain transparent on this side.

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?

In case you refer to all the map: Not in terms of "heights", as these are partly calculated randomly (which might easily be turned off)
In case you refer to the edges: I don´t really chop up maps. The 3d-map is always calculated totally new form the stored map (which can be created by "interpreting/scanning" a pixel-map)

Thanks for the two offers. Like I said above I'm not sure I could do anything with your work.

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.

First time I hear about Anna Meyer. Thanks for the hint. Will have a look at her art.

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.

I am at the beginning. But the map-stuff is only a small part of the idea and the already finished work. The main reason to make this part was to have a map, where I can let the computer calculate traveling-time and simulate dominions with income, armies and stuff like that. The 3d-map was only another way to display the map. But I will continue to work on it.

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.

Yes, you are right, the audience might be wider, but I have so much fun to work with the maps I loved to play in as a DM years ago

Actually I wasn´t so much looking for formats for 3D mapping, but instead for formats for 2D mapping and I assumed there had already been some canonical ideas about it.
I had a look of the file-format of hexographer. It looked pretty clean, but missed some information I would like to include (dominions, resources and so on.)
So I stayed with my own file-format (and implemented an import-function for hexographer-maps.)

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.

Thanks

If you have more suggestions or questions feel free to post them and I will try to reply.

I will try to provide an updated version of the simulator, including the import for hexographer maps and pixel maps, in some weeks, so you will be able to "play around with it" on your own...

*Edit* included some pictures to visualize the text

[Big Mac]

Thanks for all the information Aklandas. And don't worry about your English. I understand you just fine.

The issue with me asking quetions is purely down to the fact that you are working on a highly artistic process that I don't know how to do.

I hope things move forward for you on this, and that you find some experts who can look at what you are doing and come up with some good questions that give you new ideas.

[aklanda]

Thanks for all the information Aklandas. And don't worry about your English. I understand you just fine.
I hope things move forward for you on this, and that you find some experts who can look at what you are doing and come up with some good questions that give you new ideas.

Thanks!

[aklanda]

Wanted to know, if this method also works on real maps.

So I scanned in the British Isles, converted the map to hexes of 8 miles and added settlements from 800 A. Click on the picture for to zoom in.

[agathokles]

Once more, very cool! BTW, if suitably refined, this method would be very useful to create hex maps out of existing world maps -- from the real world or from other D&D settings.

GP

[aklanda]

Once more, very cool! BTW, if suitably refined, this method would be very useful to create hex maps out of existing world maps -- from the real world or from other D&D settings.

GP

Thanks!

Yes, thought of converting europe some time later. Unfortunatly it only works with kind of topographical maps, as the color (dark-brown:mountains, light-brown: hills, green: flatland) is the key for the conversion. Hand-drawn pencil-sketches will not be recognized correctly.

Still it will create large files, especially when I export the hex-maps as pictures...

[agathokles]

Of course. The classic map from the Lord of the Rings would not work. That said, many maps from TSR settings use a style similar to that of RW maps -- think Birthright or Forgotten Realms or Dark Sun.

GP

[aklanda]

many maps from TSR settings use a style similar to that of RW maps -- think Birthright or Forgotten Realms or Dark Sun.

Yes, you are right, that might work too.

Right now I will have to concentrate on getting rid of several bugs in the simulator.
I´d also like to proceed with the dominions (economics, civilisation-grade, income etc.)

Ireland and Britain will probably be my test-setting.

Here´s an picture showing the dominions in Britain and Ireland at about 800 AD:

[Big Mac]

Very nice.

There are a couple of RPG settings based on a distorted British Isles.

Westeros (A Song of Fire and Ice/Game of Thrones) is an upside-down Britain, with Ireland stuck on the bottom.

I think the other setting is called Valorean. (Not sure on the spelling there.) That was a setting used to test D&D Next. It was also upside-down.

[aklanda]

Very nice.
There are a couple of RPG settings based on a distorted British Isles.

A nice idea!

Posted an update for the simulator, if anyone should like to play with the map-creating-tools.
As it was time to start a website for all the stuff (simulator, maps, animations), you can download it directly from the website:

Aklandas Simulator new Website


The included documentation is a bit outdated, but I will try to also update this.

[aklanda]

Updated hex-map (6-miles) of Ireland and Britain for 800 AD.

This is done by the the same procedure as I tried on the known world (see the first posts of this thread), but I added some features in the simulator to get a bit further.

The map now includes:

* settlements of 800AD
* large swamped areas
* the mystic Island "High-Brasil"
* kingdoms and earldoms of the time
* ruins where Hadrian´s-Wall stood

Maps are (from top to down):

1. topographic map with terrain. vegetation, settlements and dominion-names

2. political map

3. map showing the estimated state of civilisation based on the assumed population of the settlements (this map might be inaccurate for Britain and is probably inaccurate for Ireland, as I had no proper resources for settlements in Ireland at this time)

4. 3D-topographic map

The topographic-map is available in an even higher resolution.
It is also available without settlements and dominions (just terrain).
The 3D-map is also available as obj-file, which you can import in any 3d-programm (like blender).
You can download these additional versions at my website (see below in my signature)

There are also less elaborated, older versions of the maps for 8-miles-hexes.

In case you might wonder, how I made them:

As describes above, the main idea is , to scan in (any) topographic map and to convert it to a hex-map and to make it editable.

If you want to have a look at the symbolds/tilesets I use, look at this post: Download Symbols/Tilesets