EUROGRAPHICS 2001 / A. Chalmers and T.-M. Rhyne Volume 20 (2001), Number 3(Guest Editors)

© The Eurographics Association and Blackwell Publishers 2001. Published by BlackwellPublishers, 108 Cowley Road, Oxford OX4 1JF, UK and 350 Main Street, Malden, MA02148, USA.

Real-Time Cloud Rendering

Mark J. Harris and Anselmo Lastra

Department of Computer Science, University of North Carolina, Chapel Hill, North Carolina, USA

{harrism, lastra}@cs.unc.edu

AbstractThis paper presents a method for realistic real-time rendering of clouds suitable for flight simulation and games. Itprovides a cloud shading algorithm that approximates multiple forward scattering in a preprocess, and first orderanisotropic scattering at runtime. Impostors are used to accelerate cloud rendering by exploiting frame-to-framecoherence in an interactive flight simulation. Impostors are shown to be particularly well suited to clouds, even incircumstances under which they cannot be applied to the rendering of polygonal geometry. The method allowshundreds of clouds and hundreds of thousands of particles to be rendered at high frame rates, and improvesinteraction with clouds by reducing artifacts introduced by direct particle rendering techniques.

1. Introduction

“Beautiful day, isn’t it?”“Yep. Not a cloud in the sky!”

Uncommon occurrences such as cloudless skies often elicitsuch common figures of speech. Clouds are such an integralfeature of our skies that their absence from any syntheticoutdoor scene can detract from its realism. Unfortunately,interactive applications such as flight simulators often sufferfrom cloudless skies. Designers of these applications haverelied upon similar techniques to those used by renaissancepainters in ceiling frescos: distant and high-flying clouds arerepresented by paintings on an always-distant sky dome. Inaddition, clouds in flight simulators and games have beenhinted at with planar textures – both static and animated – orwith semi-transparent textured objects and fogging effects.

There are many desirable effects associated with cloudsthat are not achievable with such techniques. In aninteractive flight simulation, we would like to fly in andaround realistic, volumetric clouds, and to see other flyingobjects pass within and behind them. Current real-timetechniques have not provided users with such experiences.This paper describes a system for real-time cloud renderingthat is appropriate for games and flight simulators.

In this paper we focus on high-speed, high-qualityrendering of constant-shape clouds for games and flightsimulators. These systems are already computationally andgraphically loaded, so cloud rendering must be very fast. Forthis reason, we render realistically shaded static clouds, and

do not address issues of dynamic cloud simulation. Thischoice enables us to generate clouds ahead of time, and toassume that cloud particles are static relative to each other.This assumption speeds the rendering of the clouds becausewe need only shade them once per scene in a preprocess.

The rest of this section presents previous work. Section 2gives a derivation and description of our shading algorithm.Section 3 discusses dynamically generated impostors andshows how we use them to accelerate cloud rendering. Wealso discuss how we have dealt with issues in interactingwith clouds. Section 4 discusses our results and presentsperformance measurements. We conclude and discuss ideasfor future research in section 5.

Figure 1: Realistic clouds in the game “Ozzy’s Black Skies”.

Harris and Lastra / Real-Time Cloud Rendering

© The Eurographics Association and Blackwell Publishers 2001.

1.1 Previous Work

We segment previous work related to cloud rendering intotwo areas: cloud modeling and cloud rendering. Cloudmodeling deals with the data used to represent clouds in thecomputer, and how the data are generated and organized.We build our clouds with particle systems. Reevesintroduced particle systems as an approach to modelingclouds and other such “fuzzy” phenomena in [Reeves1983].Voxels are another common representation for clouds.Voxel models provide a uniform sampling of the volume,and can be rendered with both forward and backwardmethods. Procedural solid noise techniques are alsoimportant to cloud modeling as a way to generate random butcontinuous density data to fill cloud volumes [Lewis1989,Perlin1985, Ebert1998]. [Kajiya1984] introduced thesimulation of cloud formation via approximations of realphysical processes, and [Dobashi2000] used a physicalapproximation simulated with cellular automata. Anotherimportant representation for clouds has been metaballs, or“blobs” [Stam1991, Stam1995, Dobashi2000].

