Warning: Can't synchronize with the repository (Couldn't open Subversion repository /home/crystal/scm/crystal: SubversionException: ("Expected FS format between '1' and '3'; found format '4'", 160043)). Look in the Trac log for more information.

The cloud system has been partly implemented by Julian Mautner [julian dot mautner at gmail dot com] during Google Summer of Code 2008.

General

The cloud system is a fully dynamic, physically (approximately) correct simulation of clouds with the respective rendering and illumination. It simulates the evolution of an initial empty cloud field using various (partial) differential equations coming from fluid flow, thermodynamics, mechanics, water condensation and evaporation (water continuity). The result of this simulation is a discrete volume of size X*Y*Z containing the condensed water mixing ratios, which are responsible for clouds to get visible.

The renderer takes this volume as input and does the rendering using a two pass technique. First a oriented light volume (OLV) is computed and afterwards based on the OLV the cloud from the users point of view is rendered. The lighting algorithm takes multiple light scattering as well as attenuation, absorbtion and reflection into account. The result is a highly realistic looking cloud.

Most of the used algorithms and ideas are taken from the dissertation of Mark Jason Harris: Real-Time Cloud Simulation and Rendering  http://www.markmark.net/dissertation/harrisDissertation.pdf

Implementation

There are four main classes: csCloudSystem, csClouds, csCloudsDynamics, csCloudsRenderer.

csCloudSystem: This class is designed for the direct user interaction. It respresents and entire cloud field. The user may add or remove clouds to the field. Basically this class is a simple factory class of csClouds. The CloudsRenderer requires this class to be registered in the object registry.

csClouds: This is the supervisor class for the dynamics and the rendering. It represents a single cloud volume. It holds an instance of csCloudsDynamics and csCloudsRenderer and does all the communication between these different classes. It offers the user the entire configuration API for the dynamics as well as for the rendering part. Also, it catches the frame event to let the simulation and rendering go on and calls the right methods of both classes at the right time. In addition it provides some tuning parameter, in order that the calculation amount may be limited per invocation and split up over more frames.

csCloudsDynamics: This class takes care of the entire dynamic part of the cloud simulation. It implements the various physical functions and delivers as output the voxel volume of condensed water mixing ratios. For the computation itself MAC-grids are used. This means condensed water mixing ratios, water vapor mixing ratios, potential temperature and pressure are defined at each cell center, while velocities are defined at min-faces of each grid cell. The class provides also the possibility to limit the amount of calculation per DoTimeStep() invocation. The user may specify a certain number of iterations which may be done approximately every invocation. In this way the computation time in a single frame may be regulated quite precisely.

csCloudsRenderer: For rendering a voxel volume the renderer uses the technique of slice-wise rendering and blending in eye direction. In this way the user sees only a two dimensional image perpendicular to it's view direction (like a billboard). The rendering is efficient, and the user will hardly see the difference. The advantage is that the image is stored in a texture. Thus, when the eye direction changes too much (overrunning a certain tolerance), or when the dynamic simulation provides a new data volume, this image may be updated. Due to this trick, the bottleneck of the clouds simulation is the dynamic part (especially the part solving the poisson pressure equation). A big part of the renderer comes in form of an extension of the rendermanager. Since slice wise rendering is quite a specific rendering task, it wasn't supported by CS. This is why the extension is needed. Basically it creates a context for each slice which has to be rendered, because of the lighting equations recurrence. The rendering output of the last slice is needed to render the next slice, providing an iterative rendering system.

To do

  • Test the extension of the RM
  • Continue implementing the illumination algorithm provided by Harris
  • Test the correctness of the physical simulation (by watching the graphical output)
  • Create a quad for each slice and assign it to the right context
  • Write the shader for the right blending operations
  • Integrate the rendering process into csClouds
  • Debug everything