Hi!

I've been trying to implement simple virtual globe rendering system using "3D Engine Design for Virtual Globes" book as a reference.  What I do is I use 6 planes to form a cube, send it to GPU and use vertex shader to form a sphere and add random noise to simulate surface of the planet. The problem is how do I do CPU work on the vertex data from now on - how do I get world space coordinates of a terrain patch to perform LOD techniques, how do I do camera-terrain collision detection etc. ?

47 minutes ago, regnar said:

What I do is I use 6 planes to form a cube, send it to GPU and use vertex shader to form a sphere and add random noise to simulate surface of the planet.

You should just generate the terrain on CPU before you send to GPU: You have all data you want, you don't need to repeat the exact same calculations on GPU each frame

Otherwise APIs allow to transfer vertex shader results to CPU, either by using stream out or writing vertex results to a GPU buffer that you download after vertex shader is done.

It's also possible to do all work on GPU by using compute shaders (nice for LOD, but a bit of a waste to perform just one single collision check). This would allow to generate procedural data just once and update / refine on demand. To do collision or other CPU work you could download only a small region of that data. (It is possible to treat vertex data as regular memory so compute shader can modify and CPU can download. But you may want to subdivide each of your 6 quads to even smaller quads to avoid downloading memory from a neighbouring quad you're not interested in.)

3 hours ago, JoeJ said:

You should just generate the terrain on CPU before you send to GPU: You have all data you want, you don't need to repeat the exact same calculations on GPU each frame

 

 

I wanted to use technique where you have one small vertex buffer to render all your terrain patches by modifying the vertices in vertex shader depending on world location and LOD of the patch. It seemed very efficient thing to do at first but now it makes me wonder if the hustle with sending data back to CPU is worth it.

Watch out with things written before compute shaders have been introduced, a lot effort has been spent to overcome GPU limitations that nowadays don't exist anymore.

However, in your case all you need to do for collision detection would be to replicate your random noise shader on CPU, which is surely better than downloading even a tiny amount of data. The lod problem could be solved by subdividing the patches and setting their resolution from CPU drawcalls.

17 hours ago, regnar said:

The problem is how do I do CPU work on the vertex data from now on - how do I get world space coordinates of a terrain patch to perform LOD techniques, how do I do camera-terrain collision detection etc. ?

You might be interested in this.