Hi guys,

I want to sculpt a terrain in my program written in c++, DirectX 11.

currently I am having a copy of height map where I am setting vertices height based on sculpting brush I have, which is just a circle with a radius. I am editing height map and then again generating vertex geometry from it and the updating a DYNAMIC vertex buffer, which is eats lots of memory and absolutely not optimized.

I want to do this sculpting on GPU, where I can use alpha terrain map brushes as well as simple brushes with fall off. with a better memory footprint. My height map resolution may go up to 64k x 64k

what is the good approach for it.

I would probably need to read back from gpu to get a final sculpted terrain and do collision detection on it.

My picking algorithm is working correctly but I need to do sculpting on GPU.

please guide …

thanks…!

This web gl erosion demo has interactive editing the way you describe, so you could try that to see what it gives: https://github.com/LanLou123/Webgl-Erosion
It's not much ofc. Painting height maps from hand would require automated help, like erosion simulation as shown. With this, even bad input becomes something looking like terrain.
Professional terrain tools thus often start from some noise functions, and run simulation over that for nice results. Painting is mostly supported too, so such tools (World Machine, Gaea, etc.) might be worth a look as well.

Personally i try to overcome the 2D heightmap limitations and working with 3D particle simulation instead. Here an image showing a layer of sediment particles, meshed with blended SDF primitives.

This would allow sculpting by moving particles, but i have not worked on such tools yet.
Simulation in 3D is much harder (and slower) than in 2D. I still struggle to match 2D quality, and i don't wonder we don't have any 3D tools yet.
So i recommend to stick at heightmaps. ; )

What is your goal here? Some God game with interactive terrain, or offline content generation?

offline content generation

1. looking for optimized sculpting of terrain with in memory budget
2. Must be on GPU to support alpha textures directly added as a brush
3. dynamic vertex buffer(should I need it???????)

Enzio599 said:
dynamic vertex buffer(should I need it???????)

People say the fastest way to draw would be using a small patch of grid mesh (e.g. 8x8 quads), drawing instances of that, and calculating per instance vertex positions / normals on the fly from the height map texture. (Now mesh shaders would be a lot faster again i guess.)
So you don't need a huge vertex buffer for the whole terrain.

Enzio599 said:
looking for optimized sculpting of terrain with in memory budget

I would implement this somehow like this…

CPU:
User can select brushes, blending modes, and paint. Pretty sure you also need layers and paint-able masks. So a basic Photoshop.
The application could create an execution graph to represent blending operations in correct order, containing lists of brush strokes.
Then eventually compile this list to draw calls. Could draw a quad per brush stroke, with mask and blending mode, and in proper order.

GPU:
Draw the heightmap texture with traditional rendering. Use tiles to deal with large size.
Display mesh for preview.

So, with just drawing brush strokes, no big problem is expected. An option to collapse the execution graph would be needed, so further work starts with the resulting image, but we no longer need to generate it after each time from scratch.

If you want simulation too, tiling becomes a problem. You can simulate the tiles with some overlap area and blend them. Will work as long as simulation mainly generates local features (usually the case!), but would break on global things such as a river network.
Simulation will complicate all things in unexpected and hard to predict ways.
For example: You want to simulate at multiple frequencies. Meaning to do erosion first on a 64x64 terrain, then upscale to 128x128, add missing details from original image, erode again, and repeat until you have final resoltion. That's the key to achieve natural results from my experience. But it breaks the simplicity of above painting implementation proposal.

At this point i would develop the whole system on CPU first, and port to GPU later if successful / needed.
That's more practical to me. And performance is fine too. IIRC, this 1024^2 terrain takes maybe 10 seconds, and my 2D sim is single threaded and not optimized at all:

hey,

i have successfully done the sculpting implementation on CPU,

throw some guide on how to do this on GPU kindly …

i have moved the sculpting code to vertex shader but the sculpting is not accumulating in vertex shader and cant modify position in vertex shader… kindly tell me how …

see whats happening

if (SculptMode.x == 1)//Raise
   {
       float dist = length(uint2(PickedPoint.xz) - input.position.xz);
       if (dist <= BrushRadius.x)
       { 
           PositionOffset[int2(input.position.xz)] += BrushRadius.y * smoothstep(dist, BrushRadius.x, BrushRadius.x - dist) * DeltaTime.x * 10.0f;
       }
   }  

i am using a RWTexture2D for position offset by sculpting

storing offsets in that

not all vertices get the correct height offset, why the vertices are in spikes formation when i am just setting y values of vertices to calculated value

then

   input.position.y = PositionOffset[int2(input.position.xz)];

Enzio599 said:
smoothstep(dist, BrushRadius.x, BrushRadius.x - dist)

Looking up, i see is specified like this: smoothsetp (min, max, x)

So i guess you actually want: smoothstep(0, BrushRadius.x, BrushRadius.x - dist)

Yes bro I noticed that and I corrected that but even after correcting that my sculpting world is still in spike formation

Enzio599 said:
float dist = length(uint2(PickedPoint.xz) - input.position.xz);

I was wondering this works at all with integers. Maybe it causes some quantization causing artifacts?

I've recently done this for my terrain pretty successfully.

My terrain heightmap is 8192 x 8192 (max size). When sculpting, I simply use the terrain heightmap as a render target and render a full quad over it. In the pixel shader, I check that the texture coordinate is within range of the brush coordinates, if it's not I just use the existing data. If you flip-flop two copies of the heightmap texture, you can do some nice smoothing effects by using the last render as an input to the next. I also need to access the terrain, like max height per chunk for visibility and also for picking, so I copy resource from the GPU version to a CPU version. It all works really nicely and super quick.

Let me know if you want any more details.