4
\$\begingroup\$

I've been playing with implementing dynamic level of detail for rendering a very large mesh in XNA.

It occurred to me that (duh) the whole point of this is to generate small triangles close to the camera, and larger ones far away. Given that, rather than constantly modifying or swapping index buffers based on a feature's rendered size or distance from the camera, it would be a lot easier (and potentially quite a bit faster), to render a single "fan" or flat wedge/frustum-shaped planar mesh that is tessellated into small triangles close to the near or small end of the frustum and larger ones at the far end, sort of like this (overhead view)

enter image description here

(Pardon the gap in the middle - I drew one side and mirrored it) The triangle sizes are chosen so that all are approximately the same size when projected.

Then, that mesh would be transformed to track the camera so that the Z axis (center vertical in this image) is always aligned with the view direction projected into the XZ plane. The vertex shader would then read terrain heights from a height texture and adjust the Y coordinate of the mesh to match a height field that defines the terrain.

This eliminates the need for culling (since the mesh is generated to match the viewport dimensions) and the need to modify the index and/or vertex buffers when drawing the terrain.

Obviously this doesn't address terrain with overhangs, etc, but that could be handled to a certain extent by including a second mesh that defines a sort of "ceiling" via a different texture.

The other LoD schemes I've seen aren't particularly difficult to implement and, in some cases, are a lot more flexible, but this seemed like a decent quick-and-dirty way to handle height map-based terrain without getting into geometry manipulation.

Has anyone tried this? Opinions?

\$\endgroup\$

1 Answer 1

2
\$\begingroup\$

One issue you'll run into is that the mesh is camera-relative, so you'll get a "swimming" effect as you move and pan the camera around, as the topology of the mesh sweeps over the underlying heightfield data. This can be a distracting visual artifact. However if you can minimize that, it could be a good approach. It's reminiscent of what CryEngine 2 did for water, as described in this article.

\$\endgroup\$
7
  • \$\begingroup\$ Thanks for the link. I've managed to eliminate the "swimming effect" by tacking the mesh in place and resetting it relative to the POV whenever the camera moves one cell. The mesh lines up so there's no popping, it looks static so there's no swimming, and I still don't have to regenerate anything. Looks cool; kinda feels like cheating. \$\endgroup\$
    – 3Dave
    Commented Nov 27, 2011 at 7:24
  • \$\begingroup\$ @DavidLively You’re lucky to have a situation that you can do this — in particular, that your camera apparently doesn't rotate. \$\endgroup\$
    – Kevin Reid
    Commented Nov 27, 2011 at 20:06
  • \$\begingroup\$ @KevinReid it does; the mesh just follows it. \$\endgroup\$
    – 3Dave
    Commented Nov 27, 2011 at 22:21
  • \$\begingroup\$ @DavidLively I would think you would get swimming then, because there is nothing like a 1-cell shift which fits a rotation (until you get to 90°), so you would have to make a "circular" mesh rather than one that fits the view frustum. \$\endgroup\$
    – Kevin Reid
    Commented Nov 28, 2011 at 12:15
  • \$\begingroup\$ Link broken :c, do you by chance have a mirror? \$\endgroup\$
    – Cobertos
    Commented Oct 28, 2016 at 16:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .