Jump to content


Photo

Geodata


  • Please log in to reply
18 replies to this topic

#1 Pi Masta

Pi Masta

    Sergeant

  • Xenocide Recruit
  • 68 posts

Posted 23 December 2006 - 01:37 AM

I got to thinking about how we are going to decide what country a UFO is flying over or what not. I thought it would be extremely simple to basically convert a long/lat point to a Country or Ocean name. Maybe I didn't know what to look for but everything was designed to do the exact opposite, that is take a location like a street address and convert it to long/lat.

Alas I found this site. Where he basically has a comma delimitted file with long/lat points that describe borders for the countries as a polygon. I don't know why he didn't bother to zip it, but its 2MB of text, it doesn't have the country names (just assigns a unique number to each polygon), and there are some areas missing like antartica.

Overall I think this is a good resource to use. Most other data that gave lists of long/lat were just that of cities. Such files might be useful later when we decide where Terror missions happen at, but for defining a polygon of a country it wouldn't be as useful (think of all the points inside the border). Though we could use them to find the nearest city/point of interest and get the country from there, it would be a lot of extra data that we wouldn't need.

I'm gonna play with this and see what I can come up with. My ultimate goal is to make a function that takes long. and lat. as parameters and returns the country name (well the countries we're going to use, doubt we are going to keep track of every country in Africa) or Ocean (don't think we really need to know which Ocean do we?).

Also found this really easy: Determine if a point is in a polygon

PS. I know we are a bit a ways from needing this

#2 Lars W

Lars W

    Sergeant

  • Xenocide Programming Department
  • 21 posts

Posted 23 December 2006 - 01:27 PM

As far as i remember correctly there was the plan to paint a country-id-texture that matches our earth texture. Basically that would be a normal texture and each color represents a different country.

This would be very exact especially when clicking locations on the globe. Because i think our texture map is not very precise or even correct, but i am not shure about that.

The country would then be determined by doing a texture lookup (doing it the same way the graphics card does). We could also use this to determine in which kind of terrain a mission runs in.

But lets see how it goes, maybe your approach will be better, or maybe we have a online mode later which integrates Google Earth or so ;-)

greets lars

#3 Pi Masta

Pi Masta

    Sergeant

  • Xenocide Recruit
  • 68 posts

Posted 24 December 2006 - 12:02 AM

Does sound slightly easier, but I'd wonder about the speed of doing such a thing, especially having to find the color, not just where on the sphere it was clicked. It would be extremely accurate, I think I can remember a few times on the original X-COM I'd be zoomed in and it would look like the craft was over land but when I shot it down it would sink. Even if we go that route, we might be able to use these to help make such textures.

Google Earth integration would be cool, but definately post V1.

Now for my jabberin' :blablabla:

Anyways, I actually ditched that text file I linked above. Lot more problems than I thought it had (for one, there are Longitudes outside of the ranges (ie: -216). I understand it for countries like Russia that cross over the -179 to 180 threshold, but it would have made calculations complicated) I had found this shape file before that but it was in byte code and I didn't feel like guessing how it was formatted. Luckily I had found documentation on the structure of the document, and was tempted to try and parse it to a better form myself. But I found some C++ librarys and supposed Python package that links to it. Only problem is appearantly with Python's current build you have to have MSVC 2003 Pro to build, which I don't have (and is obsolete now too). I could get a 3rd party compiler but I had an alternative. The libraries came with some basic command line utilities for shape files (there's actually 2 other helper files as well).

With those I've extracted the data which does have the longitude bound and also includes Antartica. Best part is it also groups them into Countries and Regions which are defined in the seperate dbf file. I have a rough visualization of the shape file extracted from these utils (which gave me larger plain text files), but there's a few issues I need to work out. Unless someone else is interested in the details I'll spare you all from my blabbering.

We could also potentially get a shape or data file with terrian information, so we can distinguish between desert and forests. If nothing else I'm sure we could get elevation information which should provide a rough sketch.

#4 Pi Masta

