Updated FAQ.

documentation/faq.txt

@@ -4,10 +4,16 @@ Frequently Asked Questions
 
 Should I store my environment in a single big volume or break it down into several smaller ones?
 ------------------------------------------------------------------------------------------------
-You should usually store your environment in a single big volume, and if you are going to deviate from this then you should be aware of the implications.
+In most cases you should store you data in a single big volume, unless you are sure you understand the implications of doing otherwise.
 
-All PolyVox algorithms operate on a single volume, and there are a number of algorithms which require fast access the the neighbours of a given voxel. PolyVox volumes make it easy to access these neighbours, but if you split your environment across several volumes then PolyVox no longer knows how to access them for voxels on the edge of the volume. This will cause visible artifacts between extracted meshes, meshes will contain unessesary triangles on the faces of volumes, and normal calculation from volume data will not work correctly.
+Most algorithms in PolyVox operate on only a single volume (the exception to this are some of the image processing algorithms which use source and destination volumes, but even they use a *single* source and a *single* destination). The reason for this is that many algorithms require fast access to the neighbours of any given voxel. As an example, the surface extractors need to look at the neighbours of a voxel in order to determine whether triangles should be generated.
 
-The most common reason for people *thinking* they should break their environment into seperate volumes is in order to allow for paging of big terrains. The idea would be that volumes which are distant from the camera can be removed from memory, and that the set of active volumes can be updated as the camera moves. However, the LargeVolume already implements this behaviour internally, in that it breaks the data down into a set of non-overlapping blocks. The difference between the LargeVolume implementation vs a home-grown approach of paging smaller volumes is that PolyVox understands how to access neighbouring blocks in a LargeVolume.
+PolyVox volumes make it easy to access these neighbours, but the situation gets complex on the edge of a volume because the neighbouring voxels may not exist. It is possible to define a border value (which will be returned whenever you try to read a voxel outside the volume) but this doesn't handle all scenarios in the desired way. Often the most practical solution is to make the volume slightly larger than the data it needs to contain, and then avoid having your algorithms go right to the edge.
 
-That said, there are times when you might want to use seperate volumes provided you understand the above. An example might be if you had a number of planets in space, in which case each planet could safely be a seperate volume. These planets never touch, and so the artifacts which would occur on volume boundaries are never seen.
+Having established that edge cases can be problematic, we can now see that storing your data as a set of adjacent volumes is undesirable because these edge cases then exist throughout the data set. This causes a lot of problems such as gaps between pieces of extracted terrain or discontinuities in the computed normals.
+
+The usual reason why people attempt to break their terrain into separate volumes is so that they can perform some more advanced memory management for very big terrain, for example by only loading particular volumes into memory when they are within a certain distance from the camera. However, this kind of paging behaviour is already implemented by the LargeVolume class. The LargeVolume internally stores its data as a set of blocks, and does it in such a way that it is able to perform neighbourhood access across block boundaries. Whenever you find yourself trying to break terrain data into separate volumes you should probably use the LargeVolume instead.
+
+Note that although you should only use a single volume for your data, it is still recommended that you split the mesh data into multiple pieces so that they can be culled against the view frustum, and so that you can update the smaller pieces more quickly when you need to. You can extract meshes from different parts of the volume by passing a Region to the surface extractor.
+
+Lastly, note that there are exceptions to the 'one volume' rule. An example might be if you had a number of planets in space, in which case each planet could safely be a separate volume. These planets never touch, and so the artifacts which would occur on volume boundaries do not cause a problem.