Hardware-Accelerated Visualization of Time-Varying …weiskopf/publications/vmv01.pdf · Hardware-Accelerated Visualization of Time-Varying 2D and 3D Vector Fields by Texture Advection

Hardware-Accelerated Visualization of Time-Varying 2D and 3D VectorFields by Texture Advection via Programmable Per-Pixel Operations

Daniel Weiskopf Matthias Hopf Thomas Ertl

University of Stuttgart, Institute for InformaticsVisualization and Interactive Systems Group

Breitwiesenstr. 20–22, 70565 Stuttgart, GermanyEmail: fweiskopf,hopf,[email protected]

Abstract

We present hardware-accelerated texture advectiontechniques to visualize the motion of particles insteady or time-varying vector fields given on Carte-sian grids. We propose an implementation of 2Dtexture advection which exploits advanced and pro-grammable texture fetch and per-pixel blending op-erations on an nVidia GeForce 3. For 3D vec-tor field visualization, we present an algorithm forSGI’s VPro, based on pixel textures and 3D tex-tures. Moreover, we sketch how 3D texture ad-vection could be implemented on future graphicsboards that provide programmable fetch operationsfor 3D textures. Since all implementations exclu-sively use graphics hardware without intermediatedata transfer to main memory, extremely high framerates are achieved, e.g., up to 90 frames per secondfor advecting a calculatory number of one millionparticles in a 2D flow. The proposed techniques areespecially useful for the interactive visualization ofvector fields.

1 Introduction

The visualization of 2D and 3D vector fields hasbeen investigated and used in various scientific andengineering disciplines for many years. Typical ap-plications stem from simulations in computationalfluid dynamics, calculation of physical vector fields,such as electromagnetic fields or heat flow, or frommeasurements of actual wind or fluid flows.

As flow visualization has a long tradition, vari-ous techniques exist to visually represent steady andunsteady vector fields. Among the standard tech-niques for flow visualization is the class of meth-ods based on particle tracing, such as pathlines,

streamlines, streaklines, or ribbons. The problemof placing seed points for particle tracing at ap-propriate positions is approached, e.g., by employ-ing spot noise [18, 4], LIC (line integral convolu-tion) [2, 16], texture splats [3], texture advection[12, 11], equally spaced streamlines [17], or flow-guided streamline seeding [19]. These techniqueswere originally designed to visualize steady flows.Some of these methods were extended to allow fortime-varying vector fields, e.g., with respect to LIC[7, 15] or spot noise [5].

All these approaches have in common a denserepresentation of the vector field. Therefore, theyare expensive to compute, especially when using ahigh-resolution computational domain. The maintopic of this paper is to show how texture advectioncan be simulated and visualized entirely on graph-ics hardware, thus allowing interactive visualizationof high-resolution unsteady vector fields given onCartesian grids. To achieve this goal, we exploit theprogrammable graphics pipeline of state-of-the-artlow cost graphics boards, such as nVidia’s GeForce3. The visualization of 3D flows is based on SGI’sVPro, which supports 3D textures and pixel tex-tures.

In previous work, Heidrich et al. [8] propose theuse of graphics hardware for flow visualization byLIC. Based on this approach, Jobard et al. [9] useper-fragment operations to implement texture ad-vection on graphics hardware. Some of their ideasare adopted for the visualization methods of thispaper. Therefore, we compare their approach withours and describe advantages and disadvantages ofthe different techniques in Sect. 5. Both Heidrich etal.’s and Jobard et al.’s algorithms are restricted to2D vector fields. In Sect. 4, however, we show howhardware-accelerated visualization of 3D flows canbe implemented.

VMV 2001 Stuttgart, Germany, November 21–23, 2001

The remaining parts of this paper are orga-nized as follows. In the next section, a math-ematical description of the Eulerian approach toparticle tracing—the underlying model for textureadvection—is presented, including a scheme to nu-merically solve such a texture advection problem.In Sect. 3, hardware-accelerated 2D flow visualiza-tion on a GeForce 3 is described. It is followedby an algorithm for 3D flow visualization based onSGI’s VPro. Section 5 contains some results and adiscussion of the visualization techniques of this pa-per. Finally, Sect. 6 concludes with a brief summaryand outlook on future work.

