Automatic terrain generation from geographical data (a tool I created)

[Easyscor]

Water is 165 feet wide while a ground type is 660 feet wide so painting a narrow river on a single texture won't work because a river will run in any direction. The terrain builder should choose how to deal with breaks in the rivers. With snow, and desert as well as ETO and PTO texture sets, Artik shouldn't be burdened with artwork. In truth, players will rarely notice or care about such a river break and will quickly dismiss it as unimportant.

Not @ Ranger lol:
I should think that anyone who appreciates Artik's work, and would like him to finish his tool, would not want to distract him with anything that might get in his way. Therefore it should be pretty clear that someone not trying to contribute in this thread or to its project must have a separate personal agenda of their own. Yes, I was in error about the ground type under water being grass but he'd already stated he wasn't going to choose that option.

[mrmidi]

Wasn't trying to be snark about anything, was just trying to make sure people where not getting incorrect information.

I to like what Artik is doing here. This will make for an awesome addition to the terrain creation tool box.

[ghostdancer]

I wasn't suggesting creating a texture with a river running through it and land all about in the same bmp file. I was suggesting setting the ground type below the river to river bed. Then a designer can replace the river bed texture (ntt0011.bmp) with something else that works better visually. It would be up to the individual designer to get artwork and decide what he thinks visually works. Artik's program would just set that track of river to land instead and make the ground type river bed (if he thinks 715 suggestion is worth further exploration ... river bed ground type would work better than the rock ground type that 715 suggest imo).

715 made a suggestion on how to handle rivers. Since Artik said he would consider it I added if he goes that route to be visually convincing to player flying over head they would need a land texture that looks like water even though it isn't. Personally I don't think it will add much to the experience (although I do find the concept intriguing enough to experiment with manually in the TE) and would say he just remove the river like he currently does via a variable in his config file and let designers decide what to do about directly in the TE.

Ultimately, it is Artik's program, he asked for suggestions and they were given (in this case a suggestion by 715). It is up to Artik about what wants his program to do (what new features), what advice or opinions he wants to take / finds valid, and what he considers a burden or not.

[artik]

I should think that anyone who appreciates Artik's work, and would like him to finish his tool, would not want to distract him with anything that might get in his way

Actually the most important thing for be besides many useful input - is actually testing to program, trying it and looking if there something that may be problematic.

Finally I do appreciate the suggestions even if they are "far going" as it gives me a bigger picture.

Bottom line, the most important help I can get is actually people downloading the program and Using It

Now to clarify all the non-clear stuff about the gndtype, waterd and boundaries.

I created two terrains, in one mixed ares of water-non-water marked with gndtype = water (left column) and other one with land (beach)...

I changed the graphics option from top to bottom:

1. Detailed water & Detailed terrain
2. Detailed water & NOT detailed terrain
3. Neither water nor terrain are detailed.



Now the biggest problem of having ground on the area where water should be is not seeing the water where it should be with low details. I used to fly till last week with the lowest detail to import the FPS. Now I understand why on MA I had seen an aircraft carrier floating over grassy area!!! On the left you can actually see the water.

For example, the P-51D shooting to the ground and see water splashes (3rd row at the right). Now what would happen if I would actually try to land there?

Now if I look on the first row - I actually like the way water looks in the left column much more - no unnatural gradient seen (square edges in the water) - but this is a matter of taste. The only case that I think having the ground type for water when you have detailed water but non-detailed terrain.

To be honest. I don't know what is better - as somebody who has a low grade graphics card I think that actually left column is better.

So... I made an option... what happens on boundaries of water and land. So user can set the option. The default would be the thing that happens on the left column - i.e. if there is a mixture it would be water.

[ghostdancer]

Doing a Halloween party tonight, so I will post up my testing results of the new program tomorrow.

So far as for 715's idea, I haven't come up with visually pleasing way (ntt0011.bmp) for land area connecting river segments via land textures that look rapids. Also as pointed out earlier the pixel resolution for waterd is different than for gndtype (165 feet per pixel in waterd and 660 feet per pixel for gndtype) which results in fuzzy edges. Which might not be to bad if you are thinking of the area as swampy or rapids or something with an ill defined water edge. Personally I haven't come up with anything I like (others might be fine with it, will post screen shots later).

You also have a good point on this that with details on this might be workable but with details off yeah, not so much. Good thing you pointed this out since I always fly with details on, so didn't even realized I had that bias.

