Infinite height?

Crash

04-06-2008 15:26:22

Hi,

I tested out ETM and in my opinion it fits perfectly into my project! The only really annoying thing is the maximum terrain height of 1. I commented out the following code part in TerrainImpl::setHeights and TerrainImpl::deform:

if (height > 1)
height = 1;
if (height < 0)
height = 0;


and it works perfectly. The only thing which might not work correctly then is the heightmap export function. But I think that shouldn't be the problem:
Iterate all vertices and compute the maximum height. When writing to the image, divide the current height by the previously computed max height. The result is below 1 ;)

I think that might solve the problem.

Squirell

04-06-2008 16:15:20

There is a better (more standard) way of doing what you are trying to do. Use TerrainInfo::setExtents. You can set the y-component (height) to whatever your heart desires.

Crash

04-06-2008 20:11:11

hm that's true but with setExtents you can only scale the entire terrain. But the user of the map editor doesn't know what the maximal height will be later on.

Squirell

05-06-2008 01:26:33

I think the difference between the two methods can be summed up as relative vs. absolute. Your system is absolute, mountain A has a height of 4 and mountain B has a height of 8. Mine is relative, mountain A has a height of .5 and mountain B has a height of 1.0. I scale it then by a 8 and achieve the same results as you do.

I think one advantage of the relative system is exporting/importing heightmaps. Like you said, you can convert everything into the 0-1 range (that's called normalizing) and export but how will you know what the original height was when you import again? With a relative system where you always set the extents to be the same that isn't an issue.

But it really doesn't matter. If you can make your system work more power to you.

Crash

05-06-2008 19:27:25

I think the difference between the two methods can be summed up as relative vs. absolute. Your system is absolute, mountain A has a height of 4 and mountain B has a height of 8. Mine is relative, mountain A has a height of .5 and mountain B has a height of 1.0. I scale it then by a 8 and achieve the same results as you do.
Jep, thats it exactly ;)

I think one advantage of the relative system is exporting/importing heightmaps. Like you said, you can convert everything into the 0-1 range (that's called normalizing) and export but how will you know what the original height was when you import again? With a relative system where you always set the extents to be the same that isn't an issue.

I export the maximal and minimal height as well and put them in the terrain info file. For the relative system I would have to save the scale of the terrain as well.

CABAListic

05-06-2008 20:56:22

I can see why you are interested in absolute heights, but I'd rather not change the current system.
Still, I think just setting the y scaling to very high values would give you what you want. If you use a very small brush intensity, you could basically edit the terrain "without limits", the internal heightmap would usually be very small then. You'd just have to normalise it as mentioned before saving it.

Crash

10-06-2008 13:53:24

I found another problem: In the current implementation negative heights are not supported.

CABAListic

10-06-2008 15:34:34

Well, as said, internally all height values are in the range [0;1]. But since you can map (scale) them to anything you like... just start your heightfield with values of 0.5, set large extents as you see fit, and you can effectively edit the terrain in either direction.