Keywords: water, caustics, medium
Summary
This demo provides an example of using the water/medium plugins to model the effects of caustics (wave-focused light) on a scene. The air-water interface provided is static (a demo of dynamic interfaces will be provided in the future).
Details
Water, and non-atmospheric media in general, are not explicitly modeled within DIRSIG 5. Instead, the major components of the medium (the interface and the optical properties of the medium itself) are defined by implementing a plugin that satisfies a provided API (Application Programming Interface). With these definitions in place, DIRSIG handles the radiative transfer and the interaction of the medium with a larger scene.
A medium such as water is not defined as an enclosed volume. Instead an interface is provided that signifies a change in the current medium through which rays are traveling. By default the optical properties governing that transition are modeled as Fresnel (this can be overridden by using custom materials, though that is not done in this demo).
Important Files
This section highlights key files important to the simulation.
Scene Geometry
The scene itself is fairly simple. It consists of a series of steps "cut" out
of a solid grey background (modeled with rectangular slabs). The steps.glist file contains that steps while pool.glist incorporates the steps with the surrounding geometry. The distinction between the two geometry lists is arbitrary and they could have easily been combined into a single file. Both the steps and the surrounding area are defined with Lambertian reflectane properties and are spectrally flat (in pool.mat). Note that neither glist or the material database contain any information about the volume itself — that information is provided in
JSIM file: Plugins
There are two plugins that describe a water volume in DIRSIG. The first describes the optical properties of the medium (absorption, scattering, scattering phase function, and the real component of the refractive index). The second plugin describes the geometry of the medium interface (and any custom materials that should be applied to it).
Plugin: Medium Boundary
The boundary between the air (atmosphere) and the water is defined using a simple facetized surface. The plugin can have full control over intersections (and the materials being intersected), but in simple cases like this it can also pass the geometry definition into DIRSIG and let the standard ray tracing routines handle the surface interactions (that is the approach taken here). More details about this can be found in the boundary API.
The name of this static goemetry API is ObjInterface and it takes the name of an OBJ (Alias Wavefront goemetry format) as input. That file is read in during initialization and the resulting vertexes and facet definitions are passed to DIRSIG. The plugin itself is defined within the .jsim file as part of the medium definiton (each medium must include both an interface and a properties plugin implementation).
Since this particualar implementation of the boundary API passes most of its responsibilities back to DIRSIG, not much else is done beside opening and closing the input file (interface.obj). The facetized interface is shown below:
Plugin: Medium IOP
The medium IOP plugin is in charge of supplying inherent optical properties (spectral absorption coefficients, spectral scattering coefficients, spectral scattering phase functions and spectral refractive indexes) for any position and time within the medium. Like the boundary plugin, its definition (in the .jsim file) takes a single filename as input, from which the parametrized optical property model is read. For this particular implentation of the plugin, the format follows that of the IOP_MODEL enty in DIRSIG4. In fact the IOP_MODEL can be copied verbatim from a DIRSIG4 run and placed in the input file.
Documentation for the IOP_MODEL definition can be found elsewhere. For the purposes of this demo, a simple, pure water definition is being used, by itself and with additional Henyey-Greenstein scattering (in clear_water.iop and turbid_water.iop, respectfully).
Additional JSIM Inputs: Bounding box
The medium also takes a bounding box input that describes the portion of the scene that contains "active" water (i.e. areas in which scattering should be calculated). When using the internal geometry boundary as we are in this demo, the bounding box will automatically be sized to the horizontal extents of the boundary though the height of the box will still determine the maximum depth at which scattering will be computed. In other simulations where tiling can be used, the bounding box will drive the total horizontal area that is tiled.
Additional JSIM Inputs: Options
Because some calculations are much more time-intensive than others, options are used to tune the simulation. The most important of these is to turn off the expensive, spatially-varying volumetric scattering calculations. These can be very important for capturing variations in the water column across a body of water (e.g. due to focusing/defocusing of light by waves), but for this simple setup it’s a bit of overkill (especially with the clear water). Setting the force_average_volume to true indicates that the volumetric scattering should be calculated using the average surface. In contrast, since we expect caustics (focused light) on the surface of the steps, we want to make sure force_average_surface is set to false (note that forcing the average surface will also effectively trigger the average volume). In general, the (internal) surface interactions are much less computationally expensive than the volume ones.
Setup
As with all DIRSIG5 scenes, the program scene2hdf must be run first to convert the .scene file to a .scene.hdf (i.e. a "compiled" scene). Since the scene itself has no knowledge of the water body, the boundary interface as well as the internal optical properties can be modified through the plugins (even changing plugins entirely) without requiring a rebuilt scene hdf file.
The simulation can be run with either clear_water.jsim or turbid_water.jsim (which use the corresponding .iop files).
Results
The simulation results shown below were run with the default convergence parameters (minimum of 20 paths, maximum of 100). The default limit to the number of path nodes (i.e. 3 scattering events) is sufficient for the clear water case, but because the turbid scenario is highly scattering, this was increased to 10 (run with --max_nodes=10). The resulting images are shown below.
The caustics being highlighted in this demo are readily apparent in the clear water imagery where sunlight is being focused onto the steps below the surface according to the interaction of incident light with the wave surface. Volumetric caustics are not visible in this image (the clear water has very little scattering), but are present (if not readily visible) in the turbid case. Note however in the turbid case that the bottom steps disappear as we look deeper in the water and the return is dominated by scattered radiance.
The scene itself has no color (the sun, sky, and scene geometry are all spectrally flat) so the blue tinge to the water is due only to the preferential scattering and absorption of the pure water in the model (the add Henyey-Greenstien scatering constituent was modeled without spectral character).
Noise in the images can be moderated by increasing the number of paths being used through the convergence parameters. The default converegence was used to demonstrate the quality of images generated in around a minute (or less).
The user may notice faint artifacts in the surface reflectance both at the interface and on the bottom steps, in which the facetization seems to be apparent (slight triangular structuring). This is due to a somewhat inaccurate computation of the vertex normals that are being supplied with the geometry. The common method (used here) of averaging the normals of facets that share the vertex being computed is only appropriate when the facet slopes are changing slowly — which is not the case for this surface. Ideally, the vertex normals whould be based on known surface gradiants at those points along the surface (which will be seen in other demos).