Visualization of Time-Varying Curvilinear Grids Using a 3D Warp Texture

Yuan Chen, Jonathan Cohen, Subodh Kumar

Johns Hopkins University, Department of Computer ScienceNEB 224, 3400 North Charles Street, Baltimore, MD 21209, USA

Email: {cheny,cohen,subodh}@cs.jhu.edu

Figure 1: Fragment algorithm for rendering a time-varying curvilinear grid using a 3D warp texture.

Abstract

We present a novel scheme to interactively visual-ize time-varying scalar fields defined on a curvilin-ear grid. We create a 3D warp texture that mapspoints in R3 into the grid coordinate system. At ren-dering time, the warping function is reconstructedat each fragment using tri-linear interpolation, andprovides the 3D texture coordinates required to lookup a scalar field value stored in a separate scalartexture. In essence, this approach reduces the prob-lem of rendering a curvilinear grid to the problem ofrendering a regular grid with one additional texturelookup.

Because the curvilinear grid data typically lies ona regular grid in its native space, the scalar data iseasily stored in a 3D texture without the need forexplicit resampling. For many time-varying datasets, the warping function itself is constant overtime, so only the 3D scalar texture needs to be re-loaded with each time step. Thus this factorization

of the problem minimizes the bandwidth require-ments for time-varying playback. We demonstratethe approach on several data sets, achieving interac-tive performance with low approximation error.

1 IntroductionA curvilinear (structured) grid is topologicallya uniform, Cartesian grid, but is geometricallywarped into R3, a Euclidean space. For example,curvilinear grids specify a warped position for eachdata point and assume some interpolation functionfor locations between the data points. Curvilineargrids are convenient for applications such as com-putational fluid dynamics because they provide aregular grid space for the simulation while provid-ing an adaptive sampling of the domain space. InEulerian simulations, the mapping of the grid intothe domain space is fixed over time, whereas inLagrangian simulations, that mapping may changeover time. Both styles of simulation are widely used

VMV 2005 Erlangen, Germany, November 16–18, 2005

in practice.As with regular and unstructured grids (tetrahe-

dral meshes), curvilinear grids may be rendered us-ing customized ray tracing [4] and cell projectiontechniques [11, 8]. In fact, it is even quite com-mon to tetrahedralize the grid cells and render as anunstructured grid. This is exemplified by the factthat many papers describing unstructured grid ren-dering actually use test data that originated as struc-tured grids (such as NASA’s blunt fin and delta wingmodels). This approach has the benefit of leverag-ing advances in the rendering of this more generalmesh structure [10] and may produce high qualityimages using cell projection. However, even thevery fastest tetrahedral mesh rendering algorithmwe are aware of currently achieves a maximum ren-dering throughput of 1.8 million tetrahedra per sec-ond [1]. For the largest data set we report here,containing roughly 2.3 million cells (or 11.5 mil-lion tetrahedra) we would thus expect a maximumperformance of 6 seconds per frame, which is notinteractive. Such an approach suffers from an in-ability to leverage information about the curvilineargrid’s simple topological structure.

A typical, higher-performance approach to ren-dering curvilinear grids involves resampling thescalar data into a regular grid, either at a fixed res-olution or hierarchically [6]. Such resampling ad-mits fast, hardware-accelerated rendering via 3Dtextures, using either slicing and blending tech-niques [12] or hardware raycasting [5]. However,resampling the scalar data at each time step not onlydramatically increases the total data size, but alsopotentially introduces unnecessary resampling arti-facts. The choice of resampling resolution deter-mines both the quality of each time step and the datatransfer size for loading each time step to the graph-ics hardware.

In contrast to this direct resampling, we proposea novel approach that still combines regular sam-pling with 3D texture-based volume rendering, butwith an important difference – we do not resamplethe scalar field except at the pixel level. By us-ing one level of texture indirection, we effectivelyleverage pre-computed point location queries fromEuclidean space into the grid space. For Euleriansimulation data, this warp texture does not changeover time, and thus is easily cached in texture mem-ory on the graphics hardware. At rendering time,we can now load the scalar data for each time step

