Essentially I want to remove the need for generating coherent noise from the CPU to the GPU. From there, I also want to generate the terrain for a three dimensional world using this noise as densities in voxel points. After this, I want to take those densities and polygonize (generate vertices) them representing the world's terrain.

This is fine and all. But, I also want to dynamically deform the world in real-time. Once I get to this point, I have a problem trying to get the vertices back to the CPU to do things like collision detection and all of the game computations that I want to involve on the CPU and not the GPU.

So the question is: how can I get a subset of the vertices back to the CPU for dealing with collisions among other things?

And one more question: is there an easy way to take a set of vertices and generate indices from them on the GPU?

I'm confused as well as to what kinds of shaders I should be using for these different things. I hear of people using a pixel shader for gathering densities and then using a geometry shader for dealing with the terrain generation from the vertices and then somehow incorporating a vertex shader to do the dynamic deformations.

I'm using C# 4.0, .NET 4.0, and XNA Game Studio 4.0.

  • 1
    \$\begingroup\$ You say you're using a geometry shader in the title, but you also say that you're using XNA4.0, as far as I know XNA 4.0 requires DirectX 10 (to make it easier to develop for a more uniform platform) but only supports SM3.0 features, so no geometry shader. forums.create.msdn.com/forums/p/31369/178924.aspx \$\endgroup\$
    – Roy T.
    Commented Jul 17, 2011 at 7:47
  • \$\begingroup\$ And now I will no longer be using XNA or reworking my design. Thanks for pointing that out. I had been looking into it and didn't realize this limitation (no SM 4). I suppose the question still remains though, without the consideration of XNA.So, from a DirectX only perspective, is there a way to do what I want? Or perhaps with a vertex shader in XNA? \$\endgroup\$
    – JNZ
    Commented Jul 17, 2011 at 8:54
  • 1
    \$\begingroup\$ Well XNA is still valid to use, unless you've got a proven test-case where doing deformations and generation is too slow. And that you've proven in another test-case that GPU deform+generation and then getting data back to the CPU is faster :) \$\endgroup\$
    – Roy T.
    Commented Jul 17, 2011 at 9:26
  • \$\begingroup\$ Indeed. We found that using XNA and keeping everything on the CPU gave us about 1 million vertices in roughly three minutes on a Core i7 with 8 cores and 8 threads parallelizing multiple sections of terrain per thread. When trying to do that in real-time and hopefully rendering the terrain before the player could see it, we achieved about 20 frames per second. So, a test case is definitely in order with each of the methods. \$\endgroup\$ Commented Jul 17, 2011 at 22:40

1 Answer 1


Since XNA doesn't support geometry shaders, I'll answer it as if you were using DX 10. You essentially have three options.

Geometry shaders Geometry shaders can actually modify and add vertices to a vertex buffer. You could read this back into the CPU. I haven't looked into it, but it's definitely possible.

Just use the CPU Secondly, why don't you just calculate it on the CPU? The fact that it runs on the GPU in shaders suggests that your deformation algorithm is localizable, i.e. you can easily generate just the relavent parts for your collision checking.

For example, I made a sailing game a while ago. The ocean used the vertex and geometry shaders to deform the water with waves. I used the same algorithm calculated on the CPU on just a few points under the boat for the boat's movement in the waves. I'm sure you could do something similar for your voxel map.

Pixel shaders The last option, you mentioned this in your question too: generate the densities in the pixel shader and write it to a 3D texture. You can access this from the CPU and the shaders fairly harmlessly. The pixel shader is perfect for this task, but this method has a lot of overhead. Rendering the volume texture, as well as sampling from in in the vertex and geo. shaders, and having to read the texture onto the CPU.

I don't know the specifics of your project, but I would always use the CPU for this. By all means calculate the densities on the shaders as well, but stick to using the graphics card for rendering.

  • \$\begingroup\$ The main problem we had was the GPU-CPU barrier. In the sense of, once we generate and render the terrain on the GPU, how do we figure out what the terrain looks like on the CPU side of things in order to do collisions and other things. I suppose your thought about keeping it on the CPU is valid. I mean, we can probably optimize our algorithm quite a bit and generate less terrain. I'll mark your response as the solution in a day or two to see if anyone else has a response. Thanks for provoking some alternative thoughts. \$\endgroup\$ Commented Jul 17, 2011 at 22:37
  • \$\begingroup\$ With your sailing example, you wouldn't easily be able to connect the waveform result of a boat splashing through waves to the GPU right? \$\endgroup\$ Commented Jul 18, 2011 at 4:16
  • 1
    \$\begingroup\$ You can keep the same rendering system, i.e. generate and render the terrain on the GPU, but mirror the parts of the terrain you need on the CPU. Using the same algorithm and the same parameters, you would get the same terrain on the CPU as you see on the screen. \$\endgroup\$
    – Hannesh
    Commented Jul 18, 2011 at 20:24
  • \$\begingroup\$ @Daniel Not with the wave algorithm directly, but it's possible to deform the water mesh according to the boat's wake with a displacement texture that each boat "drags" behind it. \$\endgroup\$
    – Hannesh
    Commented Jul 18, 2011 at 20:31
  • \$\begingroup\$ Ah! That is a great idea :). But it probably doesn't support multiple watercraft very well. \$\endgroup\$ Commented Jul 19, 2011 at 10:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .