Terrain Painting and Saving!

[Gumboots]

Found a handy resource. The bloke who posted this has an index of his free greyscale height maps in his sig.

[Hawk]

How would those png grayscale maps be converted to the blue and red required for RT3?

[Wolverine@MSU]

How would those png grayscale maps be converted to the blue and red required for RT3?

The blue/red aren't required for RT3, they just offer better resolution. For the grayscale maps, just convert them to TGA and they should work fine. Grayscale gives 256 different levels of elevation, which for most terrains should be sufficient.

[Hawk]

Thanks Wolvy.

Did you get your problem straightened out, or are you using a different computer?

[OilCan]

Found a handy resource. The bloke who posted this has an index of his free greyscale height maps in his sig.

The terrain painting post and the above post are very interesting...and could prove to be very useful. I was amazed at the number of heightmaps already available on his site. Wow.

[Hawk]

I was amazed at the number of heightmaps already available on his site. Wow.

I played around with a couple of them (well, 4 actually). Still trying to figure out the height modifiers, mountain heights and smoothness.

[Gumboots]

I tried using his Australian one (bet you're all so surprised, right?). It seems to work well, as far as general topography goes, but I have noticed one problem. The contrast between the lowest areas of the coast and the pure black oceans was too much, and resulted in quite sizable cliffs where there should have been beaches.

The easy way around that is to colour pick the darkest area of the coast (#0e0e0e in this particular case) and then choose a shade which is only slightly darker than this (I used #0c0c0c). Then, select the black ocean using a very tight colour variance restriction (I think 20 is the lowest in PS). This is to stop the fill bleeding outside the strict selection and onto your coast. Get your bucket tool and click once only to fill the oceans with the new colour (all the trendy people know that #0c0c0c is the new black ).

This gives your image a new default baseline to work from so you wont get cliffs on your beaches. The editor will stil be looking for a pure black baseline, so you need to give it one. Select a small corner of the map that has ocean on it. Can be only 20px square or whatever. Fill that with pure black (there's a trick here). Save as png-24 if using Photoshop, becuase the editor (or at least my one) doesn't seem to like Photoshop's .tga's (I suspect PS compresses them by default).

Open the .png in GIMP (horrible thing to use, but good for this) and export as uncompressed .tga. You now have a map that shouldn't give your editor indigestion.

Import this wonderful concoction into your map editor, go find that little sunken square of "ocean", and use a large brush and the plateau tool to make it all good. The ocean can now be treated as a big lake (do NOT use the ocean tool on it, use the lake tool) and everything will be fine.

================================

Anyway, about smoothness etc. I found that for a 512x512 map of NSW (basically the same land area as the PopTop "South East Astralia" map, but at about 50% larger scale) and using this guy's greyscale image as a starting point, on overall height modifier of 0.5 gave very good results. I left the other modifiers (mountain tops and smoothness) at the default setting of 1.

This all worked well for this particular map. Looks very realistic, as far as topography goes. Some exaggeration, which can be tweaked in places, but overall feel is great.

Bear in mind that Australia is, in general, very old and very very eroded. The smoothing has already been done by millions of years of weather. A map of the Himalayas would probably need different treatment to make it playable.

ETA: I chose 512x512 just to make the resulting map easy to handle for on-screen viewing, rotation, etc. I like to be able to get an overview of the map easily. It just so happens that I made a lucky choice there, because according to some posts I was just reading the 1.39 miles/pixel that RRT3 assigns to maps gives a map scale for NSW that is very close to the truth on 512x512. I'll do a bt more checking, and then maybe resize the map so game distances are the same as real ones.

[nedfumpkin]

If you colour the ocean as pure red (255-0-0) then mapmaker will put in the oceans for you.

[Gumboots]

I've given up on that guy's maps anyway. Got myself a copy of MicroDEM.

[Wolverine@MSU]

I've given up on that guy's maps anyway. Got myself a copy of MicroDEM.

Good move Gumboots. I know the Tutorial on MicroDEM is somewhat dated, and there is a rather steep learning curve, but once you've mastered it, it can provide excellent heightmaps. It's been a while since I used it, and they've probably updated it. If you have any questions about its use, I'll try to answer them.

[Gumboots]

Thanks. So far, so good. I did have a bit of grumbling and swearing at first, but it wasn't that hard to figure out the basics. The tutorial that WP&P wrote is still largely accurate, although the MIcroDEM interface has changed a bit and some options have moved. Also, the recommendation to install his special table of elevations still applies, but I didn't install his "update" in the same zip since the tutorial (and therefore the update) was written for a much older build than the current one. I was going to do an rewrite of the tut for the few places where it needs it. Most of it still applies though.

[Hawk]

I was going to do an rewrite of the tut for the few places where it needs it. Most of it still applies though.

That would be cool.

[Gumboots]

Hey I just ran a test to confirm something about terrain painting and saving.

Story is that after finishing the scripting for my Royal Tour scenario, the gfx were in bad shape of course. So I went over them and fixed them up. Then, when I played the scenario again, the gfx started degrading during gameplay. All the blue bleeding around rivers, etc came back, even though it was ok when the game first started.

Now being a lazy sod, I wasn't really keen on copying all the custom scripting over to a fresh PopTop SE Australia map to rebuild the scenario again. OTOH, I hate crappy gfx too. So, I ran a test.

What I wanted to find out was whether or not the PopTop map degraded during gampelay too, and I'd just never noticed. Having just run it through a 25 year scenario (not doing anything much with the company, and game on high speed, just as a basic test) the gfx were fine at the end of the 25 years.

Contrast this with the gfx in my version, which had been saved dozens of times during testing/debugging. No matter how well I touch it up before saving it, and no matter how good it looks at the start of the game, within about ten years of gameplay all that bleeding will be back and as bad as ever.

Conclusion is that once a map's gfx are borked, it's permanently borked, and touching it up in the editor wont do you any good. As soon as someone plays through it, they'll have the crappy gfx again.

This is something I had noticed with maps from the archives here, but at the time I hadn't paid much attention to it. I'd just assumed the author had done a bad job and not touched it up after testing, and that I hadn't noticed until part way through the game. I'm now pretty sure that they had touched the map up after testing, but unfortunately, as I've just found out, this doesn't really help.

So, it seems that if you want the map to look good, and to stay looking good while someone plays through a standard length scenario, there's really only one way to get that result. You'll have to have a fresh copy that has only ever been saved once, and you'll have to transfer all your custom coding and gfx work to it in one save, or at the most two saves.

So, as much as I don't like it, that's what I'm going to do.

[Gumboots]

Update. Just been doing some more degradation testing.

Starting with a fresh map that's had the satellite image put on via bmp2gmp. After 4 saves and reloads, the textures in general are fine (may not be as good after forty saves though). There might be slight texture degradation after four saves, but if there is it's very slight. The problems seem to happen at river and ocean edges.

Oceans are obvious. Rivers are a bit trickier. With a maximum sized river (brush size 7) it will start to get the nasty blue bleeding after the second save. The bleeding after two saves isn't huge, but if you're looking for it is quite discernable. With the maximum size river though, the bleeding will be mostly within the river itself. This means it tends to be less noticeable.

With a minimum sized river (brush size 1), it will also start to bleed after the second save, but the bleeding will be outside of the river itself, and going up the banks. This stands out more.

It seems that the bleed radius/width is determined by blocks/pixels/whatever coded into RRT3, rather than by the brush size selected to create the river. So, it makes sense to make your rivers as wide as possible, without making them look stupid, if you want to minimise the bleed problem after multiple saves.

The next thing to try was to take a save that had the bleeding (I used a fourth save, not second, for this), use a brush to paint over it, all along the river (I used "smooth desert plain" at full opacity) and see what happens. Obviously it totally covers the bleeding while you are doing the painting. However, after only one save, the bleeding is already coming through to some extent. After two saves, it's about as bad as if you'd never tried to cover it up.

This ties in with what I found from my saved-to-death development map. If there's something nasty you're trying to cover up, it will still be hiding there even if you can't see it after you just painted over it, and will come back really fast if given a chance.

I had a cunning thought. Seems to me that if you know you're going to have to save a complex map several times, simply because there's no other practical way of getting that scenario finished, the way to do it would be to not put your rivers in while working on it.

You could lay them once, just so you have the channels sorted, then set them back to land. This should mean no bleeding problems. When development/debugging is finished, switch off the "change height" option and just put the river back in the existing bed. Haven't tried it yet, but it should work.

Could do something similar to stop oceans bleeding up beaches. Set them back to land for a constant width (2 or 3 blocks, or whatever it needs) then do all the testing. Once it's all sorted, reinstate that width of ocean again. All the old bleeding should be nicely and conveniently drowned.

[Hawk]

So, it seems that if you want the map to look good, and to stay looking good while someone plays through a standard length scenario, there's really only one way to get that result. You'll have to have a fresh copy that has only ever been saved once, and you'll have to transfer all your custom coding and gfx work to it in one save, or at the most two saves.

There's actually two other options you can ponder.

1) Don't do any terrain painting until you have all the scripting done.

2) Every time you save, save with a different name, such as map, map1, map2, map3, etc.

It seems the terrain painting degradation only happens when you keep saving the map with the same name.

[Gumboots]

1/ Not practical in the case of oceans, because the height map will be generated with oceans already in place. Oceans cause the bleeding problem too. That's why I was thinking of manually knocking them back for a few blocks during testing. Doing that would be easier than getting rid of the whole ocean, then having to reinstate the whole thing again.

But let's face it, testing a map that has no terrain painting at all is going to be a pretty grim process. Tress and such seem to be fine. They seem to always be called straight from their default image files according to placement, so there's no problem putting in stuff like that. It's mainly rivers and oceans that really give trouble.

2/ I was saving with different names. That's how I kept track of my examples. It makes no difference, nor should it make any difference. It's just a lossy image algorithm, like .jpg or any other lossy algorithm. What you call the file doesn't matter. The thing that determines the result is the amount of information available in the existing file, and the amount that will be dropped by the algorithm with each save.

If anyone has tried saving with different names and thought it made a difference, I'd be calling "confirmation bias", or "cargo cult programming".

[Grandma Ruth]

I had a cunning thought. Seems to me that if you know you're going to have to save a complex map several times, simply because there's no other practical way of getting that scenario finished, the way to do it would be to not put your rivers in while working on it.

You could lay them once, just so you have the channels sorted, then set them back to land. This should mean no bleeding problems. When development/debugging is finished, switch off the "change height" option and just put the river back in the existing bed. Haven't tried it yet, but it should work.

As far as I recall, and it's been years since I did anything with RT, cargo flows along the rivers. So if you made the rivers back to land, wouldn't that stop the flow and alter the gameplay whilst you're testing?

[Grandma Ruth]

and why is my "quote" not working????????

[Wolverine@MSU]

and why is my "quote" not working????????

Probably because you either deleted, or forgot to put in the "[/quote]" after the quotation?

[Hawk]

and why is my "quote" not working????????

Probably because you either deleted, or forgot to put in the "[ /quote]" after the quotation?

Yep! That's what it was.
I fixed it.
I also removed that light blue color. It was too hard to read.