in its original grid-space sampling pattern as a 3Dtexture, avoiding the additional bandwidth requiredto maintain high quality rendering for direct resam-pling approaches.

Our approach has a number of desirable features:• Applies to a general class of curvilinear grids,

without any requirement for an analytical andinvertible function from grid space to Eu-clidean space.

• Does not require run-time sorting of cells.• Leverages the topological structure of the

curvilinear grid.• Converts the problem of rendering curvilinear

grids to the problem of rendering regular gridswith one level of indirection.

• Enables storage of scalar data at the originalsampling rate on the graphics card and avoidsresampling of scalar data until pixel shadingtime.

2 Algorithm

As mentioned above, our approach leverages theregular topological structure of the grid to providea natural mapping to graphics hardware. We real-ize that the structured data in fact lies on a recti-linear lattice in some warped space, just not in R3

(see Figure 2a for a 2D example). Let us denotethis space by the triple (s, t, r). The scalar valueis sampled on a lattice: at regular intervals in s, t,and r. Indeed, a structured grid is often specifiedby a three dimensional array of scalar values alongwith an unwarping function, or a table, that specifiesthe R3 location of each lattice point. Thus the timevarying scalar data itself may be directly stored asa 3D texture in that warped space – call it the gridscalar texture S. Of course, this texture is not reg-ular in R3 and thus may not be directly rendered astextured slices. Instead, we use a regular R3 grid tosample the inverse of the structured grid’s unwarp-ing function. The resulting warping texture, W , ef-fectively serves as a voxel-based parameterizationof R3. Now we can find the scalar value at anypoint in R3, denoted by (u, v, w), by first lookingup the warp texture (s, t, r) = W (u, v, w) to findits 3D warped coordinate, and then looking up thescalar value from the grid texture: S(s, t, r).

This indirect texturing approach has some inher-ent advantages over a standard resampling algo-rithm. First, for Eulerian grids, which have a con-

stant warping function over all time steps, we createa single warping texture, W , to describe the param-eterization of space, and re-use it for all the time-varying scalar values. Second, the scalar data itselfremains as compact as in its original form, and thusrequires minimal bandwidth to load to texture mem-ory and a minimal footprint to store there. Third,the warping texture sometimes requires less resolu-tion to maintain good quality rendering than doesthe direct resampling of the scalar texture. Thisis due to the fact that warping functions are of-ten largely smooth and well-approximated by thetri-linear interpolation performed on the hardware.The scalar values themselves tend to have higherfrequency content and many discontinuities. Fur-thermore, by avoiding directly resampling the scalarfield, we eliminate one resampling of this data, de-laying its resampling to the stage of rendering in-dividual pixels. Any error induced by sampling thewarping function has the effect of distorting the datain space rather than changing the actual scalar val-ues portrayed. Such a change in the nature of errorhas been previously deemed effective in the domainof polygon mesh simplification [2]. As a result ourtechnique is effective not only to reduce the datasize for time-varying scalar fields, but also for staticscalar fields.

Crawford et al.’s recent work on visualization ofGyrokinetic data [3] also takes the approach of stor-ing the scalar data in a 3D texture domain and warp-ing it back into Euclidean space at run-time. How-ever, their algorithm is rather specific to the render-ing of twisted torroidal domains. It involves bothresampling of the scalar data and the use of a knownanalytical function for the torroidal warp. Our warptexture approach does not involve such resamplingand does not require an analytical representation forthe warp function.

Our work is foreshadowed by the work of Rezk-Salama et al. [9], which was tuned to operate onan earlier generation of graphics hardware. Theydeform a uniform grid of points from a base posi-tion (our grid coordinate system) into a deformedspace (our Euclidean domain), and approximate theinverse transformation of this deformation by negat-ing the translation vectors. Rendering is performedusing object-aligned slicing, where a triangle meshwith deformed texture coordinates is rendered foreach slice. A number of extensions are proposedat a very high level for future hardware capabili-

