Geo Realism: Discussion on a new SDK based map generator

[ls612]

Thanks. The geologic time table is much too slow for the a game that only spans 50,000 years or so. Therefore it is unnecessary. However, weather/climate changes during the game are being planned for.


@ls612
LOL. I am just getting started the actual engine. Laskaris is working on filling in the climate data necessary for the biomes/climate determination. Hopefully he or someone else can take care of most of the xml changes from here on out. I will take care of ones that I need to deal with but some details can be filled out by others.

As of writing this I am working on the base calculations for temperature wind characteristics for each latitude (almost done). I will probably do the climate engine first so that we can start testing its ability on real Earth maps to improve its accuracy.

I can understand how big of a project it is. Great work so far in the design though, I have to say it has really grown on me.

 

[Michkov]

Do you take into account the creation and destruction of plates over the course of time. Or are you just moving and reshaping predetermined plates around?

 

[primem0ver]

Do you take into account the creation and destruction of plates over the course of time. Or are you just moving and reshaping predetermined plates around?

The quickest answer to this is posted in my description of how GeoRealism engine will work in post #177

6. Every so often the climate simulator, the drainage simulator, and a plate change simulator (to randomly determine the change in direction of or creation of a new plate) will update other geophysical data.

As stated above, simulation of new plate generation will occur. I have not decided whether or not to include plate disappearance. The problem with this is that if done we won't be able to get away with a simple queue of new crust created and moving outward from the divergent margin. We would also have to take plate drift into account (which doesn't always happen practically speaking).

In actuality, plates do not quite move the way it is taught in school (or as is planned in this mod). They spin around an axis. Sometimes that axis is on the fringe of the plate. Sometimes the location of the axis changes. The purpose of the mod is to reproduce realistic landscape and climates with geographically realistic features, not to simulate plate tectonics as accurately as possible. So I will only go far enough to produce realistic results (which is already obstructed by the fact that the map is not truly a sphere).

 

[Dancing Hoskuld]

One thing that would be nice would be for the game to know which continents were which - sort of. This is for animal spawning so that we can have an Australia and New Zealand if possible. The regions used for tectonics may work but this needs some thought and discussion.

 

[rightfuture]

Could be potentially useful for climate modeling
article on ancient lake changes
http://www.sciencedaily.com/releases/2012/09/120927144234.htm

 

[primem0ver]

I have encountered a problem in calculations that I want opinions on; especially from Laskaris since this is caused by "his" baby.

If we use equal area latitude line divisions, the plots are not equal in area. The problem with this is that the simulator simplifies climate calculation by using "micro" air masses the size of a single plot and moving them from plot to plot according to the prevailing winds (and other factors) more or less as they would in the real world. We then use the statistics of the air mass to calculate the weather and climate of each plot.

Using this method we encounter a problem because the area of each plot changes when doing an equal area map. The masses of the air AND moisture in the air are calculated characteristics of the micro-air mass based on the volume of air, evaporation rates, and relative humidity (and other factors). Hopefully you can see the problem as we move into a plot that has a different volume (due to the change in area) and hence... a different total mass of air (and moisture).

The question is... how do we compensate?

 

[Thunderbrd]

Can't say I understand the problem conceptually enough as it gets into the level of science that I'm unaware of.

But I've been wondering about the progress here and I'm tickled to death to see you're making significant forward strides here! Looking forward to this!

 

[primem0ver]

Can't say I understand the problem conceptually enough as it gets into the level of science that I'm unaware of.

But I've been wondering about the progress here and I'm tickled to death to see you're making significant forward strides here! Looking forward to this!

It's slow going considering I have a HORRENDOUS amount of math to figure out... much more than I originally anticipated. Take a look at my list of equation functions alone that is only 2/3 done the climate part. (from: CvGeoRealismEngine.h)

Spoiler :

public:
	float calculateSurfaceTemp(int fTemp);
	double calculateCoriolisEffect(int iLatitude);

