\section{Future Work}
For simplicity, not all optimizations were used when implementing this algorithm.
It would be possible, with some effort, to port the entire algorithm to the GPU.
Terrain data would reside completely in video memory in the form of a texture, and a
quadtree structure could be mimicked via indices to a memory location. Vertex lists
can easily be generated due to the regular grid layout, and indices could properly be
generated with triangles in a vertex shader.

Creating disk space for nodes of added detail disrupts data coherency when layed
out on disk. Though this isn't seen as a huge problem, it could be looked into further.

Currently the algorithm only allows for a single brush to be created at any given
time. Ideally, it should accept a myriad of brushes at various resolutions that can be
placed throughout the terrain and referenced by a specific identifier.

Often a terrain dataset is too large for deformations to be occurring
everywhere. Deformations are sometimes limited to a specific region of
interest even though terrain is present (the tank track deformation demo
for example). Since the current algorithm supports deformation anywhere
at any given time, the polygon throughput is not optimal. It would
be possible to detect if a region of the quadtree hasn't been touched
for a period of time, and if so, start to process the vertices into an
optimal triangulated irregular network. The mesh could toggle back to a
regular grid if deformation in that region was ever needed. This would
result in faster rendering and somewhat more distinct feature preserving
since nested error-bounds would be used within a triangulated irregular
network. Note that the memory usage would have to remain the same since a
toggle to a regular grid could happen at anytime, but the indices would
change to allow for faster rendering of a patch.

Finally, the algorithm could be modified for rendering terrain at a
planetary scale, which would require a specialized acceleration structure
for ellipsoidal geometry.


