## Summary

This document describes the BackgroundSky plug-in and associated data-model. The BackgroundSky plug-in interface is meant to capture spectrally- and angularly-resolvable, potentially time-varying path radiances not accounted for by the atmosphere physics model. Example sources of such path radiances include light pollution, star light, and air-glow. Currently, the only implementation of the BackgroundSky interface is the PositionIndependentBackground plug-in, which in turn uses the BackgroundSkyData HDF data model.

## Data Model

This section focuses on the BackgroundSkyData data model, which is a data-driven representation and evaluation scheme for arbitrary background sky contributions, the interal structure of which is easily readable/writable as a binary HDF5 file. Then, the data model may be used as a source of background sky contributions in a DIRSIG scene by supplying the filename of such a binary HDF5 file to an instance of the PositionIndependentBackground plug-in.

If it makes sense to separate different contributions into different files (e.g., a file for light pollution from cities, another for star light, etc.), then multiple instances of the plug-in may be loaded in order to additively incorporate the contributions into the same scene. |

The data model is essentially a collection of *animated
lobes*. A *lobe* is meant to model the incident path radiance of a contribution
as a function of direction. So, at a high level, a lobe is function which maps
directions to spectra. This is not exactly tractable in general however,
so the data model implementation separates each lobe into a parametric scalar
function of direction and a spectral irradiance coefficient. This is covered
in more detail in the Lobes section below. For more specific
information on the HDF5 representation, refer to the
BackgroundSky HDF Interface Control Document.

### Usage

The usage of the data model is straightforward.
For example, consider the BackgroundSkyData database `MLS_Star_Light.h5`

,
which models the background sky contribution of ambient star light through
Mid-Latitude Summer (MLS) atmosphere. To add this to a DIRSIG scene,
instantiate the PositionIndependentBackground plug-in and pass the filename
`MLS_Star_Light.h5`

to `"database"`

in the plug-in inputs, as shown in the
example JSIM below.

[{ "scene_list": [ { "inputs": "./example.scene" } ], "plugin_list": [ { "name": "BasicPlatform", "inputs": { "platform_filename": "example.platform", "motion_filename": "example.ppd", "tasks_filename": "example.tasks" } }, { "name": "PositionIndependentBackground", "inputs": { "database": "MLS_Star_Light.h5" } } ] }]

Again, multiple instances of the plug-in may be loaded in order to
add background sky contributions from multiple databases. So if there
were another database `City_Light_Pollution.h5`

, to model light pollution
from a nearby city, then that could be loaded on top of `MLS_Star_Light.h5`

by modifying the example JSIM as follows.

[{ "scene_list": [ { "inputs": "./example.scene" } ], "plugin_list": [ { "name": "BasicPlatform", "inputs": { "platform_filename": "example.platform", "motion_filename": "example.ppd", "tasks_filename": "example.tasks" } }, { "name": "PositionIndependentBackground", "inputs": { "database": "MLS_Star_Light.h5" } }, { "name": "PositionIndependentBackground", "inputs": { "database": "City_Light_Pollution.h5" } } ] }]

### Lobes

A **lobe** is a closed-form parametric function
\(\ell(\omega):\mathcal{S}^2\to\mathbb{R}^+\) that returns a
non-negative scalar weighting for a spectrum \(E\), which contributes
to the path radiance arriving along a direction \(\omega\). As the
notation may suggest, a lobe \(\ell\) is meant to account for the
directional component of a background sky contribution, while the
associated spectrum \(E\) is meant to account for its
spherically-integrated spectral irradiance. It is therefore convenient
to assign units of inverse steradians to a lobe \(\ell\), and to
require that \(\ell\) be normalized over the sphere such that

Then, the total path radiance \(L\) arriving in the direction \(\omega\) may be computed as a linear combination of \(N\) lobe/spectrum pairs,

Importantly, the spherically-integrated spectral irradiance \(E\) associated with \(L\) is simply the sum of the input spectral irradiances \(E_k\).

There are three different "functional forms" of lobes in the
data model, being *Henyey-Greenstein*, *VNDF-GGX*, and
*VNDF-Beckmann* (more on these in a moment). In general, each form is
defined in a local coordinate space where the Z-axis is understood to be the
incident direction. Each form is then associated with a special orthogonal
linear transform \(\mathbf{Q}\) (also known as a rotation) in order
to arbitrarily re-orient the apparent incident direction of the lobe
contribution.

#### Henyey-Greenstein

The Henyey-Greenstein (HG) phase function offers a convenient and intuitive functional form to re-purpose as a lobe. The HG function is normalized over the sphere by construction and has a single shape parameter \(g\in(-1,1)\), which is identically the mean scattering cosine if interpreted as a phase function. So, \(g\to-1\) is back-scattering, \(g\to+1\) is forward-scattering, and \(g\to0\) is isotropic.

