Tiling a heightmap

Started by
18 comments, last by kauna 12 years, 3 months ago
Hi!
I am currently writing a heightfield class for my engine. I want to use tiles for different heights.
How can i do this? Should i sort the indexbuffer by height of the triangles and call render once for every tile?
Or is there a better way to handle this with a vertex shader?

Thank you in advance!
Advertisement
If you use a depth buffer and opaque rendering, there's generally no need to sort your primitives by height/depth/etc... , AFAIK it's better to limitate communications between CPU and GPU because of the limited bandwidth between them. The computational power of nowadays GPUs is awesome, it's better to have a more complex pipeline rather than to communicate too frequently between CPU and GPU. A draw call for each tile must be avoided . You can group your primitives according to their vertex layouts and techniques and draw each group in a single draw call (at least far fewer draw calls). Nowadays,the less you have draw calls and shader constant updating, the more you can access to high performances. For example, that's why there is instancing (you give geometry and information about each instance to the GPU so that it can draw all geometry instances at once, so : limiting draw calls) and constant buffers (a single update for a whole set of parameters, so : limiting constant updates).

I hope that can help you
Nico rolleyes.gif
Thank you. I really have to learn shader programming now
...
My idea was to sort the primitives at the start of the program and make a draw call for each texture. Would this be efficient, if i have about 4-5 textures?
Hello IceBreaker !


My idea was to sort the primitives at the start of the program and make a draw call for each texture. Would this be efficient, if i have about 4-5 textures?


My question is : Why do you need to sort your primitives ?
If your tiles are fully opaque (even alpha testing or alpha to coverage) , and you use a depth buffer, you will get perfect overlapping results even if the tiles are not sorted.
(Sorting them would partially avoid to invoke the pixel shader for pixels that would be covered later in the rendering phase, but it would need extra CPU work.) Generally it's better to let the GPU eliminate the covered pixels thanks to the depth buffer rather than to sort your primitives. What's more, the depth buffer permits to display perfectly primitive intersections and "A over B, B over C, C over A" case, because it works at the pixel level.

Getting informations on the depth buffer could help I suppose ? There must be an good explanation of this in the DX SDK documentation

Nico

EDIT : I honestly don't get why sorting them at the start of the program only is enought, unless your point of view is static ?
Thank you, I´ll try it that way
You may also use texture arrays to store your landscape textures (up to 512 per texture array) or a 3d texture could work too.

These texture storage methods allow you to draw your landscape tiles in what ever order you want regardless of the number of materials. Of course, every tile needs an index to the desired texture in texture array or a coordinate to the 3d texture.

Otherwise, it is a good practice to arrange your objects by the resources they use such as material.

Cheers!
If in the 3d texture there is one 2d texture for y=0 and 1 for y=1 will directx interpolate between them?

If in the 3d texture there is one 2d texture for y=0 and 1 for y=1 will directx interpolate between them?


Direct3D will interpolate a 3d-texture according to the filtering mode. if you wish to interpolate between textures, the 3d texture has a limitation that the textures can only be blend with the slice above or below, which may turn out to be a huge limitation.
Otherwise you may use alpha maps (texture splatting) to blend between materials.

Cheers!
Thank you very much, I´ll definitly give it a try ;)

This topic is closed to new replies.

Advertisement