New capability (of GeoRealism): Water Body Recognition

This is a continuation of the thread that was entitled "Discreet Oceans and Ocean Naming"

The capability of separating water areas into oceans has expanded to FULL water body type recognition and separation. So we have grown beyond oceans... hence this new thread.

This thread is for discussing this new capability, its progress, and its uses and implications. The first successful tests (two of them) have been completed. See the third post for results.

Was just today wondering how this project was going for ya. Cool to see you're back at it

I have successfully completed two tests. Two versions of the maps are shown below.

Both of these maps were created using the archipelago (snaky continents) map script on gigantic(?) size. Currently, this happens to be my favorite script. Sorry about the low quality pictures but I had to get a size big enough where the numbers were drawn and then shrink the quality down until I got a file small enough to upload...

TEST 1

First is the large body map. This shows the major bodies of water that were separately identified in different colors:


NOTE: smaller bodies that appear in the second map below have a separate body id (the number). However, smaller bodies are linked to the larger bodies shown in the above map by the large body ids. (There are more ids in the next image).

Second is the body detail map. The numbers shown here are small body ids (where applicable). This image is color coded by the body type:

DARK BLUE = OCEAN
TEAL = SEA
VIOLET = GULF
BLUE = BAY
LIGHTER BLUE = STRAIT
LIGHTEST BLUE = LAKE




TEST 2
Same format as above...


First is the large body map. NOTE: I just figured out why the red "small body" zone is not attached to an ocean. It is because the only body it is adjacent too is a polar body of water which is treated as a minor body until the very last step. I will have to fix this.



Second is the body detail map. The numbers shown here are small body ids (where applicable). This image is color coded by the body type:

DARK BLUE = OCEAN
TEAL = SEA
VIOLET = GULF
BLUE = BAY
LIGHTER BLUE = STRAIT
LIGHTEST BLUE = LAKE


NOTE: There is a small problem that appears in this map but it is minor. Straights are not supposed to have bays that span the same width sandwiched between the bay and the main ocean but because I also test for gulfs using the number of border plots vs the number of body plots the one in the upper right corner managed to slip through the cracks. I will have to base it on adjacent land area id when I fix this issue.

The next step will be to try different types and sizes of maps and iron out any bugs that appear.

P.S. Is there away to scale the above pictures using bb code so that they are smaller? If not, use the attachment list to see the whole picture at once.

Very nice and very promising results.

Looks like a very good classification.

While the above results were fairly good, there are some issues with the posted maps and more that I found trying it on one other map. As I tried to fix those problems, I came to realize that it is impossible to do using the old algorithms.

The bad news is that I am having to rewrite over half of the code into new algorithms.
The GOOD news is that the new algorithms are 5-10 times as fast (because there is far less searching going on). The details are below.

The final runs that created the above maps took nearly 1.5 minutes. I only have the area merge and finalization methods left to write. Simply put, I am around 70% done the rewrite and what the new code accomplishes so far originally took about 1 minute using the old code (and then over half a minute to merge and consolidate areas). Now the same result takes less that 10 seconds! The final outcome should not take more than 20 seconds.

Awesome Prime! I was wondering how this was going and I'm glad to hear it's coming along nicely. You've had a lot of setbacks but you always come back with something stronger as a result of them.

Assuming this entire thing gets implemented, we need to discuss the relevance this has to area generation and the current problems I have heard about in WorldBuilder.

As far as the generator/simulation engine is concerned, there is a difference between "region" and "area." Each will be a separate class within the DLL. However, the difference will be invisible to the player and most of the standard functioning within the original body of the DLL. This makes the relationship between areas and regions very important to establish.

FIRST: A description on how the "Ocean" generator divides and classifies "water" regions.

The new implementation goes through a series of smaller and smaller, hard defined (based on map size) "distances to coast" spawn values and creates separate water bodies based on these values. The details of how they are grown and eventually combined are probably not important to this discussion but when all is said and done, there are three (or four) major types of water bodies (based on the spawn values) that will remain:

• Tiny (bays, and small gulfs)
• Medium (larger gulfs and seas)
• Large (Oceans)