The direction \(\omega\) is understood to be a unit-length vector, such that \(\omega = (\omega_x, \omega_y, \omega_z)\) with \(\omega_x^2 + \omega_y^2 + \omega_z^2 = 1\). Such a vector is constructible from zenith-azimuth spherical coordinates \((\theta, \varphi)\) as \(\omega = (\sin{\theta}\cos{\varphi}, \sin{\theta}\sin{\varphi}, \cos{\theta})\). |

For the purpose of modeling background sky, the implementation restricts \(g\in[0,1)\), as to interpret \(g=0\) as being uniformly ambient and \(g\to1\) as more sharply concentrated around the Z-axis. Notice that this restriction only prohibits lobe configurations that would be redundant anyway, since negative values of \(g\) have an identical effect to rotating the lobe so that it faces the opposite direction.

The image shown above is a rendering of a sum of three HG lobes with
different shape parameters and orientations applied to a sphere. This sphere
can be considered as the *background sky surface at infinity*. Then, when a
ray escapes a DIRSIG scene, its origin is placed at the center of the sphere,
and where its direction intersects the sphere determines the incident path
radiance added to the sample path. The image is rendered with the Blender
default renderer by applying the lobe contributions as vertex colors.
It is important to note that there is no “lighting” in this
visualization, and that all intensity variation on the sphere is directly
proportional to the sum of lobe contributions.

#### VNDF-GGX and VNDF-Beckmann

The primary limitation of the HG lobe is that it is azimuthally isotropic about the incident direction. The Visible-Normal Distribution Function (VNDF) of a microsurface is a candidate lobe function without this limitation. The VNDF is typically denoted \(D_{\omega_o}(\omega_m)\) in microsurface theory, where \(\omega_o\) is the outgoing/viewing direction and \(\omega_m\) is a microsurface normal direction, such that \(D_{\omega_o}(\omega_m)\) is the probability density function associated with the proportion of normal directions \(\omega_m\) visible from \(\omega_o\). Being a probability density function, it is normalized by construction similar to the HG lobe. We fix \(\omega_o \gets \hat{\mathbf{z}}\) (viewing directly from above) to form an appropriate lobe function.

It may be important to note that the conditional expression on the right
indicates that this lobe is only ever non-zero for directions in the same
hemisphere as the incident direction (recall, +Z in local coordinates by
convention). The HG lobe, on the other hand, is non-zero everywhere.
Neither is strictly more advantageous than the other, which is why the
data model implements both.
The two parameters \(\alpha_x > 0, \alpha_y > 0\)
characterize surface roughness in microsurface theory by stretching
the function about the X- and Y- axes, respectively. That being the case,
the lobe is azimuthally isotropic if \(\alpha_x = \alpha_y\),
and azimuthally anisotropic if \(\alpha_x \neq \alpha_y\). The
function \(P(m_x, m_y)\) is a probability density function
over microsurface slopes. The data model implements the two most common
variations, corresponding to the *Trowbridge-Reitz/GGX* and *Beckmann*
microsurface slope distributions.

The GGX expression resembles a Cauchy density (longer tails); the Beckmann expression resembles a Gaussian density (shorter tails). So, GGX may better represent broader/softer sources, while Beckmann may better represent narrower/harsher sources. In either case, no configuration of \(\alpha_x, \alpha_y\) ever yields a uniformly ambient contribution. For this, it is necessary to use HG with \(g = 0\). |

### Lobe Animations

While the previous Lobes section introduces the available HG and
VNDF lobe functions in (hopefully) sufficient detail, it does not at all
discuss how lobes may vary with time. So, it is important to clarify that
the data model represents background sky contributions not as individual lobes
but instead as *lobe animations*. A **lobe animation** is a just a sequence of
lobes over time. An animation is associated with an absolute reference time,
and each lobe in an animation is associated with a relative time, given in
fractional days as an offset from the reference time. There are three types
of reference times, being *absolute*, *diurnal*, and *hebdomadal*.

An **absolute** reference time specifies an ordinary absolute time, given
as seconds since Epoch, and
indicates that a lobe animation does not repeat and is clamped to
the end points. A **diurnal** (or daily) reference time is used to indicate
that relative times should be interpreted as offsets, still in fractional
days, from the most recent midnight to the following midnight, such that the
animation repeats daily. That being the case, relative times should be
between 0.0 and 1.0 inclusive. A **hebdomadal** (or weekly) reference time is
used to indicate that relative times should be interpreted as offsets, still
in fractional days, from the most recent midnight on the most recent Sunday
to the following midnight on the following Sunday, such that the animation
repeats weekly. Analogously to the diurnal case, relative times should be
between 0.0 and 7.0 inclusive.

The implementation does not strictly require that a diurnal or hebdomadal animation be continuous at the cross-over point (“midnight from the left” versus “midnight from the right”), though this is often desirable. To ensure continuity, duplicate the lobe at time 0.0 to time 1.0 (if diurnal) or time 7.0 (if hedomadal). |

## Relevant Demos

The BackgroundSky1 demo contains a working example of this plugin.