2 Eulerian Approach to Particle Trac-ing

The standard approach to particle tracing is a La-grangian approach. Here, each single particle canbe identified individually, i.e., labeled in somesense, and the properties of each particle are de-termined depending on time t. In the followingdiscussion of the Lagrangian approach, a particleis identified and labeled by its position ~r0 2 U �

Rn at an initial time t0. The underlying vector

space has dimension n, where n usually is 2 or3. The computational domain is denoted U . Inthe case of particle tracing, the properties—suchas colors—can be subsumed by a function φ whichdoes not change during time for a specific particle,i.e., we have the time-independent property func-tion φLagrangian(~r0;t) = φLagrangian(~r0). The trajec-tory of a single massless particle is determined bythe ordinary differential equation

d~r(t)dt

=~v(~r(t);t) ;

where ~r(t) describes the path of the particle and~v(~r;t) 2 U � R

n represents the vector field to bevisualized. The time t also parameterizes the path-line of the particle. Therefore, positions at arbitrarytimes t and t1 along the trajectory~r(t) of a particleare related by the integral equation

~r(t) =~r(t1)+Z t

t1~v(~r(t 0);t 0)dt 0 : (1)

From a Eulerian point of view, the property φ is afunction of position ~r and time t, as opposed to afunction of time for a fixed particle labeled by~r0 inthe Lagrangian approach. The observer is located at

a fixed position~r and measures changes of φ causedby the fact that different particles cross that posi-tion.

As the property does not change for a specificparticle, we have φ(~r;t) = φ(~r0;t0) in the Eule-rian approach if the spacetime positions (~r;t) and(~r0;t0) belong to the pathline of the same particle,cf. Eq. (1). For a continously differentiable propertyfunction, we finally obtain the advection equation

∂φ(~r;t)∂t

+~v(~r;t) �~∇φ(~r;t) = 0 :

Since φ is not even continuous in our particle trac-ing applications, we do not solve the above equationbut directly apply Eq. (1) to propagate φ throughtime. All methods based on texture advection havethis approach in common, cf., the work by Max andBecker [11], Heidrich et al. [8], or Jobard et al. [9].

To tackle the advection problem on a computer,the initial value problem for the differential equa-tion (1) has to be solved numerically and the prop-erty function φ has to be discretized. The simplestmethod to solve an ordinary differential equation isthe so-called Euler integration [13], which yields

~r(t�∆t) =~r(t)�∆t~v(~r(t);t) :

Here, an integration backward in time by a timespan ∆t > 0 is carried out. The function φ is dis-cretized on a Cartesian grid, both spatially and tem-porally. We employ the notation φτ

~ito describe a

sampling of φ at an indexed position~i 2 Nn and anindexed time τ. We identify φτ

~i= φτ

i; j in the 2D caseand φτ

~i= φτ

i; j;k in the 3D case. Without loss of gen-erality, indexed positions and physical positions arerelated by ~r = ∆r~i, where ∆r is the grid spacing.The same holds for the time t = τ∆t. Analogouslyto φτ

~i, the discretized version of the flow field is de-

noted~vτ~i

.Combining a discrete grid for φ with Euler inte-

gration for particle positions, we obtain the follow-ing numerical scheme to propagate a solution fromtime τ�1 to τ:

φτ~i= Lookup(φτ�1;~i�∆s~vτ

~i) ; (2)

with the integration step size ∆s = ∆t=∆r. On theright hand side of this equation, an interpolatedlookup in φτ�1

~ihas to be performed, since the pre-

vious position of a particle,~i�∆s~vτ~i

, is usually notidentical to a grid point. In the 2D case bilinear

440

interpolation is employed, in the 3D case trilinearinterpolation. By using an integration backward intime, the property field φτ

~iis completely filled for

the new time step; in contrast, some elements of thisfield could be missed if a forward integration fromthe previous time step was applied. For the imple-mentation of advection on graphics hardware, tex-tures represent the data grids, thus providing hard-ware support for bi- or trilinear interpolation.

