HMap fixing

[Fatal]

I am also referring to the last few posts of the following page: viewtopic.php?f=1&t=15480&start=40

So, I'm pretty much set with my map, except that kbots can climb some cliffs they aren't really supposed to. I've increased height differences in the compiling phase, but I think I've gone as far as I can with that one. The actual HMap needs some fixing.

Now I ask you, what brush/filter/effect do you generally use on these cliffsides that need to be steepend or made more gentle? The rest of the HMap seem fine, but there are just a few problem spots that need fixing up. I think that smudge tool would be a good choice for steepening, but I want to hear what you people do when you need to alter cliffside steepness.

Also about the compiling. What does it mean to compile using 8 bit vs. 16 bit HMaps? I reckon it's a question about the colour depth of the HMap, but please, elaboration.

[Warlord Zsinj]

Don't forget that in different mods, different units may have varying climbing abilities.

For example, in my mod, Imperial Winter, our infantry can climb most steep slopes that most kbots would struggle with.

I'm not aware of differences, but it could well be that kbots in say, AA or CA are able to climb different slopes to those in BA.

IIRC there is a way to indicate a section of map as impassable 'void'. I think muffdvr used this on his the pass map (From memory)...

[Fatal]

That sounds an interesting option indeed, and would dramatically help in the future. If someone has information about this feature, please do tell. I just want that no ground units, walking or driving alike, get past the cliffs. Air units are a completely different matter, though.

However, as there are instances where I'll be featuring all terrain KBots as well, I need to learn how to do this the proper way as well.

[caldera]

perhaps you can have a look at the ooooweeee-cloud map which noize pubished recently. there seem to be many regions nobody can reach...

[smoth]

IIRC there is a way to indicate a section of map as impassable 'void'. I think muffdvr used this on his the pass map (From memory)...

we have that?!?! cool.

[Pxtl]

Don't use it unless you're using it on something that should be really, really, really impassible (like a hole in the world, or lava, or something). Hell's Pass used Void on the mountaintops and it was really confusing for players who used spiders - sure, it makes sense that a mountaintop be impassible to normal units, but many mods have all-terrain units that are expected to be able to climb any terrain that is not obviously impassable. Using void for those cases violates the principle of least surprise for players.

And yeah, this feature is way old. Hell's Pass was a fun map, though - good for teaching players to ignore the choke-point and go for the airdrop.

[Beherith]

The messy workaround is using the typemap and setting all units speed on it to 0

[Fatal]

Yeah, I figured out the part about the all-terrain units. Also I found that the smudge tool is great for fixing cliff steepness either way, to make it more gentle or steep.

Now my only confusion lies in the 8 bit and 16 bit versions of heightmap and compiling. Any info regarding these? RTFM? RTFG?

Also I now realise that I posted this thread in the wrong forum in the first place. I blame silly forum descriptions. :p

[Beherith]

You posted in the right forum.

So, 8 and 16 bit

In order for 8 bit heightmaps not to look like aaviko, you have to use the -l mapconv options, which is a lowpass filter and it removes a bit of fine detail from your heightmap. If you use 16bit, the resolution is fine enough not to use -l, thus retaining full detail of your heightmap.
Best way to find out is to test it for yourself, as its worth more than 1000 words.

[Fatal]

But how do I switch between them? All I have is 0-255 greyscale (changed to 24 bit bmp later on) HMap, in texture resolution/8 + 1

Just a short description of what this all is about is enough.

[Beherith]

In photoshop, go to image/mode and select 16bits per channel greyscale mode.

An 8 bit greyscale image, when used as a heightmap, can only represent 256 distinct height levels. Now if your map has a height difference of 500, then you get 1 level per 2 height units, which will be a very quantized (eg. terraced) result if you dont -l smooth it. When switching to 16 bit, you have 65K different height levels, so your slopes will be much finer. Unfortunately switching to 16 bit too late may not help, as you would have to blur the image a bit to make use of the extra resolution.

[Fatal]

Ahh, I wasn't aware of such a greyscale palette. Thanks for clearing it up.

[Forboding Angel]

In order for 8 bit heightmaps not to look like aaviko, you have to use the -l mapconv options, which is a lowpass filter and it removes a bit of fine detail from your heightmap.

Beherith, please read my posts on this page as well as the page after (there are only 3 or 4). Aaviko's look is intentional or a newbie made the heightmap.

Edit: Quick note, Beherith is right about the greyscale pallete. But using -l is a good idea anyway, regardless of 8 bit or 16bit heightmaps.

[smoth]

No be is dead on and you are incorrect forb but only because you misunderstand what be is trying to say.

256, 16, 24, 32 all still use the RGB 0-255 8 bit range for colors. This is 8-bits per channel.

What be is talking about is 16 bits per channel, this produces arguably levels of grey that the human eye would be hard pressed to even tell apart.

[hunterw]

almost nothing can open a 16 bit greyscale

i think the gimp can tho

[smoth]

cs3, terrain editors etc

[SirArtturi]

almost nothing can open a 16 bit greyscale

i think the gimp can tho

I think that almost every can open 16-bit greyscale (meaning of course that its right fileformat)

I think that gimp has most problems opening 16-bit's... Can't handle .raw for example...

I've found .png the most usefull for 16-bit greyscales, although you need keep in mind that for compiling you may need to change it .raw...

[Forboding Angel]

No be is dead on and you are incorrect forb but only because you misunderstand what be is trying to say.

256, 16, 24, 32 all still use the RGB 0-255 8 bit range for colors. This is 8-bits per channel.

What be is talking about is 16 bits per channel, this produces arguably levels of grey that the human eye would be hard pressed to even tell apart.

And you are completely oblivious to what I said. Try reading next time.

[smoth]

I like your reply both condescending and aloof, good times. I read your posts and found them both wanting.

[Pxtl]

GIMP does not support 16-bit/channel images. If you want a F/OSS app for that, you have to use Cinepaint (a fork of a paleolithic version of GIMP) or Krita (a KDE app).