Jump to content
  • Advertisement
Sign in to follow this  
KarimIO

Terrain by Heightmap: On CPU vs GPU

This topic is 541 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey guys. Are there any benefits to loading terrain by heightmap on the GPU rather than CPU? I've seen it done both ways. I figured loading on CPU might help with physics because the mesh needs to be passed but I think Bullet (and presumably other physics engines) use images directly. That said I imagine loading the heightmap to the vertex buffer once rather than as a sampler texture constantly is much better for the system. The only possible reason I can think of using heightmaps on the GPU directly is terrain tesselation. Any thoughts?

Share this post


Link to post
Share on other sites
Advertisement

Loading and rendering are 2 separate issues and there is some confusion on my behalf as to what you mean. All terrain are loaded by the CPU ( fundamentally, the terrain or terrain data if thats what you mean ) is loaded from a file into some memory ( whether this is CPU/GPU memory is another issue ). The reason I say this is that the file I/O is done under some CPU intervention. However, if by loading terrain, you mean, terrain mesh generation, its a matter of preference. Previously with the strict memory hierarchy between GPU and CPU, the location of terrain data for mesh generation could be partition based on usage like you already mention. In this case:
1. Terrain data in GPU memory would be optimized for rendering, but not so much for modification.
2. Terrain data in CPU memory would be optimized for modification, but not so much rendering.
The impact of memory access may be less with the newer graphic APIs, but I would still expect factors such as frequency of access etc to still factor into where the data is located.
Also there a other benefits of having the terrain data in GPU memory as rudimentary collision detection and modification can also be performed on the fly, not just rendering.


I was referring to, specifically, where the height map is applied. For one, my plan is to use bullet physics, but I've never quite done it yet - are you sure physics could be aided that way? Anyways another point, you said, is that it's better for rendering to do it on the GPU - but isn't having a slightly bigger vertex buffer better than constantly taking in a texture?

Thanks again!

Share this post


Link to post
Share on other sites

Physics and rendering are entirely different beasts.

 

Sometimes the physics meshes will also use rendering meshes, but quite frequently even those will be different; a physics object tends to have a simpler mesh or collision object.

Share this post


Link to post
Share on other sites

Physics and rendering are entirely different beasts.

Sometimes the physics meshes will also use rendering meshes, but quite frequently even those will be different; a physics object tends to have a simpler mesh or collision object.

Yes I'm well aware of that, but the in modern hardware, you can simply use the same LOD for both and tesselate the render. (Either way the issue is the thickness, I simply mean the number of vertices used)

Whatever the case, does anyone have more information about my core question, which is better, applying the height map in the CPU or GPU?

Share this post


Link to post
Share on other sites

For a given heightmap say 2048x2048, Bullet will want a copy of it, and the GPU will want a copy of it to render. Now if you want to just create a vertex buffer where every pixel is a vertex, that has many many problems:

 

1.) You can't dynamically LOD your terrain. Unless you are dynamically updating grid tiles of vertex buffers every so often.

2.) If you don't LOD your terrain at all, you end up with super tiny triangles (1 to a few pixels big after projection). This causes a huge decrease in shader performance.

 

Nowadays you have tesellation which is dynamically using a heightmap to generate a new mesh every single frame. Doesn't require a huge VBO or managing any rendering LOD's.


 

 

I figured loading on CPU might help with physics

Might help? It is a must, the CPU needs a heightmap or a mesh to perform collisions.

Share this post


Link to post
Share on other sites
Even without tessellation, there's many GPU-based LOD'ing schemes for heightmap terrains, which require the GPU to sample the heightmap.

If gameplay needs to query terrain hight at arbitrary points, then you'd keep a copy of the heightmap in system RAM too.

Note that different systems may want to represent the data differently. The GPU might use 16bit floats because they're natively supported, the gameplay code might use regular floats, or maybe bytes if precision isn't required, the Physics may break the image into chunks and organise them in a min/max quadtree for faster ray-tracing/collision queries.

Share this post


Link to post
Share on other sites
Thanks Adam and Hodgman for your feedback. I thought tesselation could be done just by smoothing but you're right about using the height map instead, as well as the other things. Also Adam, my finger slipped and I downvoted you instead of upvoting, so, sorry!

Share this post


Link to post
Share on other sites
I personally like terrain on the CPU, just sending vertex buffers to the GPU as needed. Mostly for backwards compatiblilty, old cards that can't do tessellation or even vertex fetch. And I don't like having multiple render paths.

Another issue is gigantic terrain. If the entire height map doesn't fit in a texture, you're loading chunks from disk or generating them procedurally usually at the LOD required, not high resolution. You can make this work for GPU tesselation or texture fetch, but it requires an additional index/offset/scale when fetching to get the right chunk at the right LOD.

In this case I think CPU is easier, and wouldn't Go the GPU route unless performance demanded it.

I'd hazard a guess that drawing buildings, trees, and grass is the slow thing and greatly outweighs the draw calls of CPU terrain and I'd optimize accordingly.

Another thing I like about CPU terrain is simple occlusion culling. By rendering front to back, I keep track of the 'horizon' and throw away chunks of terrain below it. This saves a lot if fill rate and vertex processing.

Share this post


Link to post
Share on other sites

"or even vertex fetch"

What gfx card are you supporting that doesnt have vertex texture sampling? I can't even remember what card didn't support that. Has to be many years ago.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!