Graphics Reference
In-Depth Information
usually meant this wasn't a huge problem, but it definitely one that had to be handled.
Additionally, this handling stole CPU cycles that could have been used for better things and
further coupled the CPU and GPU.
One could also reduce draw calls by increasing the tile size—going from 9x9 to
17x17 or even 33x33 was perfectly legitimate. However, this made the algorithms other draw-
back, popping, even more noticeable. As discussed in Chapter 4 and earlier in this section,
popping can be a very unsightly and irritating artifact. And in the context of terrain rendering, it
can be even more irritating for the viewer, because of the viewing angles used. The primary axis
of change (vertical) when moving between levels of detail also tends to be the primary vertical
axis (7) on the final image; hence, problems are more noticeable than if the axis of change
were lined up with the view direction (such as into and out from the final image).
Typically, the biggest and most noticeable pops are transitions at the lower end of the
LOD scale, such as from 0 to 1, where the geometric difference between the two states is
highest. Transitioning at the top-end, such as from 4 to 5, won't be as noticeable, since the
mesh is already quite detailed, and the triangles are relatively small, making the geometric
difference small. Large changes to the silhouette of the terrain (such as mountains on the
horizon) tend to be particularly noticeable due to their prominence in the final image, and
should ideally be avoided. Unfortunately, the simplest metrics for deciding the level of
detail will typically set the geometry farthest from the camera to the lowest level of detail.
However, this can be mitigated with a more intelligent metric.
In such cases, working around this problem becomes non-trivial, because we do not
want to dynamically change the underlying buffers (as stated earlier, this is typically an
expensive operation, negating many benefits of using this algorithm). Also, in the days of
Direct3D 8 and Direct3D 9, vertex and geometry processing on the GPU was still rela-
tively simplistic. The first good solution to the problem was using more elaborate schemes
for LOD selection—weighting by screen contribution (projecting the bounding box to the
screen and using the 2D area as the LOD scalar) could handle the case where distant ob-
jects on the horizon popped unnecessarily. Vertex blending 3 was trickier to implement, but
was also an option that allowed for interpolation between detail levels.
Ultimately, the high number of draw calls and the popping artifacts were the major
problems in an otherwise GPU-friendly algorithm, and this approach was not used exten-
sively as it possibly merited. However, the Direct3D 11 implementation suffers from nei-
ther of these issues—a single draw call can render the entire landscape, and the tessellator
can handle smooth transitions between levels of detail.
The Implementation
As a high-level overview, this demonstration of Direct3D 11 tessellation focuses on the
input assembler, hull shader, and domain shader stages. The sample application will build
3 A method commonly used in animation to interpolate (blend) between two vertex positions based on weights
associated with dynamic transformation matrices.
Search WWH ::




Custom Search