Since all computations in our approach are per-formed on Cartesian grids, no explicit reference topositions is made. Positions are temporarily com-puted only in the intermediate step for the interpo-lated lookup in φτ�1

~i, but these are not stored in any

grid structure. That is an important difference to thetexture advection approaches in [11, 8, 9].

In the remaining parts of this paper, we will de-scribe how to implement this numerical scheme onOpenGL-based graphics hardware. Both 2D and 3Dcases are discussed.

3 Hardware-Based 2D Texture Advec-tion

Our implementation of 2D texture advection heav-ily relies on programmable per-pixel operationsprovided by nVidia’s GeForce 3. The simulationand rendering of texture advection is based on stan-dard OpenGL 1.2, with the following extensions[10] being included: texture shaders and registercombiners for the actual advection process; rectan-gular textures, which relax the power-of-two dimen-sions requirements for 2D textures; and pbuffers forhardware-supported off-screen rendering.

3.1 Basic Advection

The basic idea of the algorithm is as follows. Theproperty field φτ

~iis represented by a 2D image that

is normally held in a 2D texture and, only duringintermediate calculations, in the framebuffer. Thecomputational domain is determined by the extendof the image and has to be rectangular, since tex-tures are rectangular as well. The number of com-ponents in that property texture depends on the typeof application; normally, we use three RGB valuesper grid point. The vector field~vτ

~iitself is stored in

a two-component 2D texture Tv.The core of the advection algorithm uses a de-

pendent texture lookup in order to shift the particles

v

Initialize property field T

Load flow to texture T

t = 0φ

via offset texture T via dot product texture TLookup in TLookup in Tφ

v vφ

while t<tmax

Draw border

i

φiUpdate texture T or Tφ

Render quad with 4 TRender quad with Tφ φ

Next time step t = t + t∆

Inject particles

Figure 1: Structure of the 2D texture advection al-gorithm.

along the vector field. Figure 1 shows a schematicdiagram of the advection process; default opera-tions are contained within solid lines, optional op-eration in dashed lines. First, the texture Tφ holdingthe property field φτ

~iis set to its initial values; sim-

ulation time t and the corresponding value for τ areset to zero. The following steps are repeated whileincreasing the time by ∆t for each new cycle.

In this loop, the property field for the new timestep τ is computed according to Eq. (2). Two dif-ferent methods—offset textures and dependent dotproduct textures—can be used to implement the bi-linear lookup in the property texture for the previ-ous time step. These two methods will be explainedshortly. The new property grid is first rendered intothe framebuffer and then copied back into the tex-ture Tφ, thus replacing the information on the pre-vious time step. Copying from framebuffer to tex-ture memory takes place only on the graphics boardand is not slowed down by a limited bandwidth be-tween graphics subsystem and main memory. Thislast step may even be removed completely, as soonas direct rendering into texture memory is possi-ble, which has already been implemented for Di-

441

rect 3D.1 Pbuffers can be used for all these compu-tational steps. In this way, the computational partsare completely independent of visual representationon the screen; in particular, a visual window smallerthan the computational domain may be used.

For a steady flow, the simulation process is es-sentially identical; only the texture Tv is initializedwith the vector field data once. Therefore, a recur-rent transfer of texture data from main memory tothe graphics subsystem is not necessary.

Offset textures and dependent dot product tex-tures are part of the texture shader extension thatprovides programmable texture mapping within therasterization stage. A sequence of texture shadersallows a very flexible mechanism for mapping setsof texture coordinates to the actual texture.

An offset texture program transforms signed(ds;dt) components of a previous texture unit bya 2�2 floating point matrix and then uses the resultto offset the texture coordinates of the current stagefor a 2D texture fetch operation. Figure 2 showsa diagram of the offset texture process. This pro-cess contains two texture fetch operations. The firststep comprises a lookup in an offset texture basedon texture coordinates (s0;t0). An offset texture—also called DSDT texture—is a special type of 2Dtexture with two components describing the distor-tion of coordinates in the successive texture fetchfrom an RGB texture. A third, optional compo-nent can be supplied to determine a scaling of thefinal RGB colors. In the second step, a dependenttexture lookup in a standard RGB texture is per-formed. Here, another pair of texture coordinates(s1;t1) is modified by the previously fetched offsetvalues. Each component of the final RGB triplet isscaled by a factor M = kscale mag+kbias , where magis given by the offset texture and kscale and kbias areparameters constant during the whole texture pro-gram.

