Game Development Reference
In-Depth Information
66% of the time was spent within the GPU Texture Units. This highlights the
fact that our choice or implementation of the procedural height algorithm on a
per pixel basis, while visually effective, could be improved upon.
Figures 1.11(a) - 1.11(e) show some of the various steps taken to create the
final rendered scene. In Figure 1.11(e) , we added some diffuse lighting from a
single directional light source, and modified the color of the terrain based on
the calculated surface normal. Greater amounts of realism can be easily added
through any number of techniques, such as the use of textures, detail maps, etc.
An example application, as well as the complete source code implementing
this algorithm, has been included with this publication.
The results of our algorithm show promise, and we are continuing our research
in this area in an effort to make further gains.
A lot of the speed costs involved in our usage example come from the multi-
layered procedural calculation of the terrain height at the specified locations.
Swapping our procedural algorithm out and using a simpler method, such as a
single texture based height map, results in much faster rendering times. When we
swapped out our procedural height calculation for a simpler height map lookup,
we were able to achieve frame rendering times of 10 ms or even lower at the same
One problem with our approach is the visual phenomenon described as “vertex
swimming.” This can be noticed when moving towards large features that contain
a high frequency of detail. The problem can be greatly reduced by increasing the
amount of subdivisions created before rendering (i.e., by lowering the θ max value
used in the Subdivision Algorithm). When we swapped out our LOD Transition
Algorithm and instead added logic to correct the geometry (T-junctions) at the
LOD boundaries, we were able to eliminate the “vertex swimming” phenomenon.
Unfortunately, this also meant that the LOD boundaries became very noticeable,
and in our opinion, were more of a visual distraction than the “vertex swimming”
itself. There may be other ways to eliminate this visual distraction, and we are
hopeful that this issue will be improved with continued research.
Care must be taken to ensure high precision floating-point calculations are
used throughout this algorithm. Artifacts can sometimes appear if care is not
taken in this regards, and floating-point errors are inadvertently allowed to com-
pound, which can show up as sporadic pixel noise in the final rendered scene. We
solved this problem by using integer based values for our visible region's center
positions and applied offsets. Our initial applied offsets aresettolargefactors
of two, in order to accommodate the maximum number of iterative subdivisions.
By only applying a floating-point conversion factor when we required world space
coordinates, we were able to completely eliminate all floating-point difference er-
rors, while also scaling the data appropriately.
Search Nedrilad ::

Custom Search