Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I can't really find anything at all on this topic. There's a bunch of YouTube videos that show people doing it, but there aren't any articles that I can find explaining the mechanics of it. In my game, terrain is loaded from a .RAW heightmap, and saved to a .RAW heightmap. But the player will be able to modify the terrain. I don't really understand his this terrain deformation works, but so far, I've only created things using vertex buffers which as far as I know can't be changed efficiently. Here and there I've read a few things about GPU tessellation and compute shaders. I understand tessellation and I can do that, but there's also very little I can find about compute shaders.

Are there any good books or websites that explain these things in detail? I'm not really looking for tutorials, because they tend to be pretty specific. But I really just want anything to bring me out of the dark on this subject.

share|improve this question
    
Well, you likely won't be modifying the terrain once it's at the GPU. You're just going to add or subtract the height of certain points in your height map (in memory), where ever you happen to be deforming. Then these values will be used to re-buffer the data in the graphics card, and eventually saved back into your .RAW height map. –  Byte56 Jan 1 '12 at 21:43
    
@Byte56 Well, I'm confused by this. Is it possible to create a mesh with no y values, then in the vertex buffer translate the values accordingly? –  smoth190 Jan 2 '12 at 3:16
    
How are you currently creating the mesh? You want to edit the y values, then re-create the mesh. –  Byte56 Jan 2 '12 at 4:29

1 Answer 1

up vote 2 down vote accepted

Forget about tessellation and compute shaders. You simply want to maintain a system copy of the terrain and send it (or parts of it) to the GPU every frame. Yes it's slow, but it ain't that slow :)

The trick is to make the section your updating small enough to not bog down the computer. So you don't want to be updating a terrain 1000x1000 tiles. Use chunks of terrain, I use 16x16 tile chunks with 4 tri's per tile, indexed. I can update a terrain chunk in real time no problems.

I was going to suggest a dynamic vertex buffer, but you don't even need that.. here's the code i use to update geometry, just use the default resource usage :

    public void SendToBuffer()
    {
        DataStream data = new DataStream(vertices, true, true);
        DataBox dataBox = new DataBox(0, 0, data);
        device11.ImmediateContext.UpdateSubresource(dataBox, VertexBuffer, 0);
    }

you just have to provide the vertex data, which you've edited during the frame. Maybe even read about dynamic buffers, they might give you even better performance, but I don't know about that yet.

edit : Just to clarify, this is SlimDX (DX11) code, so it should translate easily to straight DX11 code.

edit2 : And just to answer one of your questions above, you can also have flat geometry and use the vertex shader to shape your terrain, but you still need to get the height data in to your shader. So you can avoid sending new geometry in, but then you have to send a height map in. So you are still updating gfx resources. Which is faster depends upon your vertex and height map formats.. importantly, their data sizes. In my case, the terrain only has Position & Normal, so it's not too large. My UV's are derived from position. And I think by updating the vertex buffer itself, then it's done, and you've got your vertex heights precalculated, rather than having to sample from a heightmap, which does have a cost.

share|improve this answer
    
This looks good, I'll have to try it out after I solve some shader issues I have. My current terrain is 1024x1024, split into 128x128 sections, which are themselves split into 16x16 sections. So it should be easy for me to implement this. –  smoth190 Jan 2 '12 at 21:56
    
@smoth190 just to expand on this answer slightly - you can get really far by just culling non-visible areas. I implemented a geo-mip-mapped terrain in XNA and the first step was exactly that - culling. I reached very acceptable framerates without the whole mip-mapping, stitching, etc. Also, geo-mip-mapping handle deformation quite well - if you share your vertices correctly. –  Jonathan Dickinson Jan 4 '12 at 9:08

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.