Terrain Prototype

[Paranoid Android]

This is really good, uzurpator.

I'm sure we can get round the lack of perfectly flat land. Such as, if you build a piece of track it will automatically level the tile it's on to the right level.

[Shrimp]

Wow, that's really good Usurpator. I really like this. I haven't played with it (still too much work, that's why I was away for the last months) but does it have variable zoom that would increase/decrease the polygon count accordingly? And generate only the portion of the map you need for the point of view?

I'm asking because if this is fast enough, the map doesn't need to be actually stored as tiled information, thus saving LOTS of memory. Of course the polygons take space in the videocard memory, but the program can access directly the height information from the function you use to generate the map so the main memory isn't bogged down with that (also meaning that map size is not limited by memory). But of course, it depends on the speed of generation (the usual tradeoff).

Am I making any sense?

[uzurpator]

Well - For now I can display any patch from a map up to 3500*3500 tiles. But I'm using a very wasteful storing method (each tile has 4 vertices stored as float value - thus 24 bytes per tile for geometry alone) - thus lots of memory can be reclaimed.

If we dropped the requirement for cliffs then I could reduce the amout of memory by about 75%. If I stored the vertives as (short int) I could reduce the memory requirement 12 times. From 25 MB to 2.1 MB form 1024*1024 patch.

ATM the proto displays and makes patch of 100*100 tiles. But for example 2000*2000 map with 50*50 display works perfectly well.

It is really slow for now. But I'm planning to use vertex/color/normal buffer which shuld increase performance about 3-5 times. The polycount is actually neglibly small - most of the time is wasted on calculating normals and moving data to all 4 adjectent vertices (one more point for dropping cliffs).

Flyby/Zoom proto is planned once I get my life a bit straightened out.

[jfs]

Hmm I don't know if this is just a bad idea or if it'll actually work.
But I just though of storing a height-map in a fashion similar to the I/P/B frame scheme used in many moders video codecs. It should allow for storing much larger heightmaps.
First of all (not directly related), there shouldn't be any need for using floats for heights, even with just a 16 bit unsigned int, there would be 65536 different height levels, which should be plenty. Now, using my scheme, it might be possible to raise that to a 32 bit int without using too much memory.

Basically, it's a kind of difference-coding. The full height-value is only stored for some points, while most of the points store only the difference between itself and its neighbors.
The most effective coding might result if only one reference-point (one of the corners, or the center) was stored for the entire map, but that would be horribly ineffecient. So instead there is a "reference-grid". There is one point on the reference-grid for each 8 or 16 points on the real grid. (This is just along one axis, of course.) The height of an R-point is stored as a 32 bit unsigned integers.

Now, while writing this, I realise it probably won't work when the landscape is modified, but I'll attempt to continue anyway
The data in between R-points are byte-packed, meaning a D-point (delta-point) will take up 1, 2 or 4 bytes. How much is decided by a kind of prefix-code of the highest bits. (This requires the data to be stored as big-endian. Damn you Intel )
A D-point always uses single-directional prediction towards the R-point, because if the datastructure was corrupted, a bi-directional coding could possibly result in infinite loops or other nasty things. I'm not sure if anything could be gained from introducing a BD-point type (bi-directional delta), but I doubt it.
Now, to the problem: When the landscape is reshaped, some of the values might flow outside the possible range of their coding-size, and data would have to be moved around. That could result in massive moves of memory or reallocations. Bad.
Also, the data would have to be transformed into full uncompressed heightmaps before any work could be done on them anyway. It might not be much of a gain then.

Now, IFF there was no possibility of ridges AND the max slope was limited, a similar system, but with fixed D-point byte-lengths could be possible.

Comments? How many other faults did I miss?

[eis_os]

Don't store the heightmap in floats, that isn't a good idea I think. While the fpu are working better and better you need additonal time to put stuff in it and out it...


Well, I fast read your idea, some point I see:

Let's say you want to calculated the height of a train to ground, say it's currently on slope and you need to know how much the code needs to reduce speed.
Normal way:
find the square of it, get the height, compare the difference = result

Compressed:
Find the square, get the compressed height, get the reference / grid height, calculate it, compare with the height of the train = result.

Well, and it really depends how you will do tunnels after all. The tunnel could be under the max. And how tiles will work after all...

[SHADOW-XIII]

if you ask me,
widths can be integers, but height can be byte, 8bits is enough for that
however that applies is we stay with tile system

(sorry for posting something that was already but I just started to following this section, I'm thinking the project's going to be interesting and worth doing)

[Monti]

Hello,

I think we need the following things to evaluate it as a base framework for the final game:
- we need a fast demo with 1000x1000
- adding a zoom function (should be easy)
- adding different textures
- animation (eg. water, woods and so on)

monti

[PJayTycy]

height can be byte, 8bits is enough for that

I don't agree. 256 heights is not enough. If we use 1 train height = +/- 10 landscape heights, 256 height levels would compare with 25 height levels in TTD.

16 bits would be more than enough anyway.

[Jpl]

The demo runs slowly on my Pentium II 350 MHz box with voodoo3 2000 graphics card. I'm trying to do some optimizations to the code and I'll post a message if I can get it faster.

[uzurpator]

...

[uzurpator]

...

[PJayTycy]

The screenshot looks nice.

Can we see the code ?

[uzurpator]

Not yet. I'm working on adding mouse support and some variety to the generated terrain (Deserts and alike).

Then I want to add basic GUI and land modification tools.]

Where is Hellfire?

[PJayTycy]

Where is Hellfire?

Aren't you both working on the design document ?

[Zuu]

Hellfire said something some time ago aout that he had things to do. I think it was with the orchestra. I have seen him on MSN a few times, but I havn't talked with him. But if not eaven Uz have heard from him, I can ask him next time I see him.

[uzurpator]

Aren't you both working on the design document ?

We were - But I haven't heard from him for quite some time now (over a month or so) - and I'm not doing the job myself - as much I'd love to, I cannot let my personal opinions shape the DD.