# Whitecaps

Whitecaps are generated dynamically by RenderWorld. This means that the user does not determine when and where a whitecap appears, only the ocean surface does. The user is given controls in the whitecap input file to adjust the frequency of their occurrence, their growth and decay life cycle, the internal structure of a simple foam process, and their intrinsic optical properties. The whitecaps currently are limited to only a two dimension manifestation that conforms to the water surface. Spray and bubbling off of the surface are the subject of additional development.

Whitecaps pose new challenges to rendering efficiency. In the earth's oceans, whitecaps exist for 4 to 8 seconds after their initial onset. If you want an ocean surface that has a steady whitecap activity, the ocean surface simulation must begin 4 to 8 seconds earlier in simulated world time than the frames you want to render. Thus there can be a significant amount of computational time taken up evolving the ocean surface and associated whitecaps to a steady state. In addition, creating and tracking whitecaps over the entire ocean would be unnecessarily burdensome, since most of the ocean is not seen by the camera. To reduce the load, the user specifies the area of the ocean surface on which whitecaps are to be simulated. If the camera is moving substantially over the surface, you must be careful to chose enough area for the entire range of camera motion.

At present, the RenderWorld Engine generates 2D whitecap layer which rides on the ocean surface. Bubbling foam and splash are not yet implemented. The present implementation works well for conditions in which the viewer is not concerned with the detailed internal structure of the whitecaps.

To put whitecaps into the ocean surface, replace the line in the ocean file

  `whitecaps` `no`

with the two lines

  `whitecaps` `yes`
  `whitecap_file` `whitecaps.dat`

The file `whitecaps.dat` contains the information about the whitecap life cycle, frequency, foam and optical properties. An example of the file is

  `RenderWorld_data_file whitecaps 2 2`
  `sampling_region`
  `center` `25 0`
  `length` `80 80`
  `interval` `0.075 0.075`
  `max_distance` `4000`
  `reference_time` `0.0`
  `evolution_time` `0.041666667`
  `ramp_up_interval` `4.0`
  `ramp_up_increment` `0.1`
  `formation_time` `0.2`
  `decay_time` `3.0`
  `threshold` `0.4 0.5`
  `reflectivity` `0.15 0.55`
  `smearing_scales` `1.0 1.0 0.20`
  `acceleration_offset` `0.2`
  `whitecap_file` `input`
  `file_name` `whitecap_data.dat`
  `add_small_scale no`
  `diffusion no`
  `end`

In this list, the `sampling_region` is the patch of the ocean surface on which whitecaps are generated at finest resolution. The center of the patch is given in the `center` line, and the size of the patch in the `length` line. Within this patch, whitecaps are dynamically generated on a grid with resolution given in the `interval` line, in the example it is 7.5 cm by 7.5 cm. Outside of this patch, whitecaps are generated on a grid which is dynamically resampled in the same method as the ocean surface doubling technique. The parameters in the `length` line act as twice the double_distance. The line `max_distance` dictates the maximum distance from the patch center that whitecaps are simulated. Keep in mind however, that whitecap bookkeeping is not as time consuming as ocean surface bookkeeping, because typically even in strong winds whitecaps occupy less than 1 percent of the ocean surface.

When a rendering job begins, the whitecap field on the ocean surface must be created dynamically. Whitecaps have a typical lifetime of about 4-8 seconds (although this is user adjustable), and so the ocean and whitecaps fields must be simulated for approximately that length of physical time in order to build of the whitecaps from nothing to a steady state. The time at which the user wants this steady state to exist is given by the `reference_time` parameter. In this case, the `reference_time` is 0, so the RenderWorld Engine begins the ocean/whitecap simulation at a time with a negative value. The amount of time before `reference_time` at which the simulation begins is given by `ramp_up_interval`, in this case 4 seconds. Note that during this initial ramp up to steady state, the ocean surface and whitecaps evolve, but no image rendering is done. During the ramp up period, the fundamental time step of the whitecap evolution process is given by `ramp_up_increment`. After the ramp up has been completed, the time interval used for whitecap evolution is on the line labeled`evolution_time`. The reason for allowing two different time steps is for efficiency: Over time intervals of image rendering, the whitecaps should evolve smoothly from frame to frame, and so `evolution_time` should be equal to or smaller than the time between frames. During the ramp up however, longer time steps should be taken because the ramp up could take substantial amounts of pre-rendering overhead time if the ramp up evolved at the frame rate, and because whitecaps typically do not have any fast temporal behavior and longer time steps do not sacrifice quality.