protected:
	double calculateDailyEvaporation(double dTemperature, double dRHumidity, double dWindSpeed, int iY);
	float calculateLiftCondensationLevel(float fTemp, float fDewPoint);
	double calculateLiftCondensationlevel(double dTemp, double dRelativeHumidity);
	double calculateBuckHumidity(double dTemp, double dRelativeHumidity);
	double calculateSimpleDewPoint(double dTemp, double dRelativeHumidity);
	double calculateAccurateDewPoint(double dTemp, double dRelativeHumidity);
	double calculateWindCoefficiency(double dWindSpeed, int iY);
	double calculateVaporPressureDelta(double dTemperature);
	double calculateZeroPlance(double dWindSpeed);
	double calculateRoughnessLength(double dWindSpeed);
	double calculateSaturationVaporPressure(double dTemperature);
	double calculateUnitKilogramVolume(double dTemperature, double dPartialPressure);
	double calculateSpecificHumidity(double dTemperature, int iAltitude, double dTotalAirPressure);
	double calculateAirPressure(double dTemperature, int iLatitude, int iAltitude);
	double calculateGlobalPressure(int iLatitude);

 

[Thunderbrd]

I know how that goes. I ought to share the full list of Combat Mod tags one of these days. whew!

But then again, the math gets ridiculous for you in complexity comparatively. I do think, however, that's a big part of what's going to make what you're doing all the better.

 

[Laskaris]

If we use equal area latitude line divisions, the plots are not equal in area. [...]

Using this method we encounter a problem because the area of each plot changes when doing an equal area map. [...]

I am not sure I understand the problem. In an equal-area projection, every plot does have the same area. That is the very point of an equal-area projection.

Can you elaborate again what the problem is?

Generally speaking, I don't insist that we use "my baby", the equal-area projection. You were the one who originally made the suggestion that we use my Gigantic Accurate Earth Map as a yardstick for the climate engine. In reply to this, I pointed out that my map uses an equal-area projection, so if we want to use it as a yardstick, the climate engine would have to be able to produce equal-area projections as well.

 

[primem0ver]

I am not sure I understand the problem. In an equal-area projection, every plot does have the same area. That is the very point of an equal-area projection.

Can you elaborate again what the problem is?

While this is true on an equal area map projection, the "plots" on such a map are NOT of equal size on the map. Look at the map that you provided for the Biome file discussion again:

Notice that while each square on the map is of the same area, the squares on the map are NOT of equal apparent size. The squares get smaller as one moves toward the poles. Notice how latitude distance between lines decreases as one gets closer to the poles. The 30 degree parallel is half way up from the equator on the map even though in reality it is only a third of the way in real life.

Civ4 plots don't work this way. All Civ plots are all of equal apparent size which means they are NOT of equal area if one is using an equal area projection. If one uses an equal area projection, the area of land bound by a single plot increases as one moves toward the poles. The equalization of area on a equal area map comes in the spacing of latitude thus changing the size of squares to become smaller as one moves toward the poles.

Here is a specific example of how this changes things depending on which type of projection is used. The code from the SDK that I have added to calculate latitude is as follows:

int CvGeoRealismEngine::getMapLatitude(int iY)
// returns the map latitude based on map Y position and type of map
{
	int iResult = 0;
	int iHalfHeight = m_pTheMap->getGridHeightINLINE() / 2;
	bool bEvenPlots = ((m_pTheMap->getGridHeightINLINE() % 2) == 0);
	double dMaxSin = sin((double) MAX_LATITUDE);

	// first determine where we are relative to the equator:
	// if we have an even number of plots we need to increment  
	// a non-negative result so that our result cannot be zero
	iResult = iHalfHeight - iY;
	if (bEvenPlots && (iResult >= 0)) ++iResult;

	// now figure out our latitude depending on which type of map
	if (m_bEqualArea)
	{
		bool bIsSouthern = (iResult < 0);
		if (bIsSouthern) 
			iResult = 0 - iResult;
		// calculate the position in degrees
		iResult = (int)((asin((double)iResult / (double)iHalfHeight * dMaxSin) * 180.0 / 2.0) + 0.5);
		if (bIsSouthern)
			return 0 - iResult;
		else
			return iResult;
	}
	else
		return MAX_LATITUDE * iResult / iHalfHeight;
}

Notice the two different algorithms in calculating latitude depending on whether an equal area projection is used. If m_bEqualArea is NOT used (false), the else statement is executed, returning a latitude that is directly proportional to the Y position. If m_bEqualArea is true, then we must use a non linear relationship based on the arcsin (to determine the angle) of the Y distance. This is why the squares (plots) get smaller as you move toward the poles on an equal area projection. Latitude lines become closer together as you move towards the poles.

However, in Civ, the plots are ALL evenly spaced (and sized). This means that a plot's actual contained area will increase as one moves toward the poles on an equal area projection map.

