Map format to support 16 bit heightmap?

TradeMark · Post by **TradeMark** » 15 Mar 2007, 10:14

256 heightlevels is just too less. Is it possible to make more than 256 heightlevels with the current map format?

It is impossible to make high maps with just 256 levels, terrain becomes unpassable and ugly.

BoredJoe · Post by **BoredJoe** » 15 Mar 2007, 23:02

i'm pretty sure heightmaps are 24bit.

smoth · Post by **smoth** » 15 Mar 2007, 23:05

bored, 24 bit doesn't matter. because each channel is coposed of 0-255 colors. Which means we have a 256 color range for black and white. The color system uses the old 8bits per color system.

what trademark is asking for support for 48bit images with 16bits per channel... not happening(find another format like terragen or leveler) btw... but anyway.

BoredJoe · Post by **BoredJoe** » 15 Mar 2007, 23:12

smoth wrote:bored, 24 bit doesn't matter. because each channel is coposed of 0-255 colors. Which means we have a 256 color range for black and white. The color system uses the old 8bits per color system.

what trademark is asking for support for 48bit images with 16bits per channel... not happening(find another format like terragen or leveler) btw... but anyway.

yeah, i realised after posting what was meant :/

AF · Post by AF » 15 Mar 2007, 23:13

I think instead we could do with sub sampling as in a general heightmap, then passing smaller images that specify areas of the heightmap in greater detail between 2 heights. Itd just need mapconv patching.

BoredJoe · Post by **BoredJoe** » 15 Mar 2007, 23:19

a solution could probably be made so that say green/red/blue channels could also be used seperately in mapconv. So you could have grayscale/green/blue/red each having their own custom heights for the heightmap, meaning there would now be 1024 seperate heights possible : P

smoth · Post by **smoth** » 15 Mar 2007, 23:20

I think we need to use a format that one of the major terrain programs uses like terragen or leveler... hell even a 16bit raw.. I do not care.. but doing funky stuff with extra heightfeilds or even using several channels as was suggested over a year ago are out of the question.

We need to go with a major supported format because we do not need to make maps EVEN HARDER to make...

one of MY pet peves is that we have to scale the heightfield and add 1 onto it.. that is asinine imo...

BoredJoe · Post by **BoredJoe** » 15 Mar 2007, 23:24

smoth wrote:one of MY pet peves is that we have to scale the heightfield and add 1 onto it.. that is asinine imo...

i never understood why that was done, why doesn't it scale directly?

Post by **Kloot** » 16 Mar 2007, 00:35

Post by **jcnossen** » 16 Mar 2007, 01:43

one of MY pet peves is that we have to scale the heightfield and add 1 onto it.. that is asinine imo...

I would think someone doing a major in CS could figure that out :) Any game uses heightmaps with non-even resolutions like spring.

Neddie · Post by **Neddie** » 16 Mar 2007, 03:24

jcnossen wrote:
one of MY pet peves is that we have to scale the heightfield and add 1 onto it.. that is asinine imo...
I would think someone doing a major in CS could figure that out :) Any game uses heightmaps with non-even resolutions like spring.

Well, nobody is perfect. Specialization generally leads to some missed data. Hence why I decided to not even try to master one section.

zwzsg · Post by **zwzsg** » 16 Mar 2007, 09:32

Afaik the map conv of old already supports 24 bits heightmaps. It's just hard to find an image editor that do 24 bits smoothing of a grey picture. Also, possibly, it use red+green+blue, and not red*65536+green*256+blue, which basically mean you don't have 2^24 height levels but less.

As for the +1, it makes perfect sense. Just look at a microsoft window logo: it has four area, but nine nodes. It's the bidimensional version of the good old problem of "If you plant a post every meter, how many do you need for a 5 meters fence?"

smoth · Post by **smoth** » 16 Mar 2007, 11:29

jcnossen wrote:
one of MY pet peves is that we have to scale the heightfield and add 1 onto it.. that is asinine imo...
I would think someone doing a major in CS could figure that out :) Any game uses heightmaps with non-even resolutions like spring.

I Have yet to write a program the reads in a heightfield and generates a mesh from it. Not something we do at uni, but it seemed odd that the data needed to have the actuall dimensions +1 pixel.

Tobi · Post by **Tobi** » 16 Mar 2007, 14:46

It's a cornerheightmap, ie. the height is specified at each corner of the quads.

2x2 squares gives 3x3 corners/nodes/whatever.
4x4 squares gives 5x5 corners
etc.

Would it have been a centerheightmap, then the dimensions would be even. But then spring would have to do quite some inter/extrapolation magic to calculate the cornerheightmap from this (because that one's needed to render the quadrilaterals).

KDR_11k · Post by **KDR_11k** » 16 Mar 2007, 16:52

Wel, you could theoretically use the centers wiothout interpolation but that wouldn't be pretty because then the quad edges wouldn't fall exactly on the footprint edges of buildings which would complicate the terraforming.

Tobi · Post by **Tobi** » 16 Mar 2007, 17:01

Plus you have to draw a half quad border on the edge of the map then (or the actual in game map will be smaller then the texture etc.), just complicating matters.

Weaver · Post by **Weaver** » 16 Mar 2007, 23:44

The height map is stored at 16bit resolution, if you can create a 16bit grey scale raw image then you can compile with it. Normally if you use an 8bit height map it wise to set the lowpass filter as you will avoid some steppiness.

The other source of steppiness is a limitation of the engine. As it renders those corners to the nearest heightmap unit. So if your map is only 300 units high you will only get 300 different height levels. This really only visible when the sun is set very low.

MadRat · Post by **MadRat** » 18 Mar 2007, 06:40

What happens when you set the last pixel around the map to a level much higher? I'm guessing that won't work as the sun will get blotted out by the tall sides.

Forboding Angel · Post by **Forboding Angel** » 18 Mar 2007, 07:26

TradeMark wrote: It is impossible to make high maps with just 256 levels, terrain becomes unpassable and ugly.

No it's not. Take a look at 40% of my maps. Look at iron gauntlet. Divided shores dry. Mountain range. Industrial mountain.

I'll give oyu a bit of a hint. Use a program like l3dt to redraw the heightmap for you in 32bit, then save as bmp (loses 32bitness, but that's ok), the run the lowpass filter in the compiler and you're home free

TradeMark · Post by **TradeMark** » 18 Mar 2007, 11:06

Hmm, you used only 256 height levels in those maps? Looks like there is more than 256 height levels...

But if i want to make some really high maps, which includes deep water, i need even more height levels.

I remember one map called "king of the hill", it had so ugly heightlevels, that i could see them from far away, i took some screenshot:

In that map one height step is 30 degree angle.

Spring RTS Engine

Map format to support 16 bit heightmap?

Map format to support 16 bit heightmap?

Re: Map format to support 16 bit heightmap?