	A SHORT EXPLANATION OF BSDF MATRIX DIRECTIONS

Radiance uses whichever transmission matrix is appropriate and
available for the direction of ray travel.  If you are rendering
from the eye to the interior surface of a window, this typically
corresponds to the "backwards" light direction, which uses the
"Transmission Back" matrix from the XML file if present.  This
naming is due to the unfortunate precedent WINDOW 6 uses of considering
the exterior of the window the "front" even though in Radiance
models, it corresponds to the opposite side from the window surface
normal.

If there is no "Transmission Back" matrix but there is a "Transmission
Front" (as might be generated by WINDOW or 'genBSDF +forward
-backward'), Radiance will interrogate the "Front" matrix in the
reverse direction, relying on reciprocity working properly.  The
reverse logic applies if the eye starts from outside (looking at
the back side of the window surface), in which case the preference
is for the "Transmission Front", using reciprocity on the "Back"
matrix if it's not available.

Something similar happens using dctimestep or rmtxop, except that
in this case, the "Transmission Front" is *always* favored, and
reciprocity is used on "Transmission Back" if it isn't available.
The reason for this is two-fold.  First, the "Transmission Front"
matrix is the right way around for the 3-phase method already.
Second, WINDOW 6 generally produces correct data for "Transmission
Front," but in some cases just has dummy values as a placeholder
for the "Transmission Back" matrix.

For the tensor tree representation, reciprocity can be used to
derive all needed information for 4-D distributions, so only one
tree is stored to save file space and memory.  However, isotropic
(3-D) data does not use reciprocity for sampling, even though it
can use it to answer BTDF queries, because it would require too
much work to build up a 4-D structure then derive the 3-D information
from it.  So, this is a caveat, and genBSDF will create reverse-flow
isotropic BTDF data if run with +forward and +backward in this case.

The situation is a bit simpler in the case of reflection, since one
cannot construct the front reflection data from the rear or vice
versa.  If one of the reflectance matrices is missing during
rendering, then the surface gets no reflected contributions from
that side.  The 3-phase method does not make use of reflectance,
so it has no bearing on dctimestep or rmtxop.