As for the supplying the removed_rivers.bmp when that option is selected. After playing around with things I really like this featured you built in. I am able to see what the rivers would have been like and it makes it very easy for me to reconstruct just the bits I want that don't cause problems.

One thing I haven't gotten around to testing yet is the water width variable. If I set say the width to 3 pixels is it this width for the whole river? Or will it taper down to 1 pixel near the head waters of the river?

[ImADot]

Now if I look on the first row - I actually like the way water looks in the left column much more - no unnatural gradient seen (square edges in the water) - but this is a matter of taste. The only case that I think having the ground type for water when you have detailed water but non-detailed terrain.

I'm guessing the "unnatural gradient in the water" is because you have no water-texture version of the ground texture, so the blending is poor. Also, in the left one that you like, you see all that white ground around the edges of the river? That's the "deep ocean" texture, and is also probably why there is no gradient where the water meets the land.

[715]

Can you please give me the reference so I can read about it as well?

Also note - there is no correlation problems with shorelines (i.e. sea, lakes, isles)  the problem with the rivers that is a separate dataset in the same collection (GSHHS)

There is a document file (Product Specific Guidance v2.0 12 Mar 03jas.doc) added to every single SRTM water body data zip file (the vector data in shape file format).  There is also a much more detailed explanation in another file included with every shape file zip (SRTM Edit Rules v2.0 12 Mar 03.doc).  These both mention rivers as having 1 m "banks" as well as the DEM data being guaranteed to be monotonic for rivers (i.e. guarantees water flows continuously downhill).  (This second doc file is ridiculously large and it, rather than the actual shape file data itself, is what sets the size of the zip download.)

[artik]

So far as for 715's idea, I haven't come up with visually pleasing way (ntt0011.bmp) for land area connecting river segments via land textures that look rapids. Also as pointed out earlier the pixel resolution for waterd is different than for gndtype (165 feet per pixel in waterd and 660 feet per pixel for gndtype) which results in fuzzy edges. Which might not be to bad if you are thinking of the area as swampy or rapids or something with an ill defined water edge. Personally I haven't come up with anything I like.

To be honest I still have no idea how to implement. I need to think about some smart algorithm to make these brake points - i.e. how to select points that would be optimal.

I am able to see what the rivers would have been like and it makes it very easy for me to reconstruct just the bits I want that don't cause problems.

What exactly do you change to improve the situation?

One thing I haven't gotten around to testing yet is the water width variable. If I set say the width to 3 pixels is it this width for the whole river? Or will it taper down to 1 pixel near the head waters of the river?

The rivers are stored as set of lines so I don't know how wide the actual river is and how its shape changes. So when I draw the line of the river (i.e. rasterize a single line I add N additonal pixels on each side so if the river_width is 2 than actual width would be 1 pixel for central line and 2 pixels for each side so totally it would be 5 pixels width when I render the line. By default the value is 1 so the default river width is 3 pixels (i.e. line with)

It is not the best but I don't have too much information about exact river properties.

[715]

Doing a Halloween party tonight, so I will post up my testing results of the new program tomorrow.

So far as for 715's idea, I haven't come up with visually pleasing way (ntt0011.bmp) for land area connecting river segments via land textures that look rapids. Also as pointed out earlier the pixel resolution for waterd is different than for gndtype (165 feet per pixel in waterd and 660 feet per pixel for gndtype) which results in fuzzy edges. Which might not be to bad if you are thinking of the area as swampy or rapids or something with an ill defined water edge. Personally I haven't come up with anything I like (others might be fine with it, will post screen shots later).

Yeah, I had forgot about the different resolution for water and land.  How about just replace the too steep water pixel with the same land type as the surrounding terrain?  Would that blend in and not give a big blob breaking up a thin river, just a break in the river?

[Easyscor]

1. Detailed water & Detailed terrain
2. Detailed water & NOT detailed terrain
3. Neither water nor terrain are detailed.

There is yet another option you might check first.

4. Detailed water OFF & Detailed terrain ON.

This is my preference and it accomplishes the same thing. Furthermore, the terrain slider allows the user to fine tune the load on his graphics card.

We've all seen posted films of people flying with detailed terrain OFF and they are better able to track their bandits. My impression is that some of those doing this have sufficiently capable hardware but are seeking an advantage that negates aircraft skins and background (textures) noise.

