CFS3 map dimensions?

I'm currently researching certain ways to improve terrain and water rendering, not sure yet if anything good will come out of this.
One issue I came across: there's a cfs3h2o.dds file which defines sea color and covers the whole map (though it is flipped vertically). I need to find a way to calculate coordinates in this file based on world coordinates. Of course CFS3 already does it for its water, but so far I'm unable to reverse engineer that part.

For the stock CFS3 Western Europe I calculated that the map is a "square" (I guess the Earth if flat :) ) with a side of about 1560 km. However I don't know where this size comes from: is it hardcoded? Or is it somewhere in the game data?

I know there are other maps - Pacific Ocean and North Africa, but I don't have them installed and can't verify the size.
Are those maps the same size as the stock one? Or if they are different, what controls it?

The only remotely related thing I found is in cfs3europe.xml inside terrains\terrdata.zip:
<Terrain OriginLat="N48 0.0" OriginLon="E3.5 0.0" ...
These are indeed the coordinates of the center of the game map (SE of Paris), but I don't see anything about the map size.

I believe the terrain sdk has some of the information you are looking for. Not certain as I don't have access to it where I am. The number 1560 or perhaps 1535 seems to ring a bell. I suppose from there you have to divide the resolution of the water color texture by the size of the map, and using the origin you could calculate lat and long of any point on the sheet. Assuming everything has been flattened I think that would work, right? I'm very intrigued by this post to say the least!

I had come across these coordinates

N55 W7 4.5
N41 E14 4.5

for the total CFS3 map.

MAW and PTO are the same size,
different coordinates.

**It's in mapdata.xml file for each theatre.**

gecko, thanks, I forgot to look into SDK. It says that the stock map size is 1,572,864m. I'll try searching for this number in the game memory.
I don't even have to bother converting lat/lon into meters (CFS3 does this) or dividing by texture size (GPU does this). All I need is to know the maximum extents of the map in meters from its origin.

Since I want to be able to add water over any terrain I need to make sure it blends with the sea water and thus I need to know its base color from cfs3h2o.dds.

FireStorm II, if MAW and PTO are the same size I can just hardcode it (or put in the config at least) if everything else fails. Thanks!

I believe some maps might be a different size - Korea for example. This by the way might actually enable us to put real water in the Korea map after all these years instead of land painted to sort of look like water.

Also will the resolution of the cfs3h20.dds be able to be changed? I ask as I've put a decent amount of work into a very high res version that allows much more detail in water color.

As I recall, MAW’s map is as big as you can go.

The resolution of cfs3h2o doesn't matter. From DirectX perspective a texture coordinate is always a fraction between 0 and 1. That's why you can (in most cases) replace stock textures with high res ones and they just work.

Spent some time researching and it seems CFS3 does not calculate cfs3h2o coordinates at runtime, instead they are precomputed inside "hyp" files. I may be wrong but that's my impression so far.
In other news the Earth is not flat, but not too round either. According to SDK the water map covers 21 deg lon and 14 deg lat, but then it seems to be projected onto a rectangle (almost a square). Maybe it is Mercator projection, I'm not really familiar with details. So effectively the water map has slightly different dimensions that the "ground" map.

Anyway, I was unable to find anything to get the size directly, but I think I can calculate all I need by looking at coordinates CFS3 uses to render water. However, if Korea map has no "real" water at all it obviously won't work.
Another option is to add an setting in the ini for example to specify lon/lat coordinates of map boundaries, since now I know how they are used.

BTW, is my understanding correct that each theater requires a separate install of CFS3?

Quote:

---

Originally Posted by AnKor

BTW, is my understanding correct that each theater requires a separate install of CFS3?

---

Effectively yes, technically no - it depends on how you look at it. The current PTO has several theatres crammed into one install with a batch selector launching it and activating the correct files for the chosen theatre. Hence the "effectively" - you can't have them active at the same time, exiting CFS3 is required to change theatres. Technically they're in the same install though.

Thanks. I guess it is quite inconvenient, but it makes things easier for me (it is always like this :) )

I think what they did for MAW was "squeeze" the operational area into the maximum map size.
Actual Lat/Lon coordinates of landmarks/cities correspond very well with ETO coordinates, but the MAW coordinates are a bit off.

hi Ankor, a chap named Rob Bruce used to run a blog about is terrain creation efforts for CFS3.

These comments may be of use/interest for you:
"Creating a terrain mesh for CFS3 is relatively easy once you have source dem data. I use a spreadsheet to calculate the approximate bounds of the terrain data. The only numbers that ers2tiff.exe requires is the theatre origin, image pixel dim, image stride, max height, outX1, outY1 (terrain extents) and the number of images in the X and Y axes. The ers2tiff tool calculates the actual extents and theatre boundary from this information. This tool will automatically clip the supplied terrain to the appropriate size given the theatre minimum extent and the theatre origin.

In CFS3 geographical co-ordinates are relative to the theatre origin i.e. the theatre centre. The terrain SDK provides example parameters of minimum co-ordinate extents of the output data, in meters relative to the origin. The SDK further states that extent of the default ETO theatre is the rectangle (-786432,-786432) to (786432, 786432). However the output parameters that ers2tiff produces using appropriate dem data are (-786432,-786432) to (785408, 785408). (785408, 785408) is the north east co-ordinate of the terrain boundary in meters relative to the theatre origin. 785408 is 1024 meters less than 786432. In other words it truncates the data by approximately 1km in the North East. Further tests reveal that regardless of minimum terrain extent or theatre origin, the tool always outputs terrain extent parameters with the the NE parameters being 1024 meters less than the SW. I don't know whether this is a bug or by design. I do vaguely recall reading posts of a 1km srtm terrain bug in FS2004 & maybe FS2002, in forums in the past - maybe it's the SRTM data"