Offset texture programs have a one-to-one corre-spondence to the iteration equation (2). The prop-erty field φτ

~icorresponds to a standard RGB texture

(if φ has three components), the flow field ~vτ~i

cor-responds to the offset texture, (�∆s) can be rep-resented by a uniform scaling via a 2� 2 matrix.The texture coordinates (s0;t0) and (s1;t1) are iden-tical and reflect the indexed position~i. The com-putational domain is implemented by rendering a

1We decided not to use Direct 3D in order to develop aplatform-independent code.

(s ,t )0 0(s ,t )1 1

(R,G,B)(ds,dt), magDSDT tex

RGB tex

multmatrix scale

bias

Figure 2: Dependent texture lookup via offset tex-ture.

single quadrilateral with the texture coordinates setin a way to represent the corner points of the do-main. By using offset texture programs, the basicadvection process is implemented in a single pass.Then, this part of the framebuffer has to be copiedback into Tφ, so that incremental integration can becontinued in the next time step. Note that all cal-culations for the shifted, dependent texture lookupare done in floating point accuracy internally on thegraphics chip and thus accuracy is not restricted tothe resolution of color channels in the frame buffer.

In addition, we propose another, alternative ap-proach to this basic advection calculation based ondot product textures. Once again, we exploit a de-pendent texture lookup. However, it consists ofthree steps this time. In the first step, a signed RGBtexture containing the 2D flow field is accessed,where texture coordinates are chosen the same wayas above. The RGB texture contains the (vx;vy)vector in the first two components, the blue valueis set to 1. In the second step, the first coordinateux for a dependent texture lookup is computed viaa dot product. Here, the texture coordinates are setto (�∆s;0;xdomain), with xdomain corresponding tothe x coordinate of the computational domain. Af-ter having executed the dot product, the coordinate

ux = (�∆s;0;xdomain) � (vx;vy;1)

= xdomain�∆svx

is exactly the x component of the previous particleposition. In the third step, another dot product iscomputed to obtain uy. Here, the texture coordi-nates have to be set to (0;�∆s;ydomain). Still inthe third texture program stage, the new coordinates(ux;uy) are used for a dependent texture lookup inthe 2D RGB texture Tφ. This approach is normallynot useful for 2D visualization because it needs onemore texture stage than the offset-texture approach.However, the 3D extension of product textures will

442

become interesting for 3D flow visualization as de-scribed in Sect. 4.1.

As we are working with fixed-point arithmeticsin texture memory and the framebuffer for both ap-proaches, we have to assume that ~vτ

~i2 [�m;m)n,

for some extreme value m. So we can fully utilizethe value resolution of the vector field texture bystretching~v to the used texture domain. Then the in-tegration step size ∆s has to be adapted to compen-sate this scaling during the iteration step, Eq. (2).

Finally, the property field for the new time step isactually drawn to screen by rendering a quadrilat-eral equipped with the texture Tφ.

3.2 Tracing Distinguishable Structures

Texture advection can readily be applied to the vi-sualization by the motion of larger, distinguishablestructures through the flow. A prominent visual-ization technique for time-varying flows are streak-lines. These can be generated by setting values ofthe property field φτ

~iat a specified starting position

of the streakline for each time step. Steaklines pro-vide an intuitive understanding of the flow structureas they resemble dye advection used in classical, ex-perimental fluid mechanics. Dye injection was alsoused, e.g., by Shen et al. [14] and Jobard et al. [9].

Analogously, texture advection allows forstreamlines by injecting dye while the vector fieldis held constant in time. Pathlines do not easily fitinto our advection approach because older positionsof a particle are discarded during the incrementalupdate of the property field.