Much previous work has been done in non-interactiverendering techniques for clouds. Rendering clouds isdifficult because realistic shading requires the integration ofthe effects of optical properties along paths through the cloudvolume, while incorporating the complex scattering withinthe medium. Previous work has attempted to approximatethe physical characteristics of clouds at various levels ofaccuracy and complexity, and then to use these approximatemodels to render images of clouds. Blinn introduced the useof density models for image synthesis in [Blinn1982], wherehe presented a low albedo, single scattering approximationfor illumination in a uniform medium. Kajiya and VonHerzen extended this work with methods to ray trace volumedata exhibiting both single and multiple scattering[Kajiya1984]. Gardner represented clouds with texturedellipsoids, and recently [Elinas2001] extended Gardner’smethod to render clouds made of multiple ellipsoids in realtime. Max provided an excellent survey in which hesummarized the spectrum of optical models used in volumerendering and derived their integral equations from physicalmodels [Max1995]. Ebert has done much work in modeling

“solid spaces”, including offline computation of realisticimages of smoke, steam, and clouds [Ebert1990, Ebert1997].Stam simulated light transport in gases using diffusionprocesses [Stam1995]. Nishita et al. introducedapproximations and rendering techniques for globalillumination of clouds accounting for multiple anisotropicscattering and skylight [Nishita1996].

Our rendering approach draws most directly from recentwork by Dobashi et al., which presents both an efficientsimulation method for clouds and a hardware-acceleratedrendering technique [Dobashi2000]. The shading methodpresented by Dobashi et al. implements an isotropic singlescattering approximation. We extend this method with anapproximation to multiple forward scattering and anisotropicfirst order scattering. The animated cloud scenes of Dobashiet al. required 20-30 seconds rendering time per frame. Oursystem renders static cloudy scenes at tens to hundreds offrames per second, depending on scene complexity.

2. Shading and Rendering

Particle systems are a simple and efficient method forrepresenting and rendering clouds. Our cloud model assumesthat a particle represents a roughly spherical volume inwhich a Gaussian distribution governs the density fallofffrom the center of the particle. Each particle is made up of acenter, radius, density, and color. We get goodapproximations of real clouds by filling space with particlesof varying size and density. Clouds in our system can bebuilt by filling a volume with particles, or by using anediting application that allows a user to place particles andbuild clouds interactively. The randomized method is a goodway to get a quick field of clouds, but we intend our cloudsfor interactive games with levels designed and built byartists. Providing an artist with an editor allows the artist toproduce beautiful clouds tailored to the needs of the game.

We render particles using splatting [Westover1991], bydrawing screen-oriented polygons texture-mapped with aGaussian density function. Although we chose a particlesystem representation for our clouds, it is important to notethat both our shading algorithm and our fast renderingsystem are independent of the cloud representation, and canbe used with any model composed of discrete densitysamples in space.

2.1 Light Scattering Illumination

Scattering illumination models simulate the emission andabsorption of light by a medium as well as scattering throughthe medium. Single scattering models simulate scatteringthrough the medium in a single direction. This direction isusually the direction leading to the point of view. Multiplescattering models are more physically accurate, but mustaccount for scattering in all directions (or a sampling of alldirections), and therefore are much more complicated andexpensive to evaluate. The rendering algorithm presented byDobashi et al. computes an approximation of illumination ofclouds with single scattering. This approximation has been

Figure 2: A view of an interactive flight through clouds.

Harris and Lastra / Real-Time Cloud Rendering

© The Eurographics Association and Blackwell Publishers 2001.

used previously to render clouds and other participatingmedia [Blinn1982, Kajiya1984].

In a multiple scattering simulation that samples Ndirections on the sphere, each additional order of scatteringthat is simulated multiplies the number of simulated paths byN. Fortunately, as demonstrated by [Nishita1996], thecontribution of most of these paths is insignificant. Nishitaet al. found that scattering illumination is dominated by thefirst and second orders, and therefore they only simulated upto the 4th order. They reduced the directions sampled in theirevaluation of scattering to sub-spaces of high contribution,which are composed mostly of directions near the directionof forward scattering and those directed at the viewer. Wesimplify further, and approximate multiple scattering only inthe light direction – or multiple forward scattering – andanisotropic single scattering in the eye direction.

Our cloud rendering method is a two-pass algorithmsimilar to the one presented in [Dobashi2000]: weprecompute cloud shading in the first pass, and use thisshading to render the clouds in the second pass. Thealgorithm of Dobashi et al., however, uses only an isotropicfirst order scattering approximation. If realistic values areused for the extinction and albedo of clouds shaded with onlya first order scattering approximation, the clouds appear verydark [Max1995]. This is because much of the illumination ina cloud is a result of light scattered forward along the lightdirection. Figures 8 and 9 show the difference in appearancebetween clouds shaded with and without our multipleforward scattering approximation.