Figure 2: (a) An 8x4 curvilinear grid is shown overthe regular gridlines of R3. Black samples arecenters of interior voxels, white samples those ofboundary voxels, and unmarked samples those ofexterior voxels. (b) Three cases of boundary match-ing (in 2D). The white boundary voxels are com-puted using extrapolation so as to match the warp-ing function at the grey points along the structuredgrid boundary.

ties, including the use of indirection with 3D tex-tures to specify the warp function. Our work pro-vides all the important and non-trivial details of thissuggested approach as well as an implementationapplied to the rendering of curvilinear grids. Wedevelop algorithms for better generation of the in-verted deformation, handling of the boundary con-ditions, measuring approximation error, etc.

3 Warp Texture Generation

The essential data component for our rendering al-gorithm is the warp texture, W, a voxel-based ap-proximation to the inverse of the curvilinear grid’sunwarping function, Wi. Thus, each value in thewarp texture describes a mapping back into the grid(scalar) texture domain and may be applied as tex-ture coordinates to look up interpolated values fromthe original scalar data.

The generation of the warp texture is primarilya sampling process. The warp texture is definedto cover the bounding box of the curvilinear gridunwarped into the R3 domain. (We also refer tothe cells of a regular rectilinear R3 grid as voxels.)Given some R3 grid resolution, a voxel may be clas-sified as interior, boundary, or exterior, according toits relationship with the warped cells of the struc-tured grid, as shown in Figure 2a.

3.1 Sampling Interior Voxels

To compute the values of W at the centers of theinterior voxels, we perform a point location queryof each voxel sample (its center) within the cellsof the structured grid. Such a query should reportwhich cell, if any, contains the sample location, andwhere the sample is within that cell (i.e., its (s, t, r)coordinate). If there is such a cell, then the voxel isan interior voxel, and the matching grid coordinatesare stored at that voxel (such as the black samplesin Figure 2a).

In case the unwarp function is analytically speci-fied and invertible, one can compute the warp func-tion at each voxel center. In the more general case,however, when only the value of the unwarp func-tion is provided at a set of given points in the gridspace, we reconstruct the function from these sam-ples first. This reconstruction is defined as a simpletri-linear interpolation to match hardware tri-linearfiltering.

To answer the point location query, in our im-plementation, we tetrahedralize the structured grid.We locate the voxel center in the tetrahedron con-taining it (if one exists) and then use the barycentriccoordinates within that tetrahedron to compute themapping to grid space.1

We later use hardware tri-linear texture filteringto compute the warp function for each fragment. Itis worth noting that with the prescient knowledgeof this subsequent tri-linear interpolation, we mightalternatively compute the voxel center sample val-ues more intelligently to reduce the difference be-tween the interpolant and the inverse function ev-erywhere in between samples. However, this sub-stantially complicates the procedure.

A variety of methods are applicable to speed upthe sequence of point location queries. In order toexploit coherence, we perform the queries withinthe outermost grid cells first, and then walk fromvoxel to voxel, following stabbing lines through thetetrahedra. Spatial data structures such as octreesand k-D trees are also good candidates for this ac-celeration.

1This tetrahedralization for point-location should not be con-fused with algorithms that permanently tetrahedralize a structuredgrid as a means of performing the entire rendering process.

3.2 Extrapolating Boundary VoxelsBy sampling the interior voxels, we have effectivelybound their centers to their accurate positions in thegrid space. This, in turn, implies that each grid sam-ple, (s, t, r), is bound to some point W−1(s, t, r)in R3, where W−1 is close to W−1

i . However, it isespecially important to ensure that the boundariesof the structured grid, which do not generally passthrough the centers of voxels, are accurately ren-dered. We take special care at the grid boundaries.In particular, we also locate all the boundary vox-els as well as reproduce a set of samples on the gridboundary precisely. Recall that a boundary voxel isone that is adjacent to an interior voxel but is notitself an interior voxel (using the convention that avoxel has 26 adjacent voxels in 3D).