Pi Masta

    Sergeant

  • Xenocide Recruit
  • 68 posts

Posted 24 December 2006 - 11:49 PM

Great news. I got the data from that shape file into python, and kinda got it to load up in the game and determine if the cooridinates line up. As far as I can tell they do! Near the shores and some of the really small islands it might not get, but otherwise it everything lines up (just a matter of converting from Radians to degrees).

I say kinda, because it is definately not a permanent solution. It reads it from ~4 Meg text file which takes python on my computer about 10 seconds to load into my polygon class I made. Also the file will need tweaking, for example the Great Lakes in the US are part of Canada and the Artic ice cap isn't in their presumably because it's not really land, however Antartica is there. Also, I didn't exactly 'overlay' the represenation onto the globe, though that is something I'll be looking into. So what I did was use the SelectTargetDialog (which works, just not implemented yet) and used python to determine the country it was in. And I checked several countries out and it seemed to get it right. Heck it even got Portugal, which insn't a very big country.

We will need to make changes of course with the countries. It has 209 contained in there, but it also classifies them by region. It shouldn't be difficult to 'merge' these countries together (if only we could do that for real in the Mid East :( ). Basically a country can have as many polygons as they want, which is useful for islands or for Alaska and US where there is a clear seperation. Also for Russia since the eastern tip crosses the -179 to 180 longitude. So we would simply just add the smaller country's polygons with the ones we are going to use. Hopefully this won't cause speed issues, as right now I have it set to see if a point is contained in any of the polygons (thus fewer polygons the faster it will run), so we could get a bit of a speed up if we actually merged the polygons themselves.

I'm assuming we are going to want to implement this in C++ as it obviously Model data. Fortunately, there are some libraries we should be able to just put into the project (under the MIT/LGPL licence). Then we can just simply use the shapefiles, as I'm sure it would be much faster loading, and we could probably find some useful GIS stuff in those libraries.

Shapelib - downloads

Shapelib is appearantly a subproject of OGR which we might be able to use just to tweak the shape file. (Should just need shapelib for the actual game, if we use it).

Everything is Open Source, so we shouldn't have any issues... I hope. Shape file is in PD I believe (I mean c'mon it describes the freakin world). ShapeLib is under the LGPL which from what I understand you can do just about anything except package and sell it as is.

Shapelib says it can't modify existing structures, but can create new ones. So we might be able to use it to read from this file and create a new one based on it, but with the changes we want.

Alternatively, we could possibly make a simplified text file with the polygon information. (The current one has some formatting that is useless because shp files can handle much more than just polygons). I mention this for moddiblity/globe generation. (I have this fantasy of using Xenocide for another game, where worlds are generated, as well as the battlescape maps). All this is possible with the shapefiles, it's an open format from what I can understand, but it needs special software. While a 4 meg text file with a bunch of longitude/lattidues isn't very human readable, but easy to make a parser for/make a generator for.

I'll probably look into this stuff some more, mainly seeing about getting shapelib (Should I talk to RK for this, or DTeviot and/or Reist?) added to dependencies or maybe the Base module. If not, I'll work on a simple polygon and country class with reading in data to use. Of course this stuff is low priority for now.

And Merry Christmas everybody!

#5 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 25 December 2006 - 09:48 PM

How to render the earth as a 3D sphere.

Basic process:
1. Generate a 3D mesh of triangles that approximate a sphere.
2. Wrap a texture onto the mesh.

How to generate the mesh (conceptually)
1. Visualise a sphere, centred at 0,0,0 radius 1.0
2. Now, map an octahedron onto the sphere, so that each vertex of the octahedron touches the sphere. (It’s a 3D shape made from 8 equilateral triangles. It looks like 2 square based pyramids joined at their bases.)
3. You can now tessellate each triangular face of the octahedron. (An equilateral triangle can be cut into 4 equilateral triangles by taking the mid point of each edge and joining it to the mid point of the other edges.) Note that we need to need to adjust the distance of the vertex (midpoint) from the origin so that the vertex will still lie on the surface of the sphere.
4. Repeat step 3, until you are satisfied the mesh is a sufficiently close approximation to a sphere.