Generally speaking, I don't insist that we use "my baby", the equal-area projection. You were the one who originally made the suggestion that we use my Gigantic Accurate Earth Map as a yardstick for the climate engine. In reply to this, I pointed out that my map uses an equal-area projection, so if we want to use it as a yardstick, the climate engine would have to be able to produce equal-area projections as well.

True. Ok. It's not your baby in that sense. Its just that I like the equal area projection map... gives a nice undistorted look that portrays the size of the continents fairly well. However, as we have just seen, the distances themselves going north to south are distorted.

 

[primem0ver]

Does anyone know if there is a way to alter the width of code blocks in bb code? I don't like the whole need to scroll horizontally.... really dumb IMO. The code block only uses half the page!

 

[Laskaris]

While this is true on an equal area map projection, the "plots" on such a map are NOT of equal size on the map. Look at the map that you provided for the Biome file discussion again:

Notice that while each square on the map is of the same area, the squares on the map are NOT of equal apparent size. The squares get smaller as one moves toward the poles.

I see. But here, you are not talking about the plots. You are talking about the latitude lines. They are indeed unevenly spaced out on an equal-area map. However, they are not identical to the plots on a Civ map.

We get the plots by simply putting a grid over the equal-area projection, like this:

This would be a very rough world map, of 48 x 24 plots. Because the underlying map projection is an equal-area projection, all of the red squares have the same area - and also the same air volume above them, for your climate engine.

Now, the complex thing with this projection is to tell the program where the latitudes are. What latitude is y=2? What latitude is y=13? That is what we would have to do with equations.

 

[ls612]

@primem0ver:

Have you profiled this code at all to see if it scales at all? Or are you not at that point yet?

 

[primem0ver]

I see. But here, you are not talking about the plots. You are talking about the latitude lines. They are indeed unevenly spaced out on an equal-area map ... Because the underlying map projection is an equal-area projection, all of the red squares have the same area - and also the same air volume above them, for your climate engine.

Now, the complex thing with this projection is to tell the program where the latitudes are. What latitude is y=2? What latitude is y=13? That is what we would have to do with equations.

The problem is (or at least what was throwing me off was) that latitude lines are evenly spaced in mileage. Each line of latitude is 69 miles from the next line no matter where you are on the globe (unlike longitude which changes). If you are changing the distance then the area changes as well. UNLESS the longitude distance gets smaller to compensate. I guess that would make sense though since we are drawing squares where the width doesn't change as we get closer to the poles. In real life the distance between longitude lines gets smaller as we get closer to the poles. I suppose that is why it works the way you say.

@ls612
No, I am not profiling any functions. I am not really sure how that works and the programming isn't far enough along to do it yet. I don't anticipate the climate part of the engine being testable until mid December at the earliest. The algorithm is about half done (after starting 2 weeks ago) but then I have to be able to jurry rig a way to test it and that will be the hard part.

THEN we will have to do the geology part. I anticipating that taking at least twice as long since it is far more complex in terms of programming. While there is a lot of research and math that go into the climate engine, for the geographic part we have to add edge and path finding in order to create the plate boundaries.

Finally there will be drainage to worry about. I anticipate that taking some time to figure out as well.

 

[primem0ver]

@Everyone
The above comment at ls612 brings up another point. What do people think of releasing the georealism engine in stages? I anticipate the climate/biome engine being fully functional by the end of January. The rest however will probably another 3-4 months or more depending on my going back to school. Should we add each stage as it is ready?

 

[Dancing Hoskuld]

Having it released in stages has the advantage of people getting used to it and providing feedback on it.

 

[Hydromancerx]

Having it released in stages has the advantage of people getting used to it and providing feedback on it.

I agree.

 

[ls612]

Having it released in stages has the advantage of people getting used to it and providing feedback on it.

Yep, assuming the stages are each balanced in isolation that should be fine.

 

[Laskaris]

UNLESS the longitude distance gets smaller to compensate.

Yes, that is exactly what the equa-area projection does. As you go from the equator to the pole, the north-south distances get more and more extremely squashed, but at the same time, the east-west distances get more and more stretched out. As a result, the surface areas underneath all the squares, if you put a square grid over it like I did above, are all exactly the same.

In regards to helping the climate engine find the latitudes: if we do use an equal-area projection as one option, my suggestion would be to use one specific one, with standard parallels at, say, 37.5 degrees. And then, it's fairly easy to calculate what latitude corresponds to which point on the y axis, and just put that into the program as fixed values.

Do you plan on the climate engine to be able to work with maps of any size, or will there be only a couple of set map sizes, like 48 x 24, 80 x 40 and so on?