2.1.1 Multiple Forward Scattering

The first pass of our shading algorithm computes the amountof incident light at each position P from direction l. Thislight, I(P, l), is composed of all direct light from direction lthat is not absorbed by intervening particles, plus lightscattered to P from other particles. The multiple scatteringmodel is written

,),()(),(0

)()(

00 ∫

∫+

∫⋅=

−− PPD

s

PD

D dttdtt

dsesgeIPIττ

ωωω (1)

where I0(ω) is the intensity of light in direction ω outside thecloud, τ(t) is the extinction coefficient (in units of 1 / length)of the cloud at depth t, DP is the depth of P in the cloudalong the light direction, and

')',()',,(),(4∫=π

ωωωωω dxIxrxg (2)

represents the light from all directions ω′ scattered intodirection ω at the point x. Here r(x,ω,ω′) is the bi-directionalscattering distribution function (BSDF), and determines thepercentage of light incident on x from direction ω′ that isscattered in direction ω. It expands to r(x,ω,ω′) =

a(x)⋅τ(x)⋅p(ω,ω′), where a(x) is the albedo of the medium atx, and p(ω,ω ′) is the phase function.

A full multiple scattering algorithm must compute thisquantity for a sampling of all light flow directions. Wesimplify our approximation to compute only multipleforward scattering in the light direction, so ω = l, and ω ′ = -l.To do so, we approximate the integration of (2) over only asmall solid angle γ around the forward direction. Becausethis solid angle is small, we also assume r and I to beconstant over γ. Thus, (2) reduces tog(x,l) = r(x,l,-l) ⋅ I(x,-l) ⋅ γ / 4π.

We split the light path from 0 to DP into discrete segmentssj, for j from 1 to N, where N is the number of cloud particlesalong the light direction from 0 to DP. By approximating theintegrals with Riemann Sums, we have

∑ ∏∏= +=

−

=

− +⋅=N

j

N

jkk

N

jP

kj egeII1 11

0 .ττ (3)

I0 is the intensity of light incident on the edge of the cloud.In discrete form g(x,l) becomes gk = ak⋅⋅⋅⋅τk⋅⋅⋅⋅p(l,-l)⋅⋅⋅⋅Ik⋅⋅⋅⋅γ /4π. Weassume that albedo and optical depth are represented atdiscrete samples (particles) along the path of light. In orderto easily transform (3) into an algorithm that can beimplemented in graphics hardware, we cast it as a recurrencerelation:

.1,

2,

0

111

=≤≤⋅+

= −−−kI

NkITgI kkkk (4)

If we let Tk = ke τ− be the transparency of particle pk, then(4) expands to (3). This representation can be moreintuitively understood. It simply says that starting outsidethe cloud, as we trace along the light direction the lightincident on any particle pk is equal to the intensity of lightscattered to pk from pk-1 plus the intensity transmitted throughpk-1 (as determined by its transparency, Tk-1). Notice that if gkis expanded in (4) then Ik-1 is a factor in both terms. Section2.2 explains how we combine frame buffer read back withhardware blending to evaluate this recurrence.

2.1.2 Eye Scattering

In addition to approximating multiple forward scattering, wealso implement single scattering toward the viewer as in[Dobashi2000]. The recurrence for this is subtly different:

.1,1 NkETSE kkkk ≤≤⋅+= − (5)

This says that the light, Ek, exiting any particle pk is equalto the light incident on it that it does not absorb, Tk · Ek-1, plusthe light that it scatters, Sk. In the first pass, we werecomputing the light Ik incident on each particle from the lightsource. Now, we are interested in the portion of this lightthat is scattered toward the viewer. When Sk is replaced byak⋅⋅⋅⋅τk⋅⋅⋅⋅p(ω, -l)⋅⋅⋅⋅Ik / 4π, where ω is the view direction and Tk is

Harris and Lastra / Real-Time Cloud Rendering

© The Eurographics Association and Blackwell Publishers 2001.

as above, this recurrence approximates single scatteringtoward the viewer. It is important to mention that (5)computes light emitted from particles using results (Ik)computed in (4). Since illumination is multiplied by thephase function in both recurrences, one might think that thephase function is multiplied twice for the same light. This isnot the case, since in (4), Ik-1 is multiplied by the phasefunction to determine the amount of light Pk-1 scatters to Pkin the light direction, and in (5) Ik is multiplied by the phasefunction to determine the amount of light that Pk scatters inthe view direction. Even if the viewpoint is directly oppositethe light source, since the light incident on Pk is stored andused in the scattering computation, the phase function isnever taken into account twice at the same particle.

2.1.3 Phase Function

The phase function p(ω,ω’) mentioned above is veryimportant to cloud shading. Clouds exhibit anisotropicscattering of light (including the strong forward scatteringthat we assume in our multiple forward scatteringapproximation). The phase function determines thedistribution of scattering for a given incident light direction.Phase functions are discussed in detail in [Nishita1996],[Max1995], and [Blinn1982], among others. The imagesshown in this paper were generated using a simple Rayleighscattering phase function, p(θ) = 3/4(1 +cos2θ), where θ isthe angle between the incident and scattered directions.Rayleigh scattering favors scattering in the forward andbackward directions, but occurs in nature only for aerosols ofvery small particles. We chose it for its simplicity, and goodresults, and plan to try more physically based functions.Figures 10 and 11 demonstrate the differences betweenclouds shaded with and without anisotropic scattering.Anisotropic scattering gives the clouds their characteristic“silver lining” when viewed looking into the sun.

2.2 Rendering Algorithm

Armed with recurrences (4) and (5) and a standard graphicsAPI such as OpenGL or Direct3D, computation of cloudillumination is straightforward. Our algorithm is similar tothe one presented by [Dobashi2000] and has two phases: ashading phase that runs once per scene and a rendering phasethat runs in real time. The key to the implementation is theuse of hardware blending and pixel read back.

Blending operates by computing a weighted average ofthe frame buffer contents (the destination) and an incomingfragment (the source), and storing the result back in theframe buffer. This weighted average can be written

destdestsrcsrcresult cfcfc ⋅+⋅= (6)

If we let cresult = Ik, fsrc = 1, csrc = gk-1, fdest = Tk-1, andcdest = Ik–1, then we see that (4) and (6) are equivalent if thecontents of the frame buffer before blending represent I0.This is not quite enough, though, since as we saw before, Ik-1is a factor of both terms in (4). To solve the recurrence for aparticle pk, we must know how much light is incident on

particle pk-1 beforehand. To do this, we employ pixel readback.

To compute (4) and (5), we use the procedure describedby the pseudocode in Figure 3. The pseudocode shows thatwe use a nearly identical algorithm for preprocess andruntime. The differences are as follows. In the illuminationpass, the frame buffer is cleared to white and particles aresorted with respect to the light. As a particle is blended intothe frame buffer, the transparency of the particle modulatesthe color and adds an amount proportional to the forwardscattering. Immediately before it is rendered, the lightincident on pk from a small solid angle γ is found by readingback the color of a small square of pixels centered on theprojection of pk. The number of pixels needed to sample γ iscomputed using the distance of pk from the projection planeof the camera. The average of these pixels is multiplied byr(x,l,-l) as in section 2.1.1. Ik is computed by multiplying

source_blend_factor = 1;dest_blend_factor = 1 – src_alpha;texture_mode = modulate;l = direction from light;if (preprocess) then

ω = -l;view cloud from light source;clear frame buffer to white;particles.Sort(,dist. from eye);

endif

γ = solid angle of pixels to read.foreach particle pk[pk has extinction τk, albedo ak,radius rk, color, and alpha]if (preprocess) thenCompute # pixels np needed to

cover solid angle γ ;Read np pixels in square around

projected center of pk;ik = Average intensity of np pix;ik *= light_color;pk.color = ak * τk * ik * γ / 4π;pk.alpha = 1 - exp(-τk);

elseω = pk.position – view_position;

endifc = pk.color * phase(ω, l);render pk with color c, side 2*rk;

endfor

[Note: Sort( means sort indescending order. Pixel values areassumed to lie in [0,1] here.]

Figure 3: Pseudocode for cloud shading and rendering.

Harris and Lastra / Real-Time Cloud Rendering

© The Eurographics Association and Blackwell Publishers 2001.

this result by the light intensity, and is then used to computemultiple forward scattering in (4) and eye scattering in (5).

In the runtime phase we use the same algorithm, but withparticles sorted with respect to the viewpoint, and withoutreading pixels. The precomputed illumination of eachparticle Ik is used in this phase to compute scattering towardthe eye.

In both passes, particles are rendered in sorted order aspolygons textured with a Gaussian function. The polygoncolor is set to the scattering factor ak⋅⋅⋅⋅τk⋅⋅⋅⋅p(ω,l)⋅⋅⋅⋅Ik / 4π and thetexture is modulated by this color. In the first pass, ω is thelight direction, and in the second pass it is the direction ofthe viewer. The source and destination blending factors areset to 1 and one minus source alpha, respectively. All cloudimages in this paper and the accompanying video werecomputed with a constant τ of 80, and an albedo of 0.9.

2.2.1 Skylight

The most awe-inspiring images of clouds are provided by themulti-colored spectacle of a beautiful sunrise or sunset.These clouds are often not illuminated directly by the sun atall, but by skylight – sunlight that is scattered by theatmosphere. The fact that light accumulates in an additive

manner provides us with a simple extension to our shadingmethod that allows the creation of such beautiful clouds. Wesimply shade clouds from multiple light sources and store theresulting particle colors (ik in the algorithm above) from allshading iterations. At render time, we evaluate the phasefunction at each particle once per light. By doing so, we canapproximate global illumination of the clouds. Two lightswere used in each of the images in this paper to keep shadingtimes low, but an arbitrary number can be used.

This technique is better than an ambient contribution,since it is directional and results in shadowing in the cloudsas well as anisotropic scattering from multiple lightdirections and intensities. We obtain good results by guidingthe placement and color of these lights using the images thatmake up the sky dome we place in the distance over ourenvironments. Figure 12 demonstrates this with a scene atsunset in which we use two light sources, one orange and onepink, to create sunset lighting. In addition to illuminationfrom multiple light sources, we include an ambient term toprovide some compensation for lost scattered light due to ourscattering approximation.

3. Dynamically Generated Impostors

While the cloud rendering method described above providesbeautiful results and is fast for relatively simple scenes, itsuffers under the weight of many complex clouds. Theinteractive games for which we developed this system dictatethat we must render complicated cloud scenes at fastinteractive rates. Clouds are only one component of acomplex game environment, and therefore can only use asmall percentage of a frame time, with frame rates of thirtyper second or higher. With direct particle rendering, even ascene with a few tens of thousands of particles isprohibitively slow on current hardware.

The integration required to accurately render volumetricmedia results in high rates of pixel overdraw. Clouds haveinherently high depth complexity, and require blending,making rendering a difficult job even for current hardwarewith the highest fill rates. In addition, as the viewpointapproaches a cloud, the projected area of that cloud’sparticles increases, becoming greatest when the viewpoint iswithin the cloud. Thus, pixel overdraw is increased andrendering slows as the viewpoint nears and enters clouds.

In order to render many clouds made up of many particlesat high frame rates, we need a way to bypass fill ratelimitations, either by reducing the amount of pixel overdrawperformed, or by amortizing the rendering of cloud particlesover multiple frames. Dynamically generated impostorsallow us to do both.

[Maciel1995], [Schaufler1995], and [Shade1996] alldiscuss impostors. An impostor replaces an object in thescene with a semi-transparent polygon texture-mapped withan image of the object it replaces (Figure 4). The image is arendering of the object from a viewpoint V that is valid(within some error tolerance) for viewpoints near V.

Figure 4: Impostors: textured, view-oriented polygons.

Figure 5: Impostor generation and translation error metric.

Harris and Lastra / Real-Time Cloud Rendering

© The Eurographics Association and Blackwell Publishers 2001.

Impostors used for appropriate points of view give a veryclose approximation to rendering the object itself. Animpostor is valid (with no error) for the viewpoint fromwhich its image was generated, regardless of changes in theviewing direction. Impostors may be precomputed for anobject from multiple viewpoints, requiring much storage, orthey may be generated only when needed. We choose thelatter technique, called dynamically generated impostors by[Schaufler1995].

We generate impostors using the following procedure. Aview frustum is positioned so that its viewpoint is at theposition from which the impostor will be viewed (thecapture point), and it is tightly fit to the bounding volume ofthe object (Figure 5). We then render the object into animage used to texture the impostor polygon.

As mentioned above, we can use impostors to amortizethe cost of rendering clouds over multiple frames. We dothis by exploiting the frame-to-frame coherence inherent inthree-dimensional scenes: the relative motion of objects in ascene decreases with distance from the viewpoint, andobjects close to the viewpoint present a similar image forsome time. This lack of sudden changes in the image of anobject allows us to re-use impostor images over multipleframes. We can compute an estimate of the error in animpostor representation that we then use to determine whenthe impostor needs to be updated. Certain types of motionintroduce error in impostors more quickly than others.[Schaufler1995] presents two worst-case error metrics forthis purpose. The first, which we will call the translationerror, computes error caused by translation from theviewpoint at which the current impostor was generated. Thesecond computes error introduced by moving straight towardthe object, which we call the zoom error.

We use the same translation error metric, and replacezoom error by a texture resolution error metric. For thetranslation error metric, we simply compute the angle αtransinduced by translation relative to the capture point (Figure5), and compare it to a specified tolerance. The zoom errormetric compares the current impostor texture resolution tothe required resolution for the texture, computed using thefollowing equation [Schaufler1995]

.distobject

sizeobjectresolutionresolution screentexture ⋅=

If either the translation error is greater than an error toleranceangle or the current resolution of the impostor is less than therequired resolution, we regenerate the impostor from thecurrent viewpoint. We find that a tolerance of about 0.15degree reduces impostor “popping” to an imperceptible levelwhile maintaining good performance. For addedperformance, tolerances up to one degree can be used withonly a little excessive popping.

In the past, impostors were used mostly to replacegeometric models. Since these models have high frequenciesin the form of sharp edges, impostors have usually been usedonly for distant objects. Nearby objects must have impostor

textures of a resolution at or near that of the screen, and theirimpostors require frequent updates. We use impostors forclouds no matter where they are in relation to the viewer.Clouds have fewer high frequency edges than geometricmodels, so artifacts caused by low texture resolution are lessnoticeable. Clouds have very high fill rate requirements, socloud impostors are beneficial even when they must beupdated every few frames.

3.1 Head in the Clouds

Impostors can provide a large reduction in overdraw even forviewpoints inside the cloud, where the impostor must beupdated every frame. The “foggy” nature of clouds makes itdifficult for the viewer to discern detail when inside them. Inaddition, in games and flight simulators, the viewpoint isoften moving. These factors allow us to reduce theresolution at which we render impostor textures for cloudscontaining the viewpoint by about a factor of 4 in eachdimension.

However, impostors cannot be generated in the samemanner for these clouds as for distant clouds, since the viewfrustum cannot be tightly fit to the bounding volume asdescribed above. Instead, we use the same frustum used todisplay the whole scene to generate the texture for theimpostor, and display these impostors as screen-spacerectangles sized to fill the screen.

3.2 Objects in the Clouds

In order to create effective interactive cloudy scenes, wemust allow objects to pass in and through the clouds, and wemust render this realistically. Impostors pose a problembecause they are two-dimensional. Objects that pass throughimpostors appear as if they are passing through imagesfloating in space, rather than through fluffy, volume-fillingclouds.

One way to solve this problem would be to detect cloudsthat contain objects and render their particles directly to theframe buffer. By doing so, however, we lose the benefitsthat impostors provide us. Instead, we detect when objectspass within the bounding volume of a cloud, and split theimpostor representing that cloud into multiple layers. If only

Figure 6: An airplane in the clouds. Left: particlesdirectly rendered into the scene; artifacts of intersectionswith wings are visible. Right: the airplane renderedbetween impostor layers; no visible artifacts.

Harris and Lastra / Real-Time Cloud Rendering

© The Eurographics Association and Blackwell Publishers 2001.

one object resides in a certain cloud, then that cloud isrendered as two layers: one for the portion of cloud particlesthat lies approximately behind the object (we considerparticles to be behind an object if they are farther from theeye than its center point) with respect to the viewpoint, andone for the portion that lies approximately in front of theobject. If two objects lie within a cloud, then we need threelayers, and so on. Since cloud particles must be sorted forrendering anyway, splitting the cloud into layers adds littleexpense. This “impostor splitting” results in a set ofalternating impostor layers and objects. This set is renderedfrom back to front, with depth testing enabled for objects,and disabled for impostors. The result is an image of a cloudthat realistically contains objects, as shown on the right sideof Figure 6.

Impostor splitting provides an additional advantage overdirect particle rendering for clouds that contain objects.When rendering cloud particles directly, the billboards usedto render particles may intersect the geometry of nearbyobjects. These intersections cause artifacts that break theillusion of particles representing elements of volume.Impostor splitting avoids these artifacts (Figure 6).

4. Results and Discussion

We have implemented our cloud rendering system using boththe OpenGL and DirectX 8 APIs. We have tested theOpenGL-based system on both Windows PC systems and anSGI Onyx2 with InfiniteReality2 graphics. On a PC with anNVIDIA GeForce 256 graphics processor, we can achievevery high frame rates by using impostors and view-frustumculling to accelerate rendering. We can render scenescontaining over one hundred thousand particles at high framerates (greater than 50 frames per second). If the viewpointmoves slowly enough to keep impostor update rates low, wecan render a scene of more than 1.2 million particles at about10 to 12 frames per second. Slow movement is a reasonableassumption for flight simulators and games because theuser’s aircraft is typically much smaller than the cloudsthrough which it is flying, so the frequency of impostorupdates remains low.

As mentioned before, our shading phase is a preprocess.For scenes with only a few thousand particles shading takesless than a second, and scenes of a few hundreds thousandparticles can be shaded in about five to ten seconds per lightsource.

We have performed several tests of our cloud system andpresent the results here. Our test machine is a PC with 256MB of RAM and an Intel Pentium III processor running at800 MHz. It uses an NVIDIA GeForce 256 graphics cardwith 32MB of video RAM.

The tests rendered scenes of increasing cloud complexity(from 100 to 12800 clouds of 200 particles each) with andwithout using impostors. We also tested the performance fordifferent types of movement. The first test moved thecamera around a circular path, and the second moved thecamera through the clouds in the direction of view. The

results of our tests are shown in Figure 7. The chart showsthat using impostors was faster than not using them for thelarge range of scene complexity that we covered, and thateven for scenes with several hundred thousand particles weachieve interactive frame rates.

Our cloud rendering algorithms have been incorporatedinto the game “Ozzy’s Black Skies”, by iROCK Interactive.In this game, players ride fantastical flying creatures throughbeautiful environments with realistically shaded volumetricclouds. The clouds are interesting in an interactive sense, asplayers may momentarily hide in them as they pass through.The steps we have taken to ensure high frame rates for cloudrendering makes our system work well in an alreadygraphics- and computation-laden game engine. Impostorsprovide a means of scalability that is necessary in gamesintended to run on a wide range of hardware. Performanceand quality can be balanced by adjusting impostor errortolerances and texture resolution.

5. Conclusion and Future Work

We have presented methods for shading and renderingrealistic clouds at high frame rates. Our shading andrendering algorithm simulates multiple scattering in the lightdirection, and anisotropic single scattering in the viewdirection. Clouds are illuminated by multiple directionallight sources, with anisotropic scattering from each.

0.1

1

10

100

1000

2000

0

4000

0

8000

0

1600

00

3200

00

6400

00

1280

000

2560

000

Number of particles

Fra

me

Rat

e(f

ram

es/s

ec)

Linear path No Impostor s

Linear path Impostor s

Cir cular Path No Impostor s

Cir cular Path Impostor s

Figure 7: Results of performance measurements forcloudy scenes of varying complexity rendered with andwithout impostors.

Harris and Lastra / Real-Time Cloud Rendering

© The Eurographics Association and Blackwell Publishers 2001.

Our method uses impostors to accelerate cloud renderingby exploiting frame-to-frame coherence and greatly reducingpixel overdraw. We have shown that impostors are anadvantageous representation for clouds even in situationswhere they would not be successfully used to represent otherobjects, such as when the viewpoint is in or near a cloud.Impostor splitting is an effective way to render clouds thatcontain other objects, reducing artifacts caused by directparticle rendering.

Since our shading algorithm computes multiple forwardscattering during the illumination phase, it should bestraightforward to extend it to compute an approximation ofglobal multiple scattering. This would require running manypasses to evenly sample all directions, and accumulating theresults at the particles. We are also researching methods forspeeding cloud shading by avoiding pixel read back, so thatwe can shade and render dynamic clouds in real time. Thiswill allow the visualization of cloud formation in aninteractive simulation.

Currently we are limited in the size of clouds that we areable to render at high frame rates, because large cloudsrequire high-resolution impostors that are expensive toupdate. We would like to render dense fields of immensecumulonimbus clouds in real time. In order to solve thisproblem, we will explore hierarchical image caching[Shade1996] and other work that has been done withimpostors.

Beyond clouds, we think that other phenomena mightbenefit from our shading algorithm. For example, we wouldlike to be able to render realistic interactive flight throughstellar nebulae. Nebulae can be modeled as particle cloudswith emissive properties, and rendered with a modifiedversion of our algorithm.

For more information and color images, please visithttp://www.cs.unc.edu/~harrism/clouds.

Acknowledgements

This work would not have been possible without the support,encouragement, and ideas of the developers at iROCKInteractive, especially Wesley Hunt, Paul Rowan, BrianStone, and Robert Stevenson. Mary Whitton and FrederickBrooks at UNC provided help and support. Rui Bastos gavehelp with the paper and ideas for the future, and SharifRazzaque helped with modeling. This work was supportedby NIH National Center for Research Resources, Grant No.P41 RR 02170, Department of Energy ASCI program,National Science Foundation grant ACR-9876914 andiROCK Interactive.

References

[Blinn1982] J. Blinn, “Light Reflection Functions for Simulationof Clouds and Dusty Surfaces”. SIGGRAPH 1982, pp. 21-29

[Dobashi2000] Y. Dobashi, K. Kaneda, H. Yamashita, T. Okita,and T. Nishita. “A Simple, Efficient Method for RealisticAnimation of Clouds”. SIGGRAPH 2000, pp. 19-28

[Ebert1990] D. S. Ebert, R. E. Parent, “Rendering andAnimation of Gaseous Phenomena by Combining Fast VolumeScanline A-Buffer Techniques,” SIGGRAPH 1990, pp. 357-366.

[Ebert1997] D. S. Ebert, “Volumetric Modeling with ImplicitFunctions: A Cloud is Born,” Visual Proceedings of SIGGRAPH1997, pp.147.

[Ebert1998] D. S. Ebert, F.K. Musgrave, D. Peachey, K. Perlin,S. Worley, Texturing & Modeling: a Procedural Approach.1998, AP Professional.

[Elinas2001] P. Elinas, W. Stuerzlinger, “Real-time Renderingof 3D Clouds”, to appear in Journal of Graphics Tools, 2001.

[Gardner1985] G. Gardner, “Visual Simulation of Clouds”,SIGGRAPH 1985, pp. 297-303.

[Kajiya1984] J. Kajiya and B. Von Herzen. “Ray TracingVolume Densities”. SIGGRAPH 1984, pp. 165-174.

[Lewis1989] J. Lewis. “Algorithms for Solid Noise Synthesis”.SIGGRAPH 1989, pp. 263-270.

[Maciel1995] P. Maciel, P. Shirley. “Visual Navigation of LargeEnvironments Using Textured Clusters”. Proceedings of the1995 symposium on Interactive 3D graphics, 1995, Page 95

[Max1995] N. Max. “Optical Models for Direct VolumeRendering”, IEEE Transactions on Visualization and ComputerGraphics, vol. 1 no. 2, June 1995.

[Nishita1996] T. Nishita, Y. Dobashi, E. Nakamae. “Display ofClouds Taking into Account Multiple Anisotropic Scattering andSky Light.” SIGGRAPH 1996, pp. 379-386.

[Perlin1985] K. Perlin. An Image Synthesizer. SIGGRAPH1985, pp. 287-296.

[Reeves1983] W. Reeves. “Particle Systems – A Technique forModeling a Class of Fuzzy Objects”. ACM Transactions onGraphics, Vol. 2, No. 2. April 1983. ACM.

[Reeves1985] W. Reeves and R. Blau. “Approximate andProbabilistic Algorithms for Shading and Rendering StructuredParticle Systems”. SIGGRAPH 1985, pp. 313-322.

[Schaufler1995] G. Schaufler, “Dynamically GeneratedImpostors”, GI Workshop Modeling - Virtual Worlds -Distributed Graphics, 1995, pp 129-136.

[Shade1996] J. Shade, D. Lischinski, D. Salesin, T. DeRose, J.Snyder, “Hierarchical Image Caching for AcceleratedWalkthroughs of Complex Environments”. SIGGRAPH 1996,pp. 75-82.

[Stam1991] Jos Stam and Eugene Fiume. "A Multiple-ScaleStochastic Modelling Primitive", Proceedings of GraphicsInterface '91, June 1991, pp. 24-31.

[Stam1995] Jos Stam and Eugene Fiume. "Depiction of Fire andOther Gaseous Phenomena Using Diffusion Processes",SIGGRAPH 1995, pp. 129-136.

[Westover1990] L. Westover, “Footprint evaluation for volumerendering” SIGGRAPH 1990, Pages 367 - 376

Harris and Lastra / Real-Time Cloud Rendering

© The Eurographics Association and Blackwell Publishers 2001.

Figure 8: Shading with multiple forward scattering.

Figure 9: Shading with only single scattering.

Figure 10: Clouds with anisotropic scattering.

Figure 11: Clouds with isotropic scattering.

Figure 12: An example of shading from two light sources to simulate skylight. This scene was rendered with two lights,one orange and one pink. Anisotropic scattering simulation accentuates the light coming from different directions. Seesection 2. (See the electronic version for a color version of images).