The working is a lot easier if you do it in polar, rather than Cartesian co-ordinates.
In fact, you could do it in a simple loop.
1. Decide on the number of horizontal “strips” you want to cut the earth into between one pole and the equator. (You only need to calculate one hemisphere; the other can be obtained by reflection.) Number of strips must be a power of 2.
2. Calculate the first line of latitude, and mark out 4 longitudes. (This gives you 5 vertices, the “pole” and the “north”, “south”, “east” and “west” vertices.)
3. Now join the “pole” to the other vertices, and you have your first strip, composed of 3 triangles.
4. You now take the next latitude (the same step size), and double the number of longitude points. Just keep the existing set of longitudes, and add another one between each pair. This will give you a strip with 3 times as many triangles as the previous strip. Repeat until you reach the equator.

There’s one problem with the above plan, to tessellate equilateral triangles on a 2D surface (which the sphere will approximate, for sufficiently high numbers of triangles) you need 6 triangles to use each vertex. In the above example the initial vertices only have 4 triangles. I suspect that problem is solved if one starts with an iscohedron.

I think I need to do a bit of Googling – Buckmeister Fuller, and geodesic dome calculations

Wrap a texture onto the mesh
This is pretty simple.
1. Assume we’ve got bitmap that is an image of a conventional map. That is, rectangular. So, X co-ordinates are longitude and Y co-ordinates are latitude.
2. Then, if we have the latitude and longitude of a point on the sphere, we just look up the appropriate pixel in the bitmap and paint it on the sphere.
3. Now, when we created the mesh in the first step, we had to calculate the latitude and longitude of each vertex. So:
4. For each triangle in the mesh, we get the latitude and longitude of its co-vertices. We can then convert these directly into the X and Y co-ordinates of the bitmap. We then bitblit the texture onto the triangle.

Why am I discussing this here?
To debate should countries & terrain be modelled as polygons or as a bitmap?

My preference would be to use a bitmap. Advantages:
1. The data can be understood (viewed) by a person, making it easy to modify.
2. The existing data you’ve found, while it has country information, probably doesn’t have geography. (Mountain, desert, jungle, etc.)
3. The information can be mapped (as a texture) directly onto a globe. I doubt the polygons you have can be rendered directly. (The vertices may be out of order)

The disadvantage of a bitmap is that creating it might take a lot of work. (However, it should not take any special skills, just patience, and if you can find the right maps, maybe not even that.)

One final point, it occurs to me that converting a mouse click into a position on the globe is reasonably simple geometry. We know the earth’s rotation, (so we know the latitude and longitude for the center of the screen.) If we know the earth’s radius (in pixels) then converting screen co-ords to latitude and longitude is basic trig.

Edited by dteviot, 25 December 2006 - 09:49 PM.

Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#6 Pi Masta

Pi Masta

    Sergeant

  • Xenocide Recruit
  • 68 posts

Posted 26 December 2006 - 02:56 AM

Why am I discussing this here?
To debate should countries & terrain be modelled as polygons or as a bitmap?

My preference would be to use a bitmap. Advantages:
1. The data can be understood (viewed) by a person, making it easy to modify.
2. The existing data you’ve found, while it has country information, probably doesn’t have geography. (Mountain, desert, jungle, etc.)

...

The disadvantage of a bitmap is that creating it might take a lot of work. (However, it should not take any special skills, just patience, and if you can find the right maps, maybe not even that.)


Using bitmaps would be much easier, but we might need rather large ones to get precision (if we are very worried about that). The polygon files are extremely accurate with using floats.

Overall it probably would be better to get it to a bitmap, I think I can make a rendering from the current data I have. (I used Tkinter to draw polygons from it so I could see the result, to make sure it looked like the world.) We will still need some text files to convert the color at the bitmap to the country it should be associated with.

