Hey BenR, let's break down what's causing your terrain self-occlusion issues at larger sizes like 257×257 or 1000×1000. I spot a couple of critical issues in your code, plus some common pitfalls with large terrains that could be contributing:

1. 16-bit Index Overflow (Most Likely Culprit) #

Your index buffer is using WORD (16-bit unsigned integers), which can only hold values up to 65535. When your terrain dimensions hit 257×257, the total vertex count becomes 257 * 257 = 66049—this exceeds the 16-bit limit, so your indices will wrap around incorrectly (e.g., an index of 65536 becomes 0, 65537 becomes 1, etc.). This leads to completely wrong triangle connections, which manifests as overlapping geometry, self-occlusion, and visual glitches.

Fix:

• Change your index type from WORD to DWORD (32-bit unsigned integers) to support larger terrains.
• Update your CreateIndices code:

  // Change indices to use DWORD instead of WORD
  std::vector<DWORD> indices;
  
  // ... rest of your index generation logic stays the same ...
  
  // Update buffer description for 32-bit indices
  ibd.ByteWidth = sizeof(DWORD) * m_indexCount;
  

• When binding the index buffer in your draw setup, specify DXGI_FORMAT_R32_UINT instead of DXGI_FORMAT_R16_UINT.

2. Depth Buffer Precision Issues #

Large terrains with wide coordinate ranges (e.g., 1000 units across) can suffer from Z-fighting when the depth buffer doesn't have enough precision to distinguish between nearby surfaces. Even flat terrain can hit this limit because the sheer size of the geometry stretches the depth buffer's range too thin.

Mitigations:

• Optimize your projection matrix:
  • Use the smallest possible near-plane distance (avoid values close to 0 to prevent precision loss near the camera).
  • Narrow the far-plane distance to only what your scene requires.
  • Consider using a reverse-Z projection (a common modern technique) to improve precision for distant objects.
• Scale down your terrain coordinates: Instead of 1000 units, use 100 units and adjust your camera/lighting accordingly. Smaller coordinate ranges reduce depth buffer strain.

3. Triangle Winding Order & Culling #

While your index generation logic looks correct for quad-to-triangle conversion, it's worth verifying it matches your rasterizer state's culling settings. If backface culling is enabled and some triangles are wound in the wrong direction, you might get missing faces or unexpected overlaps.

Quick Check:

• Temporarily disable backface culling (set rasterizer state to D3D11_CULL_NONE). If the issue disappears, adjust your triangle winding order. For default counter-clockwise culling, you could swap the order of two indices in one of the triangles per quad.

4. Unnecessary World Position Offset #

In LoadFlatTerrain, you set m_position = verts2d[terrainDimentions - 1][terrainDimentions - 1].Position;—this shifts the terrain's world origin to its top-right corner. For large terrains, this moves the entire geometry into a very large coordinate space, worsening depth precision issues.

Fix:

• Keep the terrain centered at the world origin (your vertex generation already positions vertices around (0,0,0)). Remove the m_position assignment or set it to XMFLOAT3(0,0,0).

Start with fixing the index overflow issue first—this is almost certainly the main cause of your 257×257+ terrain glitches. Once that's resolved, tweak the depth precision settings if you still see minor Z-fighting.

内容的提问来源于stack exchange，提问作者BenR