| 1 |
greg |
1.1 |
A SHORT EXPLANATION OF BSDF MATRIX DIRECTIONS
|
| 2 |
|
|
|
| 3 |
|
|
Radiance uses whichever transmission matrix is appropriate and
|
| 4 |
|
|
available for the direction of ray travel. If you are rendering
|
| 5 |
|
|
from the eye to the interior surface of a window, this typically
|
| 6 |
|
|
corresponds to the "backwards" light direction, which uses the
|
| 7 |
|
|
"Transmission Back" matrix from the XML file if present. This
|
| 8 |
|
|
naming is due to the unfortunate precedent WINDOW 6 uses of considering
|
| 9 |
|
|
the exterior of the window the "front" even though in Radiance
|
| 10 |
|
|
models, it corresponds to the opposite side from the window surface
|
| 11 |
|
|
normal.
|
| 12 |
|
|
|
| 13 |
|
|
If there is no "Transmission Back" matrix but there is a "Transmission
|
| 14 |
|
|
Front" (as might be generated by WINDOW or 'genBSDF +forward
|
| 15 |
|
|
-backward'), Radiance will interrogate the "Front" matrix in the
|
| 16 |
|
|
reverse direction, relying on reciprocity working properly. The
|
| 17 |
|
|
reverse logic applies if the eye starts from outside (looking at
|
| 18 |
|
|
the back side of the window surface), in which case the preference
|
| 19 |
|
|
is for the "Transmission Front", using reciprocity on the "Back"
|
| 20 |
|
|
matrix if it's not available.
|
| 21 |
|
|
|
| 22 |
|
|
Something similar happens using dctimestep or rmtxop, except that
|
| 23 |
|
|
in this case, the "Transmission Front" is *always* favored, and
|
| 24 |
|
|
reciprocity is used on "Transmission Back" if it isn't available.
|
| 25 |
|
|
The reason for this is two-fold. First, the "Transmission Front"
|
| 26 |
|
|
matrix is the right way around for the 3-phase method already.
|
| 27 |
|
|
Second, WINDOW 6 generally produces correct data for "Transmission
|
| 28 |
|
|
Front," but in some cases just has dummy values as a placeholder
|
| 29 |
greg |
1.2 |
for the "Transmission Back" matrix.
|
| 30 |
|
|
|
| 31 |
|
|
For the tensor tree representation, reciprocity can be used to
|
| 32 |
|
|
derive all needed information for 4-D distributions, so only one
|
| 33 |
|
|
tree is stored to save file space and memory. However, isotropic
|
| 34 |
|
|
(3-D) data does not use reciprocity for sampling, even though it
|
| 35 |
|
|
can use it to answer BTDF queries, because it would require too
|
| 36 |
|
|
much work to build up a 4-D structure then derive the 3-D information
|
| 37 |
|
|
from it. So, this is a caveat, and genBSDF will create reverse-flow
|
| 38 |
|
|
isotropic BTDF data if run with +forward and +backward in this case.
|
| 39 |
greg |
1.1 |
|
| 40 |
|
|
The situation is a bit simpler in the case of reflection, since one
|
| 41 |
greg |
1.2 |
cannot construct the front reflection data from the rear or vice
|
| 42 |
greg |
1.1 |
versa. If one of the reflectance matrices is missing during
|
| 43 |
|
|
rendering, then the surface gets no reflected contributions from
|
| 44 |
|
|
that side. The 3-phase method does not make use of reflectance,
|
| 45 |
|
|
so it has no bearing on dctimestep or rmtxop.
|