However, the concept of “short pathlines” canbe implemented without any additional renderingpass. Here, not the current property field Tφ isused to texture the quadrilateral in the final output.Rather the property fields for the latest npath timesteps are added, yielding moving, short segmentsof pathlines. Up to four textures can be fetched ona GeForce 3 in a single rendering pass; theses tex-tures are then blended via register combiners. Thismethods yields LIC with a limited kernel.

Note that streaklines, streamlines, and pathlinesare identical for steady flows.

3.3 Noise-Based Approach

Another technique based on texture advection ap-plies noise textures to visualize a vector field. Theessential difference to the previous dye-injection

techniques is the use of a noise texture as initialinput for the property field Tφ. Therefore, a noise-based approach can easily be incorporated in the ad-vection algorithm.

This approach is investigated in detail by Jobardet al. [9]. They propose several extensions to basictexture advection in order to improve image qual-ity and spatial and temporal correlation. First, theuse “edge correction” to allow for a continuous in-flow of noise at the borders of the computationaldomain. Secondly, they propose “noise injection”to maintain a constant noise frequency even for aflow with positive flow divergence. Thirdly, theyimplement “noise blending” to enhance spatial cor-relation along a pathline segment. These extensionscould be integrated in our advection approach sim-ilarly. In particular, noise injection could be imple-mented without any additional rendering pass, sincea noise texture can be accessed in another texturestage and XORed via register combiners.

3.4 Random Particle Injection

Another variation of texture advection employs arandomly distributed injection of particles, thuscombining the ideas of the previous two techniques.These particles are added by drawing randomly dis-tributed and colored points into the property fieldduring each iteration step, similarly to dye injection.By increasing the “inflow” and adapting the size ofnew particles, one can gradually adjust the visual-ization from being rather dye-based to being rathernoise-based, i.e., from a sparse to a dense represen-tation of the vector field.

Due to a continuous inflow of additional parti-cles, the image tends to converge to a white image inthe long term limit. Therefore, a continuous, large-scale dissipation of particles has to be employed. Itsimplementation is described in the following sub-section.

3.5 Continuous Distribution of Outflow

In Sect. 3.1, a third, optional component mag foroffset textures and a corresponding scaling of fi-nal RGB colors by a factor M = kscale mag+ kbiasis mentioned. By setting kbias = 0, mag = 1, andchoosing a value less than one for kscale, a uniformdissipation of particles can be implemented.

However, the mag component can be used in aneven more flexible way. By adjusting this part of the

443

offset texture, a gradual and locally controlled dissi-pation can be impressed. This feature can be used tomimic arbitrarily shaped outflow regions inside thecomputational domain or to fade out less importantparts of the flow field, such as regions with small ve-locity. Once again, this variant of texture advectioncomes without any additional rendering pass.

4 Extension to 3D Texture Advection

4.1 Advection Based on Texture Shaders

Unfortunately, 3D textures are not yet supportedon GeForce graphics boards in hardware, althoughthey are part of standard OpenGL 1.2. Nevertheless,corresponding operations and adapted texture shad-ing operations (NV texture shader2) have al-ready been specified by nVidia. Since we expectthis functionality to be available soon, we give abrief sketch of how the 2D algorithm from the pre-vious section could be adapted to 3D flows and whatextensions would be required for doing so.

First, both the computational domain as well asthe vector field have to be extended from 2D to 3D.This is trivial for the vector field; just a 3D texturewith three components has to be employed insteadof a 2D texture. The extension to a 3D computa-tional domain is easy, as long as the property fieldis stored as 3D texture. As the framebuffer is only2D, the intermediate results have to be stored as2D data. Here, we adopt the standard approach ofequidistant parallel slices to sample the whole vol-ume. The new property field contained in a sliceis written back into the complete 3D texture by us-ing glCopyTexSubImage3D, thus allowing anincremental update of this 3D property field. Otherthan in 2D flow advection, two versions of the prop-erty texture have to be stored to separate side effectsduring the iteration of Eq. (2).

Unfortunately, offset textures are restricted to2D. In order to adapt this approach to 3D flow visu-alization, 3D offset textures would be required. An-other approach could be based on 3D dot producttextures, analogously to the description of dot prod-uct texture programs in Sect. 3. The basic algorithmcould be as follows.