As far as terrain data, I think we are going to need a seperate file/bitmap. The only way around this is to assign a color per terrain per country. This will also make geographical features look weird when they cross a border as they would suddenly change colors (so as to designate the country). This is also true if we were to use the polygon files. If we combine country and terrain data into one file we will make it unnecessarily complicated, afterall nature doesn't care about political borders.

Here's what I'm thinking:
  • countries.jpg - image file with different colors used to define territory owned by a country
  • countries.txt - text file associating a color with a country name and probably a region as well
  • terrain.jpg - image file with colors representing different terrain. We could possibly even allow blending, and maybe pass that on to the random map generator for more varied environments (just a thought)
  • terrain.txt - like the countries text file, will link a color to a terrain type
Both text files could probably be merged into 1 with different sections as there shouldn't be too much data.

I doubt the polygons you have can be rendered directly. (The vertices may be out of order)

I didn't plan on rendering the polygons directly into 3D polygons, but rather rendering basically to a bit map or material at run time. Though it probably would be best to go ahead and render them and then load them. And you are right, some of the polygons are 'out of order'. Shape files allow for polygon's to define a hole inside another polygon by using the order of the verticies. It appears that this file I have uses them incorrectly on Austrailia, and Mexico (along with others), though it could be a problem with the function I used to check for such things (copy-pasted C++ code from a site and converted to python).

One final point, it occurs to me that converting a mouse click into a position on the globe is reasonably simple geometry. We know the earth’s rotation, (so we know the latitude and longitude for the center of the screen.) If we know the earth’s radius (in pixels) then converting screen co-ords to latitude and longitude is basic trig.


I had seen this as well and almost tried to come up with something to do just that. It will require some modification to the C++ class's, as I believe they don't store the current rotation. Also I'm not sure how easy getting the "earth's radius (in pixels)" would be. Though I believe you implied it, we need to know the current zoom, or distance from the earth. And it would probably be easier to figure out what percentage it covers the screen (which might be more than 100% if we zoom in a bit), and convert the X, Y co-ords of the mouse as a percentage as well. Frankly, I don't know how to figure out how much the earth covers the screen at zoom X.

Now for a little rant on the subject. Though I'm probably talking through my arse here as I'm not 100% on what I think is going on, so feel free to correct me.

It might be unecessary to figure this problem out, while interesting to me academically, it's basically re-inventing the wheel. We are using Ray-Tracing to figure out where on the globe it was clicked. I think that (read: I'm guessing that) a lot of 3D applications use lots of ray-tracing queries for complex objects. For example 1st-person shooters would use them to determine where a bullet hits an enemy, or an object. They would need to do this very fast with rapid firing guns and many people shooting in different directions. Thus if it's fast enough for them, I'd think it's fast enough for the occasional click from the user.

However, there is one caveat that might be in play here. In the example the people are relatively low polygon compared to our earth rendering as good spheres need lots of triangles. I'm guessing that these ray-tracing queries slow down quite a bit with polygon monstrosities.

Ok, actually I just thought of this. All of this reasoning is because I seem to notice a bit of a lag when getting co-ord's from the globe. If I remember correctly (too lazy to fire up Visual Studio right now), the code that convert's mouse clicks, actually creates a mock up globe at the same distance and runs the query there and then destroys the mesh. This is a lot of unecessary loading and unloading, even if there is a reason for not using the 'real' globe mesh on the screen, we should just keep this mock globe in memory until EarthScreen isn't needed any more.

