Hi.

Ive gone through a similiar process with my editor (see video here http://www.gamedev.net/blog/807/entry-2259360-strife-world-editor/). It used to be CPU based but the framerate became so low it was pretty unusable to do continues drawing. I use a grayscale image next to the terrain display to draw on because it seemed better at the time. However for painting textures or placing models onto the terrain i use picking to get the coordinates under the cursor. I use two 24 bit textures. one for x and one for y. i treat the 24bit's (RGB8) as one number so i can go from 0 to 16777216. wich is overkil but only going from 0.0 to 1.0 (wich is 0-255 when using 8 bit textures is way to little if you have a big heightmap).

triggers the GPU to update the heightmap on 'mouse down' events at fixed time intervals - maybe 20 times per second.

Why would you update the heightmap if it hasn’t changed?

Are you talking about dragging vertices up and down manually?

It’s really trivial to make a translucent patch for that area and only update that as the user drags the mouse. Only update the terrain when the user lets go.

For vertex picking, I intend to write to two colour buffers - a normal colour buffer, and a 32-bit RG floating point buffer using colours interpolated from 0.0f, 0.0f to heighmap width and height (e.g. 8192.0f). On mouse move, I can then use the mouse XY coordinates to copy the pixel value under the mouse into a 1x1 texture, which can then be read back by a shader (rounding the RG colour to the nearest integers will give me a precise XY vertex), which in turn can modify heighmap values based around these coordinates using a another texture 'brush'.

That sounds like an extremely convoluted way to do picking when it is trivial to take advantage of heightmap terrain’s grid-based layout for real-time picking on the CPU (which will be faster and much less complicated than what you have just proposed).

It sounds as though your tool is slow because you have poor high-level strategies, and the GPU strategies don’t seem any better.
I would suggest looking at what is actually a bottleneck and fix that first. In my first fixed-function engine I made real-time sunlight by ray-casting every vertex on the terrain against the sun to check whether they were in shadows or not (real-time vertex light-baking) and it ran on low-end machines in real-time.

And whatever bottleneck you think you have regarding updating the terrain is a product of a poor updating strategy. You don’t need more brute power, you need more efficient approaches.

L. Spiro