In the first texture shader stage, the data for(vx;yy;1) is fetched from a 3D texture. This tex-ture is identical to the flow field, except for the bluecomponent set to 1. The second stage fetches data

for (vz;0;1) from another modified flow data set.In the next two stages, dot products are calculatedfor shifted texture coordinates ux and uy, based onthe flow data from the first stage. The texture coor-dinates are (�∆s;0;xdomain) and (0;�∆s;ydomain),respectively. Another dot product operation duringthe fifth stage can calculate uz by using texture co-ordinates (�∆s;0;zdomain) and flow data from stagetwo. Still in the fifth texture program stage, the newcoordinates (ux;uv;uz) are used for a dependent tex-ture lookup in the 3D texture holding the propertyfield for the previous time step. Unfortunately, thecurrent GeForce 3 does only support up to four tex-ture stages. Therefore, this algorithm would workonly on improved chip sets with at least five texturestages. Since the gaming industry demands an in-creased number of texture stages, we are confidentthat this deficit will be overcome soon.

Texture-based volume rendering [1] can be easilycombined with the 3D texture advection approachin order to render the property fields. Even more ad-vanced texture-based volume rendering techniques[6] could be applied to achieve a high image qualityon that kind of consumer graphics hardware.

4.2 Advection Based on Pixel Textures

A variant of the above algorithm can be imple-mented on SGI’s Octane 2 workstations with VPrographics pipes in order to demonstrate that textureadvection is not restricted to nVidia chip sets. SGI’ssystem does not support texture shaders but thesimilar, yet not as powerful concept of pixel tex-tures. This technique allows RGB color values inthe framebuffer to be interpreted as 3D texture coor-dinates for a trilinearly interpolating texture lookup.

As pixel textures can only be applied on imag-ing operations, the temporarily computed positionshave to be explicitly written into the framebuffer,before using them as texture coordinates in the pixeltexture lookup step. Unfortunately, standard tex-ture modulation operations are not as flexible as tex-ture shaders or register combiners, thus the frame-buffer pixels representing the position informationhave to be created by rendering two quads. For thefirst quad, the colors (0;0;z), (1;0;z), (0;1;z), and(1;1;z) are assigned to the four vertices, with z be-ing the current slice number scaled to [0;1). UsingGouraud shading, this effectively leads to frame-buffer colors that would create an identity map-ping for φ. While drawing this first quad, the vec-

444

tor field texture is applied, using GL_ADD modula-tion. The looked-up texture values are first scaledby 2 m∆s

w and biased by �m∆sw in order to lift the

texture color values to the intended vector range;w denotes the size of the vector field texture inone direction. The post-filter scale and bias op-eration is, again, an SGI specific OpenGL exten-sion. As the values are clamped before modula-tion, no signed adds are possible. Therefore, asecond quad has to be drawn, this time withoutadded primary color, but scaled and biased withnegated values and blended into the framebufferwith GL_FUNC_REVERSE_SUBTRACT.

Now the framebuffer holds the positions for thenext time step, encoded in color values. The lookupcan be performed by copying the region onto itselfwith the pixel texture enabled. Finally, the slice isto be copied back into its 3D texture as with theprevious approach.

5 Results and Discussion

Figures 3–5 show examples of 2D flow visualiza-tion based on the algorithms from Sect. 3. In allexamples, the size of the computational domain is10242 and the size of the vector field is 5122. Fig-ure 3 shows the visualization of a 2D circular flowvia streaklines. Red dye is permanently injected atthree fixed positions. Despite using only Euler inte-gration, the resulting streaklines are (almost) closedto circles. With the chosen time step, a completecircle needs approximately 620 integration steps.The dye gradually smears out due to an implicit dif-fusion process. This issue of texture advection iscaused by bilinear interpolation in the property tex-ture of the previous time step.

This problem can be overcome either by noise in-jection, or by adding new, randomly distributed par-ticles, as shown in Figure 4. A uniform dissipationabsorbs this constant inflow of particles and spatialcorrelation is enhanced by using short pathlines.

