Frustum culling

[Ralith]

We can massively reduce the amount of vertex processing done on the GPU with a relatively simple frustum culling check per terrain chunk.

[Ralith]

This could potentially be GPU-accelerated as well. For example, we could store a transform relative to the view node with every GPU-resident chunk, then use a compute shader to emit an indirect draw command for zero or one instances of each. It's unclear if this would be worth the additional complexity of maintaining that transform list, though.

[Ralith]

We can actually use this to accelerate the graph traversal to collect in-view nodes and therefore drastically reduce the number of chunks that need to be considered for culling. This is as simple as ignoring neighbor nodes which fail the frustum test. If the reference graph described in #55 is implemented, the geometric character of the graph could be further leveraged by ignoring neighbors with shorter distance to the view node outright. Furthermore, fine-grained per-chunk frustum tests only need to be performed within nodes that overlap the frustum boundary.

The frustum test itself can be implemented in terms of bounding spheres, using the same point vs. plane signed distance formula we use to judge distance from the reference plane in terrain generation.

[Ralith]

We probably shouldn't actually frustum-cull the graph traversal, since loading nearby chunks that aren't in view is desirable to limit pop-in when the view rotates quickly.