Well its entirely too late/early for me to be up, but I think I might be able to fall asleep. (It's about 3 am here, so I wouldn't be surprised if some of this doesn't make any sense)

#7 Lars W

Lars W

    Sergeant

  • Xenocide Programming Department
  • 21 posts

Posted 26 December 2006 - 07:26 AM

Ok, actually I just thought of this. All of this reasoning is because I seem to notice a bit of a lag when getting co-ord's from the globe. If I remember correctly (too lazy to fire up Visual Studio right now), the code that convert's mouse clicks, actually creates a mock up globe at the same distance and runs the query there and then destroys the mesh. This is a lot of unecessary loading and unloading, even if there is a reason for not using the 'real' globe mesh on the screen, we should just keep this mock globe in memory until EarthScreen isn't needed any more.


Thats right, i use a fake globe, just using radius, no mesh involved, no triangles just simple ray-sphere intersection, that doesn't consume memory (only a vector for the position and a float for the radius). So it can stay as is.

If we then have the correct geocoords, it is easy to calculate the texture coordinates. you just need to look into the sphere generation algorithm. If you want it the most exact way (testing against the real sphere) you need to do a intersection test against the sphere mesh, to get the triangle and then find the exact texture coords. I once did this for a game and changed the texture at the position where an object was hit.
This runs very well for 1000 or even 10000 of triangles (the sphere is 1280 if i remember correctly). And we should not forget we are in very controlled environment. always only one large mesh, and collisions can only come from a mouse click.

I take that task officially, getting the texture from the current mouse pos.

greets
Lars

#8 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 26 December 2006 - 12:03 PM

Here's what I'm thinking:

  • countries.jpg - image file with different colors used to define territory owned by a country
  • countries.txt - text file associating a color with a country name and probably a region as well
  • terrain.jpg - image file with colors representing different terrain. We could possibly even allow blending, and maybe pass that on to the random map generator for more varied environments (just a thought)
  • terrain.txt - like the countries text file, will link a color to a terrain type
Both text files could probably be merged into 1 with different sections as there shouldn't be too much data.

Sounds good to me, only suggestion I would make is that we prefer the datafiles to be XML, rather than text.

Edited by dteviot, 26 December 2006 - 12:04 PM.

Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#9 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 26 December 2006 - 12:42 PM

:doh:
Here's my bitmap size calculation

Item 4. Implementing regions: possible implementation would be have a bitmap if it's 512 wide bye 256 high, then each pixel represents an area of 80 km per side at the equator. (12,756 * pi / 512) = 78.3 km.
Allow one byte for terain type, another byte for region/country and we have 2 left over for other purposes.


Edited by dteviot, 26 December 2006 - 12:42 PM.

Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#10 Pi Masta

Pi Masta

    Sergeant

  • Xenocide Recruit
  • 68 posts

Posted 27 December 2006 - 01:15 PM

Thats right, i use a fake globe, just using radius, no mesh involved, no triangles just simple ray-sphere intersection, that doesn't consume memory (only a vector for the position and a float for the radius). So it can stay as is.

...

I take that task officially, getting the texture from the current mouse pos.

greets
Lars


Ok, I guess I didn't realize that an Ogre Sphere isn't a mesh. I'm not too savvy with 3D graphics (atleast not yet), so I'm glad you're going to get the texture from the mouse position.

... we prefer the datafiles to be XML, rather than text.

Agreed. We could use one XML file and use different tags for defining terrain and countries. Guess that means someone will need to make a schema. I'll see about doing that.

:doh:
Here's my bitmap size calculation


Item 4. Implementing regions: possible implementation would be have a bitmap if it's 512 wide bye 256 high, then each pixel represents an area of 80 km per side at the equator. (12,756 * pi / 512) = 78.3 km.
Allow one byte for terain type, another byte for region/country and we have 2 left over for other purposes.

2 issues I can see:
  • I'm not sure if the bitmap is large enough. Again it is if we want it more precise. Those measurements give about 0.7 degree resolution (360 / 512 and 180 / 256) which might be noticeable. I know that using images with a power of 2 are needed for 3D textures, so we would only be able to go to 1024 x 512, which seems enourmous. Is it possible to do 'half' powers of 2 like 768x384?
  • That implementation would use one image for both country and terrain data. While efficient, it might look weird in an image editor. Like the Rocky Mountains from the US crossing over into Canada. Though I thought about this and it might not be too bad if we use large differences in values between the countries, instead of incremental values, ie use 12 for US and 32 for Canada instead of 1 and 2. I guess we can try and see how it looks. Possibly use two bytes for the country so we can use even more distinct colors for ease of editing.
Other than that, it looks great. I'll see about making such a bitmap from the file I have, though it has 209 countries. I think I'll use the list that the original XCOM used and combine the appropriate countries together.

For the XML schema I'm thinking of something like this:
<geodata regionfile='region.bmp' terrainfile='terrain.bmp'>
  <region name='North America'>
	<country name='USA' red='11'/>
	<country name='Canada' red='BB'/>
  </region>
  <terrain name='Mountains' blue='22'/>
  <terrain name='Desert' blue=11/>
</geodata>
Where regionfile and terrain file could be the same name if we want to use 1 data file, and red/blue are the hexadecimal values to match in the file.

#11 Lars W

Lars W

    Sergeant

  • Xenocide Programming Department
  • 21 posts

Posted 27 December 2006 - 02:30 PM

For texture viewing/creation, use a indexed fileformat like gif. They give you 256 totally different colors. They can then be converted into one png where one channel is country and the other is terrain.

And for the texture size if we look at the earth texture which currently consists of 20 texture files, each 512x512. Which is a about 2560x2048 (could be different proportion)

And it is called earth_lo so i would say take that as reference and do the size at least that.
Such a texture with 3 channels consumes approx. 16 MB uncompressed memory, so you can store 3 of these in a 64 Megabyte Card and still have space for the frame buffer.
We don't have any other textures in the geoscape then the ones for the globes and the GUI (1024x512 = 1536 kB), so no Problems there.

And if i think a second time we don't need the country/terrain texture on the graphicscard... maybe to show some highlighting or borders between countrys... but thats for later... we will see

greets
Lars

#12 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 27 December 2006 - 04:19 PM

For texture viewing/creation, use a indexed fileformat like gif. They give you 256 totally different colors. They can then be converted into one png where one channel is country and the other is terrain.

And for the texture size if we look at the earth texture which currently consists of 20 texture files, each 512x512. Which is a about 2560x2048 (could be different proportion)

And it is called earth_lo so i would say take that as reference and do the size at least that.
Such a texture with 3 channels consumes approx. 16 MB uncompressed memory, so you can store 3 of these in a 64 Megabyte Card and still have space for the frame buffer.
We don't have any other textures in the geoscape then the ones for the globes and the GUI (1024x512 = 1536 kB), so no Problems there.

And if i think a second time we don't need the country/terrain texture on the graphicscard... maybe to show some highlighting or borders between countrys... but thats for later... we will see

greets
Lars

Um, if the existing bitmaps are your stated size, then a 512x256 bitmap for country & terain would give us 40 pixels of texture for every 1 pixel of country. That is, a country pixel would equate to a 6 x 6 pixel square of texture. That should be perfectly adaquate for our needs. (The icons for craft and bases are bigger than that.)
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#13 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 27 December 2006 - 04:46 PM

I'm not sure if the bitmap is large enough. Again it is if we want it more precise. Those measurements give about 0.7 degree resolution (360 / 512 and 180 / 256) which might be noticeable. I know that using images with a power of 2 are needed for 3D textures, so we would only be able to go to 1024 x 512, which seems enourmous. Is it possible to do 'half' powers of 2 like 768x384?


Well, as I posted before, its not intended to be used as a texture, so we can scale it to please ourselves. If we do decide to use it as a texture, then we can rescale it.

<geodata regionfile='region.bmp' terrainfile='terrain.bmp'>
  <region name='North America'>
	<country name='USA' red='11'/>
	<country name='Canada' red='BB'/>
  </region>
  <terrain name='Mountains' blue='22'/>
  <terrain name='Desert' blue=11/>
</geodata>


Nice, one change I’d suggest is replace “red” and “blue” with “color”. The reason is that optional arguments make parsing harder.
It occurs to me that we can expand it for the future if we want.
We can add city locations to countries, and even other data: Mean and standard deviation for initial funding, cost to purchase a base etc.
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#14 Pi Masta

Pi Masta

    Sergeant

  • Xenocide Recruit
  • 68 posts

Posted 28 December 2006 - 06:05 PM

Ok I dived into this hoping it would be rather transparent, but I don't think it is. Here are some issues:
  • How many countries do we want to have? The original had 16, and I thought that it just lumped ground nearby into that country. I got to looking in the game, and I don't think it does this. Zoom in enough and you do see the borders of the countries, there are areas with no country name tagged like in Africa.
  • Do we want to assign every country to one of 16? What about the Antartica? Interesting thing I noticed was that there were still cities in these unclaimed territories.
My guess is to have some 'unclaimed' countries. We would need one for each region if we are going to have countries contained in regions (though technically this isn't true, Guam is of the US, but isn't in North America)), we will need an unclaimed Europe, unclaimed Africa, etc. Perhaps we need a seperate channel for regions?

