I thought manipulating vertices via CPU is very slow?

No why would it? Only if you manipulate all terrain vertices at once (like scale it in z-direction). You can easily determine close terrain vertices and thus you even don't have to loop through all of them for every manipulation.

Of course it does.
On like every hardware newer than five years or so.
But as HeelX mentioned, you´ve got to use the tex2Dlod function.

Nah, just manipulate the vertices you are actually modififying. Even if you have a huuuge terrain your brush will mostly cover only a small fraction of it. So it makes sense to update only those. I have written a terrain editor a while ago for a client and in the following screenshot, you see that the brush covers only about 30-40 vertices. So.. well.. this is fast, even on the CPU



Besides, it is only fast, if you don't update the collision hull per frame with c_updatehull. For that I implemented an own tracing function that raymarches the matrix from the viewpoint. I use that to adapt a circle-mesh on the ground.

If so, could you please tell me roughly how to do this? - if it's not too much to explain, of course.



Well thats okay. The main feature I want to have is just being able to "paint" the terrain and to see how the terrain will look like.
Using MED's terrain-from-image-function all the time is senseless for just testing how the terrain will look like.

@Slin Just got it, thank you very much for the advise!!

I just have to fix the culling for terrains: