Jump to content

  • Log In with Google      Sign In   
  • Create Account

TiagoCosta

Member Since 26 Nov 2008
Offline Last Active Yesterday, 04:39 PM

Posts I've Made

In Topic: Geometry Clipmaps - sample heightmap?

09 February 2016 - 06:38 PM

The main goal of Geometry Clipmaps is enabling you to draw terrains with higher resolution than you can fit in GPU memory (and still have space for the rest of the game assets).

Example: The Witcher 3 height map is 23552x23552 = ~1GB (0.37m resolution, I think there's a typo in the presentation). Clearly too much memory if you want other assets in your game.

 

You *probably* don't need full resolution height data to draw distant mountains, so you can use a clipmap.

 

dRiJCCN.png(source)

The top layer in blue is the full res height map. The blue layers below it are the mips (each half res of the previous one).

 

But you only load into GPU memory the green areas (centered around the camera).

 

Continuing using The Witcher 3 as example:

It uses 5 clip maps each with resolution 1024x1024 (eg: texture array).

1st layer - Full res - 1024 * 0.37m = 378m around the camera (in each direction)

2nd later - Half res - 1024 * 0.74m = 757m around the camera. (0.74m because it's half res so each pixel corresponds to double the distance)

...

5th layer - 1/16 res - 1024 * 5.92m ~ 6km around the camera

 

Full map is 23552 * 0.37 ~8.7km, so they're able to draw most of the map using only 1024*1024*5*2 bytes ~ 10 Mb height data.

 

Since you have all the data you need in the clip map, you don't need as many vertices as the size of the heightmap to render the terrain. Just create a 16x16 patch of vertices (15x15 rectangles), don't need any uvs, and reuse it to draw the terrain. In the vertex shader calculate the world position of the current vertex and use that to sample the clipmap in the correct position/layer.

Since you only have full res height data close to the camera, as soon as you start to use different layers of the clipmap render patches doubling the distance between vertices so each vertex matches one pixel of terrain data.

 

You'll run into problems in the borders when you start to render patches using a different layer because the height data won't match perfectly.

This GPU Gems article explains the types of patches to use and how to hide the seams between patches with different levels of detail.

 

When the camera moves (enough) you need to update some layers of the texture clipmap with data from the full map texture you have on disk. Doing toroidal access allows you to only update parts of the texture instead of having to move the parts that are still relevant over old parts and fill the "empty" space with new height data.

 

Some useful links:

http://www.gamedev.net/topic/652777-geometry-clipmaps-terrain-tutorial-with-source/

http://www.vertexasylum.com/downloads/cdlod/cdlod_latest.pdf (good solution for seams between layers, I use a modified version of this in my demos and it works very well) link to full source code in the end of paper)


In Topic: D3D12 Best Practices

02 October 2015 - 07:52 AM

Thought I shouldn't start a new topic as it is kind of generic DX12 question: if I put my CBV in the root signature, does the driver version the data automatically, i.e. I wouldn't need a per-frame constant buffer resource?

 

Thanks!

 

You will still need a per frame constant buffer resource. You just won't need a per frame entry in a descriptor table for that CBV.

 

The only way to not need a constant buffer resources is to store constants directly inside the root signature, but you have very limited root signature memory, so you won't be able to store everything in the root signature.


In Topic: DirectCompute - set numthreads from application code (or read from shader).

23 September 2015 - 02:46 AM

You can use ID3D11ShaderReflection::GetThreadGroupSize to get the thread group size of a compute shader in C++.

 

I do it in my engine right after creating the compute shader and store the thread group size together with the compute shader pointer in a struct, so I always have access to the info when I want the use the shader. 


In Topic: Cheap but realistic lighting engine: Is it a good idea?

18 July 2015 - 08:14 AM

You haven't described anything new wink.png but if you came up with that on your own, great!

 

Many engines and games use lightmaps, just google a bit.

 

You also, basically, described reflective shadow maps (also here).

 

So yes, it will work but you will have to deal with the limitations. Eg: How will you handle reflections?


In Topic: Uses for unordered access views?

05 July 2015 - 04:31 AM

There are many possible uses:

 

1 - Update particle systems on the GPU. Read from previous frame state (ConsumeBuffer), run simulation for the particle and append to the current frame (AppendBuffer). Draw using draw indirect. You can also do this in the geometry shaders (try both and see which is faster)

     This also works for other types of geometry like vegetation, water simulation, finding pixels that need bokeh, cloth simulations etc.

 

2 - Calculate per tile light lists (forward+ rendering) or tiled deferred lighting (tile culling and lighting runs on compute shaders). The results are stored in UAV that are then read as SRVs.

 

3 - Some full screen effects might benefit from compute shaders groupshared memory, so you'll use UAVs.

 

4 - and many more, just google a bit.

 

Check out this GDC presentation.


PARTNERS