If this is the case, it should make it easier. When drawing the polygons I'll just check if it is in the list of countries we want, if it is, use the color assigned, if not use the 'unclaimed' color.

I tried to look and see if there is a way of determining in the original what city a country belongs to. I haven't seen anything, but I haven't looked too hard. I'm hoping some X-COM uber-geek (like Zombie :P ) could shed light on this.

In the meantime I'll try this 'unclaimed' countries idea and I'll probably post up a Gif soon.
Edit:
Alright got it done. I'm not sure about India's borders, though. It might not be 100% accurate but should be darn close.

Interestingly it has one pixel of 'unclaimed' country in Italy, must be the world's smallest country where the Vatican is. Probably shouldn't have been drawn (doubt it's big enough), but the map was generated in alphabetical order and I guess every polygon gets atleast 1 pixel.

Black is ocean, gray is 'unclaimed'. All countries have unique colors, though some are close like Germany and Canada.

Now for the XML file/schema.

Attached Files


Edited by Pi Masta, 28 December 2006 - 06:42 PM.


#15 Lars W

Lars W

    Sergeant

  • Xenocide Programming Department
  • 21 posts

Posted 29 December 2006 - 02:47 AM

Um, if the existing bitmaps are your stated size, then a 512x256 bitmap for country & terain would give us 40 pixels of texture for every 1 pixel of country. That is, a country pixel would equate to a 6 x 6 pixel square of texture. That should be perfectly adaquate for our needs. (The icons for craft and bases are bigger than that.)


I also mislooked some things, its just 10 textures, not every face of the Icosahedron has its own texture, there are always two faces paired to use one texture.
But thanks to Pi_Masta the texture gets generated automatically from the polygon data, nice work by the way! so we can choose a size later on if we want to. And maybe we need more resolution if we raise the zoom-level for example, or want to draw Region/Country Borders with the same resolution as the texture map.

To retrieve the texture coordinates it seems to be enough to calculate a ray-icosahedron intersection, which results in 20 ray-triangle intersection tests. I hope i get that done till next week.

greets
Lars

#16 Pi Masta

Pi Masta

    Sergeant

  • Xenocide Recruit
  • 68 posts

Posted 29 December 2006 - 11:48 PM

Ok, here is a near-ready texture for determining terrain type.

There are a few issues of course.
  • there is no 'mountanous' terrain, just snow.
  • I had to 'fake' putting deserts in as the orignal data was concerned about vegetation so tundras and deserts were left marked as 'barren'. (Most of North Africa and parts of Northern Canada were marked this way, they both aren't tundra's and both aren't deserts) I got rid of the barren, and made them either snow or desert depending on the latitude.
  • It has rivers and lakes, but no distinction between it and oceans. Though the Political map I showed doesn't have any of these features so checking between the two won't be a problem except for determining the terrain of 'water' inside a country. Take the Amazon river for example. Yeah we might make it jungle, but then what about the Mississippi, there are no jungles nearby. Maybe we can settle for a 'river/lake-bed' type.
  • There are 5 types of forests defined, which makes for some pretty colors on the map, but I doubt we are going to have tilesets for all these, but I believe in the XML file we should just map them to the same terrain type. This way if we do decide we want to have a pine needle forest set and a broadleaf set we can easily do it.
  • This is more of a pro, the red dots on the map are Urban areas. I like this a lot, so that if you attack a craft landed at a city, we can get it to load a city tile set. While we might not list all the cities in this map for terror sites, it would be nice every now and then to have the city tile set load up instead of the usual farm one, even if no large city was mentioned on the geoscape.
If you're really curious as to what each color means:
(134, 201, 226), #water
( 33, 138, 33), #Evergreen needle forest
( 49, 205, 49), #Evergreen broad forest
(154, 205, 49), #Deciduous needle forest
(151, 250, 151), #deciduous broad forest
(143, 187, 143), #mixed forests
(187, 143, 143), #closed shrublands
(245, 222, 179), #open shrublands
(218, 235, 157), #woody savannas
(255, 214, 0), #savanna
(239, 184, 102), #grasslands
( 70, 130, 180), #permanent wetland
(236, 241, 131), #croplands
(255, 0, 0), #Urban and built-up
(255, 255, 255), #Snow and Ice
( 0, 0, 0), #Barren or sparsely vegetated
(134, 201, 226), #IGBP Water Bodies, should be 0
(255, 220, 0), #Desert

I can get higher resolution as well. The data file I made this from is 933 Megs (It's in raw form, every byte is a pixel).

XML
Well after I had made up an XML definition and all, I found that there already was an XML file for this called planets.xml. It went differently than the way I would have done it, and has the regions defined as polygon's (I shudder at looking at, editing, and parsing hundreds of points in XML). So I'm not sure if I should just adapt it to my model.
The main issue is that it has the capability of holding data for multiple planets. While this is nice, there is a lot of stuff to put in for a planet, terrain, political boundries, cities, funding info, base cost info, regions, etc. I think one file per planet should be enough. We can just tell the geoscape to load a different planet if we need/want to (post v1 of course).

Attached Files



#17 red knight

red knight

    Xenocide Project Leader

  • Xenocide Inactive
  • 3,310 posts

Posted 03 January 2007 - 09:56 AM

About the bitmap/polygon issues... Globe is bitmapped, the rest of the information it is better to be in polygon form. You can even work that out using multiple blended spheres, so you just hide or not the information sphere to render it.

Greetings
Red Knight
Sourceforge Nick: flois - Federico Andres Lois
Visit my blog at: flois.blogspot.com

Posted Image

Pookie cover me, I am going in.

#18 Pi Masta

Pi Masta

    Sergeant

  • Xenocide Recruit
  • 68 posts

Posted 04 January 2007 - 12:05 PM

About the bitmap/polygon issues... Globe is bitmapped, the rest of the information it is better to be in polygon form. You can even work that out using multiple blended spheres, so you just hide or not the information sphere to render it.

Greetings
Red Knight


What about editing? A list of polygon points is a lot harder to visualize/modify than a bitmap.

I'm not opposed to using polygons, but I'm not sure how to draw them onto a sphere. If I knew how to do lines on a sphere, it would probably be enough. Otherwise I'm thinking it would be easier to generate textures from the polygons at run-time and display them on a sphere.

One last comment, the terrain data I have is in a bitmap form (well sort of) and not in polygons like the countries. Of course I could look for terrain data in polygon form if need be.

#19 red knight

red knight

    Xenocide Project Leader

  • Xenocide Inactive
  • 3,310 posts

Posted 05 January 2007 - 05:05 PM

Depends, both formats are useful, the issue is how big it is in megabytes. Polygons are pretty efficient for queries and size, however they need extensive preprocessing (you wont create polygons in xml by hand). On the other hand bitmaps give you flexibility at the expenses of memory use. Given that, you should create a class with the simpliest version that could accomodate the change if needed and code the simpliest one. :)

Greetings
Red Knight
Sourceforge Nick: flois - Federico Andres Lois
Visit my blog at: flois.blogspot.com

Posted Image

Pookie cover me, I am going in.