In order to understand the next six parameters, the model of whitecap dynamics must be discussed. Whitecaps have a lifecycle which begins when the ocean surface reaches a dynamically favorable condition, at which point a whitecap grows in intensity and size for a short period of time, then decays over a much longer period. The RenderWorld Engine gives the user the ability to control the dynamical condition for onset, the growth rate and intensity, and the decay profile. In addition, there is an option for adding simple texturing to the internal structure of the whitecap.

Once a whitecap begins to grow, it continues growth for a period of time labeled as `formation_time`. At the end of this time, the whitecap has grown to its maximum size and brightness, and decays over `decay_time` seconds. A whitecap begins growth when the ocean surface acceleration at any given spot on the surface exists a threshold given by the first value in the `threshold` line. During growth, a whitecap grows in diffuse (spectrally white) reflectivity, and reaches its maximum reflectivity when the local acceleration reaches the second value in the `threshold` line. The values of the minimum and maximum reflectivity are given in the `reflectivity` line.

The two lines, `smearing_scales` and `acceleration_offset`, allow you to alter the definition of acceleration used to control whitecap growth. The first and second values in `smearing_scales` define the size of the area around a point to average the acceleration, and the third number is the interval of time over which to average. This averaging over space and time controls the effective size of a patch of whitecaps on the ocean surface, and how sensitive it is to rapid and small-scale ocean structure. The value of `acceleration_offset` moves the physical time of the acceleration calculation back. With an `acceleration_offset` of 0, whitecaps typically begin formation on the tops of the waves. By increasing the value of `acceleration_offset`, the onset criteria are satisfied earlier in time, so that the whitecap begins forming on the front size of a wave. A negative value for `acceleration_offset` would cause the whitecaps to typically begin forming on the backsides of the waves.

Because of the overhead time spent ramping up the whitecap field before rendering begins, the whitecap field at the `reference_time` can be written to a file and read back again in a later rendering job. Thus `whitecap_file` has three options. The option `whitecap_file` `input` reads the whitecap field from the file given on the line `file_name` `whitecap_data.dat`. This field is used at the `reference_time`. The option `whitecap_file` `output` creates a new whitecap field at the `reference_time` and writes it to the file specified. The third option, `whitecap_file` `ignore` does not do any file I/O. In this third option, the `file_name` line must be removed.

The last option in the whitecap input file is whether to add small-scale texture fluctuations to the whitecaps. The three options are `no`, `yes`, or `texture`. If `yes` is picked, then replace `add_small_scale no` with the following:

  `add_small_scale` `yes`
  `size` `64 64`
  `spacing` `0.075 0.075`
  `seed` `19334`
  `power_law_length` `1.0`
  `power_law` `0.5`
  `mixing_time` `0.125`
  `log_normal_width` `0.4`
  `end`

The fluctuations are multiplicative on the whitecap reflectivity. The set of lines following `add_small_scale yes` define the characteristics of the fluctuations. The line `size` creates a patch of fluctuations of the size specified, and with facet size given by the `spacing` line. As in other cases, `seed` is just the random number seed to start the fluctuations. The fluctuations are random log-normal variations in reflectivity, with spatial and temporal statistics given in the four lines after the seed.

If `add_small_scale texture` is specified then texture maps are used to color the whitecaps. The texture maps are specified in the exact same way as the ocean surface texture maps. A sample set of whitecap texture input parameters is shown below

  `add_small_scale texture`
  `RenderWorld_data_file texture 2 2`
  `surface_type ocean`
  `number_of_textures 1`
  `location 0. 0.`
  `orientation 0.`
  `size 100. 100.`
  `periodicity 1`
  `motion 0`
  `new_picture 0`
  `file_name whitecap_texture.rgb`
  `priority 1`
  `bands 3`
  `image_above yes`
  `multiplyReflectance 0`
  `alphaAbove 0`
  `min_radiance_above 0 0 0`
  `max_radiance_above 30 30 30`
  `image_below no`
  `endTexture`

Contents