Heightmap continuity

OK, I’ve got a height map that is broken into numerous (hundreds) of pieces. Each piece, called a sector, is a 16x16 vertex square of heightmap data. Each sector is centered around the origin.

I know that OpenGL doesn’t guarentee that the edges of two polygons will be perfectly colinear unless they share binary-identical vertices. Since each sector will be transformed into its own position via a translation component, how do I go about getting the sector edges to match up perfectly? If they didn’t have that translation, they would be the exact same binary-identical vertices. However, once the translation is involved, they are no longer guarenteed to be colinear.

How should I go about solving this problem?

Originally posted by Korval:
Each sector is centered around the origin.

If you are translating pieces like that you are always going to have precision problems.

Why do you need to translate each piece individually? What makes this “translation component” so special?

You need to change the data on load.

What I’d suggest is center all data around the center of the square that the camera is currently over when loading. When the camera moves far enough from that square for your comfort, you re-center and re-load all blocks. You may wish to do that in the background, and swap out all geometry at once once it’s all done, to avoid a large frame rate stutter.

Yes, this mechanism temporarily requires twice the amount of storage. That’s the price of perfection.

Another alternative would be to quantize X, Y and Z to some specific resolution inside a vertex shader, using mul, floor, and mul of the inverse. That will do a “snap” of vertices to each quantization “bin” which should get them all to be coincident if they’re close enough.

Why do you need to translate each piece individually? What makes this “translation component” so special?

Because the world can be arbiturarily large. I’m planning on streaming data off of the disk. Float’s tend to lose precision when they become too big. Also, read below.

You need to change the data on load.
What I’d suggest is center all data around the center of the square that the camera is currently over when loading. When the camera moves far enough from that square for your comfort, you re-center and re-load all blocks. You may wish to do that in the background, and swap out all geometry at once once it’s all done, to avoid a large frame rate stutter.

Yes, this mechanism temporarily requires twice the amount of storage. That’s the price of perfection.

Actually, your ideas have given me a much better idea than either of ours. You’d probably have thought of it yourself if I’d told you one of the reasons for the translation bit.

I was already planning, to help save space, to separate the heightmap (x,y) coordinates from the z-height data and recombine them in the vertex shader.

However, I was planning on doing this per-sector. That is, I was planning on using the same (x, y) data for each sector, and translating with the matrix (so the translations were only intended to be just x,y, not z). Instead, I could do it over all of the loaded data. Granted, this takes up more memory than I planned, but it shouldn’t be too much of a problem.

To be a bit more lucid than my last paragraph (and, in case anyone out there has the same problem), I’ll explain more thoroughly.

I plan to have 3 distances of sectors in memory: the one the camera is in, the 8 sectors adjacent to that, and the 16 around them. I’ve already separated the (x,y) data from the (z) data; the (x, y) data spans the entire range of this 5x5 sector block.

When the camera goes into a new sector, the game simply adjusts which z-data goes with which (x,y) data.

Granted, it loses the memory I’d planned on saving by translating, but I can live with that. On the plus side, I can still keep streaming only the z-data, so harddrive access time doesn’t go up. Presumably, in any given sector, the adjacent sector data is either being loaded, or is already in memory, waiting for use.

[This message has been edited by Korval (edited 01-20-2003).]