For special event terrains like those being built for the AvA, a builder can actually defeat this advantage and force choice 4 with the color choices you mentioned early in this thread.

[ImADot]

Here's a sample I put together a while ago, from my Canyon terrain, showing different combinations of terrain detail. I used various textures around and under the water.

[ghostdancer]

Basically Artik I just do an abbreviated river. I just reconstruct the river  up to the point I just start to run into to many elevation issues that I think are to extreme (creating grand canyons). So basically I am able to reconstruct rivers that start at the foot hills of mountains and then run down a plain to the shore. I just do without the river part in the mountains.

I can't really think of anything you could do in addition to what you have already program since this is more of designers call of how deep a canyon he is willing to put up with.

[artik]

There is a document file (Product Specific Guidance v2.0 12 Mar 03jas.doc) added to every single SRTM water body data zip file (the vector data in shape file format).  There is also a much more detailed explanation in another file included with every shape file zip (SRTM Edit Rules v2.0 12 Mar 03.doc).  These both mention rivers as having 1 m "banks" as well as the DEM data being guaranteed to be monotonic for rivers (i.e. guarantees water flows continuously downhill).  (This second doc file is ridiculously large and it, rather than the actual shape file data itself, is what sets the size of the zip download.)

@715...

Note, I'm using GSHHS database, not SRTM Water Body Data - they are different databases. GSHHS is much easier to read/use. Its data is not split across hundreds of files. For example in GSHHS the Africa and Eurasia represented each one as a separate single polygon.

Also once you change the resolution of the elevations grid, you can not maintain the monotonic slope property of rivers.

There is yet another option you might check first.

4. Detailed water OFF & Detailed terrain ON.

This is my preference and it accomplishes the same thing

Interesting. I actually had found that detailed water has almost no effect on FPS, on the other hand
detailed terrain reduces FPS significantly. Also I must admit that I can see enemy planes much better
over detailed terrain. I can't explain why.

Basically Artik I just do an abbreviated river. I just reconstruct the river  up to the point I just start to run into to many elevation issues that I think are to extreme (creating grand canyons). So basically I am able to reconstruct rivers that start at the foot hills of mountains and then run down a plain to the shore. I just do without the river part in the mountains.

Actually it is very good way to reconstruct rivers...

Maybe I can automate this process. i.e. once I eliminated all rivers I start drawing each one from the from the bottom to the hill until I "hit the wall" i.e. when the corrections become too severe and than stop - instead of doing this manually.

It may actually work nicely and I think even better than what 715  had proposed.

And than if somebody wants mountain rivers can really add them manually.

[ghostdancer]

Okay been bouncing around and making test maps to see how things work. So far so good. I have made a map based on Manila, Stalingrad, Palopo (Celebes in Indonesia), Rabaul, etc.

No build issues so far. Although I do have to agree with you that when it comes to rivers and lakes you have to take things with a grain of salt because they don't actually sort of line up all the time with real lakes. Either that or some lakes have come and gone since the dataset was done. For instance the lakes up around Manila are good but when I moved down to the island of Negros there were some issues when comparing it against google maps. But then it did a good job on Mindano.

So my hunch is some areas have better info than others and that a designer really should double check lakes and rivers like your recommend. I think area 2 might me be river looping back and forth (when I went into satellite view I saw a lot of switch backs there and then it went into a stream).

Area 1 is bunch of marine ponds, its hard to make out the size exactly in satellite view but seems like things are a bit off.

Anyway just confirming what you already warned about, thought you might want to know that things seem fine in major areas just off in less develop areas you have to take with a grain salt. Your program is working great so far just the data is suspect in some cases.

#Manila
lat 11.3333
lon 123.0167
scale 1.0

[ghostdancer]

I also played around with the river width variable.


# Specify the width of the river in pixels
# ----------------------------------------
#
# river_width 1

I set it to river_width 4 which resulted in all rivers being 9 pixels wide on waterd.bmp. I was expecting it to be 4 pixels but what seems to have happened is that it took the original river (1 pixel wide) and then added 4 pixels to each side resulting in 9 pixels. Not sure if that is the proper behaviour / functionality but it wasn't what I expected.



Also the whole river was the same width. I did expect this but would probably go in after your program creates the waterd.bmp file and manually taper the river at its header waters down to one pixel to give it a better aesthetic look.