19-12-2002 05:29									#1
	Map: Coordinates, Shape, Polygons, and rendering issues. Tired of ads?

This is a new thread (don't mean to threadjack the polygon thread... but this is all related) for discussing how we are going to implement the map.

This thread is for discussing map shape, coordinates, polygons, rendering issues (2-D vs 3-D), the relationship between them, and hopefully for coming to a consensus on their role in the evolution of the map generator.

This is continued from a discussion that started here, and a concept that was introduced in the polygon thread and the previous map thread.

PLEASE NOTE: If you are going to participate in this discussion, I suggest dowloading the document mentioned in my next post below. It contains links to a document that is central to the nature of this discussion. (It has a lot of math in it... but don't let that scare you )

Last edited by primemover on 19-12-2002 at 07:26

	19-12-2002 06:18									#2
	Support Apolyton, buy Galactic Civilizations: Deluxe Edition

Hi primemover, thanks for getting this going, and putting in the links!

I hate to rain on your parade, but the "polygon thread" and "previous map thread" links both go to the polygon thread. . .

Cya,

Mark

	19-12-2002 07:11									#3
	Get a bigger avatar today!

quote: Icosahedron is way more interesting than dodecahdron because it looks the same from everywhere and you don't have to figure out strange projection angles. Furthermore, you can refine triangles by splitting them in 3 triangles, and all the angles still remain the same.

Yes... I understand... and I did mean an Icosahedron. I did a *lot* of research on how to grid a spherical map when I started developing ideas for the game I had in mind over a year ago. I found a very informative document on how to do a global grid system. I am attaching it to this discussion because of its value in understanding how this all works (see below). It serves as the starting point for the topic of this discussion thread. The document is a zipped Acrobat (PDF) document. For purposes of acknowledgment, I found this document at http://www.wmo.ch/web/www/DPS/. I do not know who the author is (as of yet).

Here are direct links to the original source:

Doc version
PDF version

When you view a spherical map made of triangles that use the isocahedron as its base, the angles are going to change. This is especially true because not ALL the angles ARE the same in the translation from euchlidean geometry. The triangles that are positioned on one of the 20 triangles are going to have a different orientation/angle than those which are positioned on another of the 20 triangles. This will make 2-D rendering very difficult in my opinion. (If you can't envision what I mean, take a look at the illustrations in the attached document).

Now I am guessing that this might be scaring Mark a little... (too complicated?)... But I don't think it would be too hard (at least from the grid point of view)... especially since we have code that already takes care of the generation/grid sytem part of the picture.

	19-12-2002 19:08									#4
	Increase Your PM Length

Hey primemover, can you just email me the doc? I tried to download it but since it has a .doc extension my MS Office tries to open it and covert it. Next time, if the correct file type isn't available, could you just put it in a zip, which is always allowed? You might want to go to the Apolyton/Community forum and request that pdfs be made a possible file type, since I"m with you that its pretty silly not to have it available.

quote: Originally posted by primemover Now I am guessing that this might be scaring Mark a little... (too complicated?)... But I don't think it would be too hard (at least from the grid point of view)... especially since we have code that already takes care of the generation/grid sytem part of the picture.

I wouldn't be scared if that level of detail were absolutely essential. Rather than "too complicated" my shoot-from-the-hip response is "Needlessly complicated". Simply using lattitude and longitude on a sphere with polygons seems so much simpler And better a way to do a 3D map. . . Why would we ever want to go this route? I just don't get it.

Once we had a sphere implemented we could use tranformations as suggested by Laurent if needed.

Laurent, responding to your comment from the I want to help... thread about not liking a globe because you want to see your Atlantic and Pacific fleets at the same time. The fleets will be too small to see anyway at that scale. I can see cases where you would like to see the whole world in one view, but that would be so zoomed out that about all you could look at are large-scale political boundaries and geograpic features.

	20-12-2002 02:54									#5
	Support Apolyton, buy Alpha Centauri

I couldn't reach the document either... I get the point about the icosahedron problem in terms of rendering.
About the fleets: I want to be ablt to zoom out from Atlantic to world, zoom in to Pacific on the same map. Basically, I like to zoom at mas level to see my Earth when I am almost done...

	20-12-2002 07:06									#6
	lattitude, longitude, and zoom. Support Apolyton

Latitude and longitude is not a problem from the user standpoint. The problem is that when using lattitude and longitude on any sphere, the size of the block changes. Using squares would be needlessly complicated if a sphere were to be used.

All we would need is a translator. I am not worried at all about the type of coordinate system. If it is endlessly complicated, we won't use it. I just don't think it is that complicated. As long as we can have/find (which I believe I already have) an algorithm that allows us to translate any coordinates into the correct spot in a system of trianges (and hexagons/pentagons), it wouldn't matter what system the user uses at all (longitude, latitude, x,y, whatever). We could even program in terms of x and y for certain things, but a grid locator routine would be necessary (i.e. the translator--which I don't forsee as being a big problem).

Zoom isn't a problem either. We could simply generate a small projection of any type desireable and put it on the screen as a locator (mini-map) that allows zoom where one clicks on it. It would simply be a matter of translating between mouse coordinates, to the miniature coordinates, to the actual grid position. (The only real potential problem here is clock cycles. This is the only complication really... other than the time it would take to convert between systems... again, I don't forsee either of these as problems)

I think what I should probably do is examine the algorithm used in the code I downloaded and see how complicated it would be to implement. Once we know what it would involve, we can talk in concrete terms instead of guesswork. I still would not want to implement it until we have other details of the map worked out as well. I will try looking it over the holidays.

	20-12-2002 07:07									#7
	Downloading the document Remove this text

just use the links to the actual doc on the internet. Download whichever form you want. If they get moved (or sooner), I will worry about the format.

I put the links in the same post as the attachment.

EDIT: OK IT WAS SOONER... it is now a zipped pdf file.

Last edited by primemover on 20-12-2002 at 07:18

	29-12-2002 03:02									#8
	Tired of ads?

I finally read the document (had to download Acrobat Reader, it was not on my new computer...).
I understand better what you said about 5/6 triangles now.
As I understand it, the 5/6 may not be a problem in terms of visualisation, as we could always use a centered visualization like the one on Fig.4, then pan it left/right if the view is not centered on the central vertex of the star. That means we would effectively switch between 12 different "flat" views.
The coordinate system would probably best be adressed by 1 big triangle number + 2 small triangle numbers if we need them. I think that is not very important in-game, only during world generation, but I could be wrong (maybe volcanoes or such want to know where they are on the sphere).
That document is very interesting and I think we should use that kind of algorithm to cut a sphere into polygons.
The good side is that the number of small triangles can be as high or low as we want. We could have numbers of polygons in a formula of 10* (i) * (i+1) triangles, with i the number of divisions of a big triangle. (That means 20, 60, 120, 200, 300, 420 etc. triangles.)
Triangles could be merged into hexagons/pentagons if needed, and into bigger polygons after map generation if we need to save computing power (like oceans).

	10-01-2004 23:56									#9
	Browse Apolyton AD-FREE

Resurrecting a thread that appeared during my absence...

The whole purpose of the icosahedral system is to produce a regular grid.

My polyhedron proposal is specifically designed to get away from the concept of a regular grid. The Earth is not divided into triangles, so why should our game made be so divided?

Cheers and PF

	14-01-2004 05:49									#10
	Increase the size of your Attachments

It isn't divided into squares/rectangles either...

	14-01-2004 11:46									#11
	Support Apolyton

quote: It isn't divided into squares/rectangles either...

Quite. I dislike them just as much.

Cheers

	17-01-2004 01:23									#12
	Suffering from ads?

quote: It isn't divided into squares/rectangles either...

Of course. It's divided into pixels.

	17-01-2004 03:11									#13
	Inflate your Upload Space

No it isn't. It is mapped to pixels. Storing it as pixels could be a real chore. Mark would immediately want to have pixel-level-economics. Also, how many armies could dance on the head of a pixel?

Cheers

	17-01-2004 05:25									#14
	Support Apolyton, pre-order Civilization IV

quote: Originally posted by Gary Thomas Mark would immediately want to have pixel-level-economics.

I resent that allegation. I would, to reduce processor usage, have the same economy for clusters of pixels with the same color.

	17-01-2004 23:05									#15
	Support Apolyton buy from Amazon

By suitable use of dithering we could ensure that no two contiguous pixel are of the same colour...

Cheers