I have a nice terrain engine based on the games programming gems 6 method of terrain blocks and a heightmap + normalMap for lighting.

Works great but now I need to sample heights off the terrain in parts of my game code.

The first thing I can do is copy the texture from the GPU and sample it. Doesn't seem very elegant, and its pretty hard to debug at the moment (My system does some things that don't seem to convert well between vertex shader and cpu). Plus I dislike having the texture replicated in system memory.

The other option I've come up with is using the texture in GPU memory and sending a texture of samples I want and computing it on the graphics card. This has its own problems too, since my engines not set up for a lot of GPGPU.

How does everyone else do it?

-Simon

I've never seen a terrain that was exclusively on the GPU. How would anything collide with it? Getting data back from the GPU could take a couple of frames.

Every implementation I've seen at least has the heightmap data (as verts or heights, etc...) or heightmap image from which to calculate the height on the CPU.

You might want to check this link:

www.cs.montana.edu/courses/525/presentations/Mike2.pdf

Note, the report about collision detection:

As the height map's data and the final outcome of its use are now being fully separated into different systems, some of the problems that need to have both available to it arise. The major problem that needs both the data behind the height and the final outcome is collision detection. Since the actual heights of the terrain are not being stored in any format directly accessible by the CPU, an alternative method of passing this information has to be developed. In this paper, the author has chosen to use a simplified version of collision processing at a specific single point. This point's coordinates are sent into the shader like every other parameter, and the height at that point is written out to a separate one dimensional texture that can be checked against by the CPU separate from the main rendering system. Other similar methods with larger point grids can be used as well, but only a single point was necessary to satisfy the needs of the author's collision problem.

Quote:
I've never seen a terrain that was exclusively on the GPU. How would anything collide with it? Getting data back from the GPU could take a couple of frames.

Every implementation I've seen at least has the heightmap data (as verts or heights, etc...) or heightmap image from which to calculate the height on the CPU.

Well, it seems(intersting to me too) this method does not store much in RAM, but in VRAM.

Thanks Deliverance, that's exactly what I was thinking. Seems like I answered my own questions then. :D

I will stay with my initial implementation for now and just take the memory hit, its only about 3 meg anyway. Now the bugs are ironed out I don't hate it too much.

I guess there's no point optimising it until the games done anyway as I wont know if I'm cpu, memory or GPU bound for a good while yet.