Figure 5 shows the visualization of a 2D flowaround a rod by using randomly injected particlesand short pathlines. In a spherical region aroundthe center, a continuous distribution of particle out-flow with gradually changing degree of dissipationis employed.

These three examples were generated on a Win-dows PC with an Athlon 650 MHz CPU and aGeForce 3 board. In all examples, the time for one

iteration of texture advection, including the updateof the property texture Tφ, is 11 msec, correspond-ing to a frame rate of 90 fps. For the complete vi-sualization process, including the final display ona 8002 window, 37 fps are achieved. The render-ing speed is reduced to 21 fps if the unsteady vectorfield is transferred from main memory to the graph-ics subsystem in every integration step.

Figure 6 shows an example of 3D flow visual-ization by using randomly injected particles. Boththe 3D cylindrical vector field and the computa-tional domain have dimensions 1283; texture-basedvolume rendering uses approximately 380 slices.The implementation runs on an SGI Octane 2 withR12000 CPU (400 MHz) and VPro (V8). The com-putation of texture advection runs at 9 fps, the com-plete visualization process, including volume ren-dering, runs at 4 fps on a 3202 window. We findthat the injection of randomly distributed particlesis especially useful in 3D flow visualization, as thedensity of the vector field representation can begradually adjusted to achieve an appropriate, semi-transparent rendering.

Note that our methods for 2D and 3D texture ad-vection greatly benefit from time-dependent visual-ization in interactive environments because the mo-tion of particles can be fully recognized only herebut not in static images.

An advantage of our 2D texture advection algo-rithm is an extremely high simulation and renderingspeed. This method benefits from a very simple ap-proach, which allows to advect a texture by draw-ing a single quadrilateral in only a single pass. Fur-ther visualization features, such as short pathlinesor continously varied dissipation of particles comeswithout any additional rendering pass. Transferringintermediate data back into a texture is fast, sinceall operations take place entirely on the graphicsboard. The limited depth of a color channel does notrestrain the accuracy in the calculation of particlepositions because only difference vectors are storedas textures; new absolute coordinates are computedand used only within the texture stages of the ren-dering pipeline, where all computations are basedon floating-points.

Conversely to previous work, such as by Heidrichet al. [8] or Jobard et al. [9], we use a completelyEulerian approach and implementation. At no partof the rendering pipeline, particle positions are ex-plicitly stored in the framebuffer or a texture; our

445

approach needs only textures for computational do-main itself and the flow field. Moreover, we neglectsome of the image enhancement steps proposed byJobard et al. [9]. Therefore, the implementationis very simple and requires only one real render-ing pass, apart from reading results back to texturememory. In this way, e.g., we achieve 90 fps for ad-vecting a 10242 texture as opposed to 2 fps for 2562

texture with Jobard et al.’s implementation (on anOctane 1 with EMXI graphics).

For the implementation of 3D texture advection,pixel textures and 3D textures on SGI’s VPro areused. Here, one indirection step writing particlepositions into the framebuffer is required becausepixel textures can only be applied during imagecopy processes. Hence, the accuracy of computa-tion of particle positions is an issue. With a colordepth of 12 bits per channel available, sufficient ac-curacy is achieved for moderately sized volumes,such as 1283.

6 Conclusion and Future Work

We have presented very fast, hardware-based, andsimple-to-implement methods to visualize 2D and3D unsteady vector fields. We have developed an al-gorithm for 2D flows, based on consumer graphicshardware, and for 3D flows, based on SGI’s VPro.We think that these techniques are especially usefulfor interactive ad hoc visualization of flows.

In future work, we will focus on extensions of the3D approach—in particular, on the next generationof consumer graphics hardware.

Acknowledgments

We would like to thank Klaus Engel, Martin Kraus,and Manfred Weiler for fruitful discussions andhelp with the implementation.

References

[1] B. Cabral, N. Cam, and J. Foran. Accelerated vol-ume rendering and tomographic reconstruction us-ing texture mapping hardware. In Symposium onVolume Visualization, pp. 91–98, 1994.

