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.

Note 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

\[\int_{\mathcal{S}^2} \ell(\omega)\,d\omega = 1.\]

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

\[L(\omega) = \sum_{k=1}^{N} \ell_k(\omega) E_k.\]

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.

\[\ell_{\text{HG}}(\omega) = \frac{1}{4\pi}\frac{1-g^2}{(1+g^2-2g\omega_z)^{3/2}}.\]
Note 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.

hg lobes

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.

\[\ell_{\text{VNDF}}(\omega) = \frac{1}{\alpha_x \alpha_y \omega_z^3} P\left(-\frac{1}{\alpha_x} \frac{\omega_x}{\omega_z}, -\frac{1}{\alpha_y} \frac{\omega_y}{\omega_z}\right) \times \begin{cases} 1 & \omega_z > 0, \\ 0 & \text{otherwise}. \end{cases}\]

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.

\[P(m_x, m_y) = \frac{1}{\pi} \begin{cases} (1 + m_x^2 + m_y^2)^{-2} & \text{if GGX},\\ \exp(-m_x^2 - m_y^2) & \text{if Beckmann}. \end{cases}\]
Note 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.

Note 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.