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.