[2] B. Cabral and L. C. Leedom. Imaging vector fieldsusing line integral convolution. In SIGGRAPH 1993Conference, pp. 263–272, 1993.

[3] R. A. Crawfis and N. Max. Texture splats for 3Dscalar and vector field visualization. In Visualization’93, pp. 261–267, 1993.

[4] W. C. de Leeuw and R. van Liere. Enhanced spotnoise for vector field visualization. In Visualization’95, pp. 359–366, 1995.

[5] W. C. de Leeuw and R. van Liere. Spotting structurein complex time dependent flow. Technical ReportSEN-R9823, CWI, Sept. 30, 1998.

[6] K. Engel, M. Kraus, and T. Ertl. High-qualitypre-integrated volume rendering using hardware-accelerated pixel shading. In Workshop on GraphicsHardware, 2001.

[7] L. K. Forssell and S. D. Cohen. Using line integralconvolution for flow visualization: Curvilinear grids,variable-speed animation and unsteady flows. IEEETransactions on Visualization and Computer Graph-ics, 1(2):133–141, June 1995.

[8] W. Heidrich, R. Westermann, H.-P. Seidel, andT. Ertl. Application of pixel textures in visualizationand realistic image synthesis. In ACM Symposiumon Interactive 3D Graphics, pp. 127–134, 1999.

[9] B. Jobard, G. Erlebacher, and M. Y. Hussaini.Hardware-accelerated texture advection for un-steady flow visualization. In Visualization 2000,pp. 155–162, 2000.

[10] M. J. Kilgard, editor. NVIDIA OpenGL ExtensionSpecifications. NVIDIA Corporation, 2001.

[11] N. Max and B. Becker. Flow visualization usingmoving textures. In D. C. Banks, T. W. Crockett,and S. Kathy, editors, ICASE/LaRC Symposium onVisualizing Time Varying Data, pp. 77–87, 1996.

[12] N. Max, R. Crawfis, and D. Williams. Visualizingwind velocities by advecting cloud textures. In Visu-alization ’92, pp. 171–178, 1992.

[13] W. H. Press, S. A. Teukolsky, W. T. Vetterling, andB. P. Flannery. Numerical Recipes in C. CambridgeUniversity Press, second edition, 1994.

[14] H.-W. Shen, C. R. Johnson, and K.-L. Ma. Visualiz-ing vector fields using line integral convolution anddye advection. In Symposium on Volume Visualiza-tion, pp. 63–70, 1996.

[15] H.-W. Shen and D. L. Kao. A new line integral con-volution algorithm for visualizing time-varying flowfields. IEEE Transactions on Visualization and Com-puter Graphics, 4(2):98–108, June 1998.

[16] D. Stalling and H.-C. Hege. Fast and resolution in-dependent line integral convolution. In SIGGRAPH1995 Conference, pp. 249–256, 1995.

[17] G. Turk and D. Banks. Image-guided stream-line placement. In SIGGRAPH 1996 Conference,pp. 453–460, 1996.

[18] J. J. van Wijk. Spot noise-texture synthesis for datavisualization. In SIGGRPAPH 1991 Conference,pp. 309–318, 1991.

[19] V. Verma, D. Kao, and A. Pang. A flow-guidedstreamline seeding strategy. In Visualization 2000,pp. 163–170, 2000.

446

531

Figure 3: Visualization of a 2D circular flow(vx;vy) = (y;�x). Red dye is permanently injectedat three fixed positions, yielding a visualization viastreaklines.

Figure 4: Visualization of a 2D circular flow, basedon randomly injected particles. Short pathlines com-prising the last four integration steps are used to en-hance spatial correlation. A uniform dissipation ab-sorbs the constant inflow of particles.

Figure 5: Visualization of a 2D flow around a rodby using randomly injected particles and short path-lines. In a spherical region around the center, a con-tinuous distribution of particle outflow with gradu-ally varying degree of dissipation is employed.

Figure 6: Visualization of a 3D cylindrical flow,based on randomly injected particles.

D. Weiskopf, M. Hopf, Th. Ertl: Hardware-Accelerated Visualization of Time-Varying 2-D and�. . . � (p. 439)

531