The "fourth" one will be polar bodies since technically they have to be treated differently than the rest. However, when it comes to the way they are viewed post-processing, these will be treated as either medium or large bodies depending on how they are classified by the engine (as based on size).

One important thing that needs to be considered is that "tiny" regions will be sub regions of medium and large ones. In other words they are assigned to be part of medium and larger regions.

So now we come to the big question. How should we define areas? Large only (in which case I would need to link medium to large areas)? Medium and Large? or should we treat every single region as a separate area?

Seeing your Straits, it gave me an idea. What if we had like a special Amphibious II promotion that was only for explorer units to cross straights? Note it would be a very high tier promotion.

Likewise it might be cool for a special "Ice Walker" promotion for only explorer units that allows units to travel on Ice Sheets. Maybe make it require Amphibious II and Arctic Combat III.

What do you guys think?

Hydromancerx said:

Seeing your Straits, it gave me an idea. What if we had like a special Amphibious II promotion that was only for explorer units to cross straights? Note it would be a very high tier promotion.

Likewise it might be cool for a special "Ice Walker" promotion for only explorer units that allows units to travel on Ice Sheets. Maybe make it require Amphibious II and Arctic Combat III.

What do you guys think?

Click to expand...

Swimming and Ice Walking... yeah cool I like it! Not sure if we're coded to be setup for it or not but I like it

Well if you get icewalking then you'll have to deal with the black border of the north and south edges.

Civ Fuehrer said:

Well if you get icewalking then you'll have to deal with the black border of the north and south edges.

Click to expand...

It does not seem to be a problem when you have land at both poles.

Dancing Hoskuld said:

It does not seem to be a problem when you have land at both poles.

Click to expand...

Or send submarines under the ice sheets.

I suppose so - but I just find the borders a rather ugly aspect of the game... Ever since Civ 1.

Dancing Hoskuld said:

It does not seem to be a problem when you have land at both poles.

Click to expand...

Actually... this brings up another topic that I would like to put forward (and I also would like some feedback on the whole area vs region issue).

Poles. Currently, the game does not produce land at the poles. This is understandable considering the fact that distances are so distorted and "strange" if you think of the world as spherical rather than flat. Making them into an impenetrable ocean helps get rid of some of that because it provides a convenient way to avoid those issues.

However, when dealing with the code involved with GeoRealism engine, always treating poles as oceans has advantages and disadvantages. When representing the Earth itself (or an earthlike planet) it is a disadvantage because the "ocean finder" methods rely heavily on distance to coast lines which in the past has made separating the Indian ocean from the Atlantic ocean a real pain since the Antarctica is helpful in providing a "barrier." I had to change Laskaris' ice plots in the south to land in order to get it to work right (which is what they should be anyway).

SO the question arises. Do we still want the poles to always be oceans? I have made allowances for either situation in the code. However, the ocean separation is still going to be an issue if no land exists to the far south and we nave another situation where one ocean relies on polar land to keep it separate from another ocean.

I think land should be allowed at the poles. I have no problem with the edge of the map at the top and bottom. Not counting flat maps, we are still dealing with cylindrical maps rather than spherical, so map distortion is not really an issue.

So what... we randomize whether the territory beyond the polar cutoff is land or water?

primem0ver said:

Poles. Currently, the game does not produce land at the poles.

Click to expand...

I don't understand this. In about half my games I have land at one or both of the poles. U have even had two continents stretch pole to pole completely separating the oceans. It made circumnavigation very hard

Thunderbrd said:

So what... we randomize whether the territory beyond the polar cutoff is land or water?

Click to expand...

No no we assume that whatever type of terrain land or sea is touching the polar edge that behind that edge is the same type of terrain. In other words the "pretend" terrain on the otherside of the looking glass in a mirror image of what terrain is generated at the edge.

0 = Ocean
# = Land

0000000000000000
------------------ North Polar Edge
0000000000000000
0000000000000000
0000000000###00
0000000#####000
------------------ Equator
0000########00
00000#######00
000###00####00
0###0000###000
------------------ South Polar Edge
0###0000###000