We associate each boundary voxel with a latticepoint on the grid boundary, as shown in Figure 2b.We choose the grid boundary point to be the inter-section of the grid boundary with a line connectingthe boundary voxel with one of its interior neigh-bors. Whenever possible, this line is parallel toone of the coordinate axes, but we use a diago-nal line when no axis-aligned neighbor pairing isavailable.2 For each of these intersection computa-tions, we trace the line from the interior voxel to theboundary voxel, walking from tetrahedron to tetra-hedron until the structured grid boundary intersec-tion is found. In cases where more than one possibleneighbor pairing is available, we select one arbitrar-ily.

Given an interior voxel, a boundary voxel, and aboundary intersection, we apply a simple extrapola-tion to determine the warp texture value to store atthe boundary voxel.

As a result of this extrapolation, the warp tex-ture now contains texture coordinates both insideand outside the valid grid domain. The texture co-ordinates outside the valid domain are used to al-low us to interpolate right up to the structured gridboundary. When we come to a pixel whose inter-polated value in the warp texture lookup lies out-side the valid grid domain, we map that fragment totransparent black. As a result, the grid does not con-tribute color to any fragment outside the grid bound-ary.

2If the corners and edges of the grid domain map to sharp fea-tures in the Euclidean space, it may be advantageous to force someof the matched grid boundary points to lie along these sharp fea-tures.

Figure 3: (a) It is possible for a voxel to be bothabove and below the curvilinear grid (mapped intoR3), resulting in the appearance of an extraneousgrid. (b) The colors indicate how fragments withinthose regions are classified. White: forced to betransparent by stencil = 0. Light grey: elimi-nated due to warp values outside [0, 1]. Dark grey:boundary fragments with warp values in [0, 1] andstencil > 0. Black: interior points with warp val-ues in [0, 1] and stencil = 1.

3.3 Stenciling Exterior Voxels

We refer to voxels that are not adjacent to an interiorvoxel as exterior voxels. The entire neighborhoodaround these exterior voxels should always be ren-dered as transparent black. One might like to assignto these voxels warp values outside the valid griddomain so that they too may be mapped to transpar-ent black. However, this is not generally possible,depending on how the grid warps in R3. For ex-ample, see Figure 3a. The warp function takes s

component values greater than 1 as we proceed be-yond the s = 1 boundary, as shown by the arrow.At the same time, s takes values less than 0 beyondthe s = 0 boundary. This necessarily causes adja-cent voxels, like A and B to get warp values greaterthan 1 and less than 0, respectively. Thus the inter-polated values of s for points between A and B fallinto the range [0, 1], mapping them to points insidethe structured grid.

To avoid this problem, we supplement the warp-ing texture with a 3D binary stencil texture. Thisstencil texture is set to 1 at all interior voxels and0 at all boundary and exterior voxels. At render-ing time, we test the linearly interpolated value ofthis stencil texture, and set the pixel’s output colorto transparent black if the stencil texture evaluatesto exactly 0 (as depicted in Figure 3b). This effec-tively eliminates the rendering of all exterior voxelneighborhoods, and thus we do not need to care

what value is stored in the actual warp texture forexterior voxels. The extraneous grid may yet appearwithin a voxel if opposite boundaries pass throughthe same voxel. We generally avoid this by choos-ing a sufficient voxel resolution such that oppositeboundaries are separated into separate voxels (seeSection 5.3 for handling of cases where this is notpossible).

This stenciling approach bears some resemblanceto our prior work [6]. However, we are operatinghere in a different domain that requires a very dif-ferent procedure. In the prior work, the scalar datais being resampled, and the regions just outside theboundary are padded with copies of the boundaryscalar data, then clipped away by the stencil tex-ture. Here we are operating on a warp texture byextrapolating the warping function to position thegrid boundary in the correct location.

4 Error Computation

Apart from numerical errors, the main source of er-ror in our technique is the approximate reconstruc-tion of the warp-function from the samples at voxelcenters. In order to measure this error, we com-pute the difference of the interpolant from the actualwarp function at each point of R3. For a point, pe,in Euclidean space, we evaluate the warping textureat W (pe) using tri-linear interpolation of neigh-boring voxel centers to compute its correspondingpoint, pg , in grid space. Now we use the originalinverse warp function provided with the curvilineargrid to map pg to its correct location, p′

e, in Eu-clidean space. We measure the error as |pe − p′

e|,a distance of displacement in R3. This is effec-tively the distance from where we are rendering aparticular scalar value to where that scalar valueought to appear. If desired, this object-space dis-tance may also be conservatively projected at run-time into screen space to indicate the warping er-ror in pixel-sized units that account for perspectiveforeshortening.

It is worth noting that we have chosen to measurethe error in the warp function itself. A more directapproach may be to measure the error in the result-ing scalar values, if they are known in advance. Thisis helpful primarily if the scalar values are gener-ally R3-coherent – in other words, grid coordinatesclose in R3 have similar scalar values. Similarly,one could measure the color error resulting from

application of the transfer function to the incorrectscalar value. However, such error measures seemless informative to us than our measurement of ge-ometric distortion in the warping function.

5 Subtleties

The use of one level of indirection in our texture-based volume rendering algorithm gives rise to sev-eral more subtle issues that are worth discussing inmore detail. These are issues related to the limitedprecision of the warp texture, to the polygonal slicesused for rendering, and to degenerate grid specifica-tions.

5.1 Precision IssuesWhen we specify texture coordinates to the graph-ics driver in the typical way, by binding them to in-dividual vertices, we can send the data in a varietyof formats. They ultimately arrive in floating pointregisters in the fragment processing unit, so we canpotentially take advantage of the full floating pointprecision. In practice, the number of mantissa bits isa good estimate of the useful precision of a floatingpoint texture coordinate, due to the limited range ofinterest, so we essentially have access to 24 bits.

However, when we specify texture coordinates aselements of an actual texture, as we do with ourwarp texture, our precision is limited by the sup-ported internal texture formats. For example, ifwe wish to store the warp texture in a single 3Dtexture on our current hardware (NVIDIA GeForce6800), we can choose from a four-channel texturewith either 8 bits integer precision per channel or 16bits floating point precision per channel.3 The fourchannels may be used to store the three texture coor-dinate dimensions plus the stencil texture. The 8 bitoption is rather small. 16 bits floating point some-what better, although it is difficult to make gooduse of the exponent bits. The use of multiple tex-tures (and thus multiple texture lookups), allows usto use integer texture formats with 16 bits per chan-nel, which currently gives us the best quality, at theexpense of more texture lookups. We can expect in-creased support for the 32-bit floating point textureformats in future graphics hardware, so this prob-lem will likely go away soon.

332-bit floating point textures do not yet support trilinear inter-polation.

5.2 Slicing DistanceAnother interesting issue which arises in our settingis the choice of a distance to use between polyg-onal slices during rendering. In a standard voxelgrid, all the scalar samples are equally spaced, soit is straightforward to choose a reasonable spacingof planes to incorporate all the data. In our case,however, the scalar data is still non-uniformly dis-tributed in R3. This makes choosing an inter-planedistance a tougher problem. One useful approachis to vary the inter-plane distance according to theportion of the space being sliced (i.e. the distancebetween successive pairs of planes varies). Our cur-rent approach is to incorporate progressive refine-ment as well as user-controlled refinement, whichworks reasonably well in an interactive system. Us-ing our warp texture formulation in a hardware-accelerated ray caster may provide increased oppor-tunities for adaptive step sizes.

5.3 Grid DegeneraciesIn some cases, the warping of the grid into Eu-clidean space as specified by the original grid datamay contain degeneracies. For example, the gridshown in Figure 3 could close into a toroidal con-figuration. In this case, there is no way to keep theboundaries separate during rendering. Such a de-generacy occurs, for example, in the NASA OxygenPost data set. In this case, it is generally possible tosplit the original grid into multiple grids such thatno single grid has a degenerate configuration. Wethen sort these grids with respect to each other atrender time and render them in sorted order. Thisapproach may also be used to handle curvilineargrids with multiple zones. The actual implemen-tation of this is ongoing work for us.

6 Implementation And ResultsWe have implemented the warp texture genera-tion algorithm as well as the rendering algorithmon a Windows PC equipped with 2.8 GHz IntelXeon CPU, 2 GB RAM, AGP 8X bus, and anNVIDIA Geforce 6800 GT with 256 MB VRAM.3D texture-based volume rendering is performedwith viewport-aligned slicing. A custom fragmentprogram uses the R3 location as an index into thewarp and stencil texture. The results of the warptexture lookups are scaled and biased, then used

to perform the scalar texture lookup. The scalartexture, which has been quantized to one byte perscalar, is then used to index a final transfer functiontexture, which maps the scalar value to RGBA ac-cording to a user-specified transfer function. Thetransfer functions may be mapped linearly or loga-rithmically across the scalar range, and the user mayexplicitly update the quantization to reflect the cur-rent range of interest.

The preprocessing time for generating the warptexture was less than 20 minutes for the highest res-olution warp textures and much less for the lowerresolution ones. We have not yet devoted significanteffort to optimizing this stage because the time istrivial compared to the time to generate the simula-tion data (e.g., 50 hours times 288 CPUs, or 14,400CPU hours, to generate the KDPhrd data set), andcan be performed in parallel with the actual simula-tion computation if desired.

Figure 4 presents some data for several test mod-els. The BluntFin and Tapered Cylinder (Figure 6)are well known data distributed by NASA. KDPhrd(Figure 7 is a simulation of turbulent gas around ablack hole.

We see that even small resolutions for the warptexture provide reasonable accuracy. The mean er-ror remains rather small with respect to the warptexture voxel size.

We timed the run-time performance of our warptexture volumes using a window size of 640x480,with the object just filling that window and rotating.We use glTexSubImage3D() to load the nexttime step’s scalar data before rendering each frame.For consistency, we use 800 slices for all these tim-ing tests. Because we are generally fragment bound,the frame rate generally varies with the number offragments. We currently perform two two-channel,16-bit integer texture lookups4 to fetch the warpand stencil textures before looking up the scalar andtransfer function in two additional lookups. Thenumber of unnecessary fragments is directly relatedto the percentage of empty volume in the object’sbounding box (these fragments may be killed be-fore actually looking up the scalar data and transferfunction). Due to our warp texture approach, whichkeeps the scalar texture size small, the texture load-ing is not a bottleneck. Should the simulation gridsize exceed the bus bandwidth for some application,

4Driver and hardware advances should soon reduce this to asingle lookup.

it may be more appropriate to employ a scalar fieldcompression based on vector quantization of eachvoxel over some number of time steps [7].

We also present a set of visual quality compar-isons in Figure 5. The two images rendered usingwarp textures exhibit warping error as well as someringing artifacts at the boundary of the sphericalcut-out at the core of the original domain. The im-ages rendered using direct resampling exhibit scalardata errors that become color errors. We believethe warping error is preferable – its size shrinkswith the distance of the viewer to the images, asyou can see by stepping back from your paper orcomputer monitor. The resampling error remainsobjectionable even as it becomes smaller on yourretina. Note that the goal of this comparison isnot to compare warp resolution to direct resamplingresolution. Recall that the warp texture resides intexture memory throughout visualization, with onlythe original scalar resolution loaded for each timestep (e.g., 192x192x64), whereas the direct resam-pling method requires the resampled resolution tobe loaded at each time step.

7 Conclusions and Future Work

We have presented and demonstrated a new 3Dtexture-based algorithm for visualization of time-varying curvilinear grids. By factoring a staticwarping function out from the time-varying scalardata, we essentially convert the problem of render-ing curvilinear grids to the problem of renderingregular grids with an additional level of indirection.The use of a precomputed 3D warp texture serves asan accelerated point location query from Euclideanspace into grid space. Our approach eliminates theneed to resample the scalar data for each time stepand maintains a relatively low space requirement forstoring and transmitting the data.

We are currently developing methods for assign-ing adaptive warp texture resolution across the Eu-clidean domain to reduce error in a localized fash-ion and also for dealing with more degenerate andmultizone data sets. Although we have demon-strated the use of our warp texture in the context ofslice-based volume rendering of curvilinear grids, itshould be useful in other contexts as well, such asray casting of curvilinear grids, particle and stream-line tracing through curvilinear grids, etc.

Figure 4: Statistics for several data sets. Grid resolution is the number of data points in the curvilinear grid.Time steps is the number of scalar data values available per grid point. Warp resolution is the resolution ofthe created warp texture. Mean error and standard deviation are measured as a percentage of the boundingbox diagonal (i.e., error/diagonal*100). Frame rates are for time-varying data, using 640x480 windowresolution and 800 slices.

8 Acknowledgments

We would like to thank Julian Krolik and John Haw-ley for providing the astronomical data which moti-vates this work and also NASA for the blunt fin andtapered cylinder data. This work was supported inpart by NSF ITR Grant AST-0313031.

References

[1] S. Callahan, M. Ikits, J. Comba, and C. Silva.Hardware-assisted visibility sorting for un-structured volume rendering. IEEE Transac-tions on Visualization and Computer Graph-ics, 11(3):285–295, 2005.

[2] J Cohen, M Olano, and D Manocha.Appearance-preserving simplification. InMichael Cohen, editor, SIGGRAPH 98, An-nual Conference Series, pages 115–122, Or-lando, FL, 1998. Addison Wesley.

[3] D Crawford, K Ma, M Huang, S Klasky,and S Ethier. Visualizing gyrokinetic simula-tions. In IEEE Visualization 2004, pages 59–66, 2004.

[4] L Hong and A Kaufman. Accelerated ray-casting for curvilinear volumes. In IEEE Vi-sualization ’98., pages 247–254, 1998.

[5] J. Kruger and R. Westermann. Accelerationtechniques for gpu-based volume rendering.In IEEE Visualization 2003, pages 287–292,2003.

[6] J. Leven, J. Corso, J. Cohen, and S. Ku-mar. Interactive visualization of unstruc-

tured grids using hierarchical 3d textures. InIEEE/SIGGRAPH Symposium and Volume Vi-sualization and Graphics 2002, pages 37–44,2002.

[7] E. Lum, K. Ma, and J. Clyne. Texture hard-ware assisted rendering of time-varying vol-ume data. IEEE Visualization 2001, pages255–262 and 562, 2001.

[8] N. Max, P. Williams, and C. Silva. Cell pro-jection of meshes with non-planar faces. InData Visualization: The State of the Art, pages157–168. Kluwer, 2003.

[9] C. Rezk-Salama, M. Scheuering, G. Soza, andG. Greiner. Fast volumetric deformation ongeneral purpose hardware. In 2001 ACM SIG-GRAPH/Eurographics Workshop on GraphicsHardware, pages 17–21, 2001.

[10] S. Roettger, S. Guthe, A. Schieber, and T. Ertl.Convexification of unstructured grids. In Pro-ceedings of Workshop on Vision, Modeling,and Visualization 2004, pages 283–292, 2004.

[11] A. Van Gelder. Rapid exploration of curvi-linear grids using direct volume rendering. InIEEE Visualization ’93, pages 70–77, 1993.

[12] R. Westermann and T. Ertl. Efficiently usinggraphics hardware in volume rendering appli-cations. In SIGGRAPH 98, pages 169–177,1998.

Figure 5: KDPhrd astronomical simulation data with density values logarithmically mapped to hue. (a)White square indicates zoom-in region for b through e, which is the site of the most densely space gridsamples. (b) Warp texture resolution 256x256x256. (c) Warp texture resolution 128x128x128. (d) Directresampling at resolution 256x256x256. (e) Direct resampling at resolution 128x128x128. The error forwarp-based renderings is visible as geometric distortions, as opposed to the color errors present in directresamplings.

Figure 6: Rendering of the NASA BluntFin with a 128x128x256 warp texture and Tapered Cylinder with a256x256x128 warp texture.

Figure 7: Several time steps in a temporal sequence from the KDPhrd astronomical simulation data. Thescalar field represents the Poynting flux.