UPTEC F 15 048
Examensarbete 30 hp Juni 2015
Efficient and Accurate Volume Rendering on Face-Centered and Body-Centered Cubic Grids
Karl-Oskar Smed
Teknisk- naturvetenskaplig fakultet UTH-enheten
Besöksadress:
Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0
Postadress:
Box 536 751 21 Uppsala
Telefon:
018 – 471 30 03
Telefax:
018 – 471 30 00
Hemsida:
http://www.teknat.uu.se/student
Abstract
Efficient and Accurate Volume Rendering on Face-Centered and Body-Centered
Karl-Oskar Smed
The body centered cubic grid (BCC) and face centered cubic grid (FCC) offer improved sampling properties when compared to the cartesian grid. Despite this there is little software and hardware support for volume rendering of data stored in one of these grids. This project is a continuation of a project adding support for such grids to the volume rendering engine Voreen. This project has three aims. Firstly, to implement new interpolation methods capable of rendering at interactive frame rates.
Secondly, to improve the software by adding an alternate volume storage format offering improved frame rates for BCC methods. And thirdly, because of the issues when comparing image quality between different grid types due to aliasing, to implement a method unbiased in terms of post-aliasing. The existing methods are compared to the newly implemented ones in terms of frame rate and image quality and the results show that the new volume format improve the frame rate significantly, that the new BCC interpolation method offers similar image quality at better
performance compared to existing methods and that the unbiased method produces images of good quality at the expense of speed.
Ämnesgranskare: Robin Strand
Handledare: Elisabth Linnér & Johan Nysjö
Sammanfattning
Vid lagring av volymdata är det kartesiska gittret absolut vanligast. Det är dock inte optimalt ur samplingssynpunkt då det har visats att både det kubiska rymdcentrerade gittret (BCC) och det kubiska ytcentrerade gittret (FCC) återger mer information med samma antal samlingspunkter.
Nackdelen med att lagra volymdata med något av dessa två gitter är att det finns väldigt lite verktyg för att behandla och visualisera informationen. Det här är ett fortsättningsprojekt som går ut på att vidareutveckla en
tilläggsmodul som lägger in stöd för att rendera volymdata lagrad på både BCC och FCC -gitter till volymrenderingsmjukvaran Voreen.
I projektet implementeras både nya interpolationsmetoder och förbättringar av existerande. En ny volymlagringsstruktur implementerades för en av dom existerande metoderna för BCC med syfte att snabba upp metoden. Även en ny interpolationsmetod för BCC-gitter implementerades. Artefakter som beror på vilken typ av gitter volymdatan är lagrad på är ett problem vid bildkvalitetsjämförelser mellan olika metoder. Därför implementerades också en metod som kan återge volymdatan rättvist med avseende på gittertyp.
Både tester av bildkvalitet och renderingssnabbhet utförs där dom nya metoderna jämförs med dom existerande. Resultaten visar att den nya volymlagringsstrukturen ökar renderingshastigheten märkvärdigt, att den nya BCC-metoden erbjuder likvärdig bildkvalitet och är snabbare än dom
existerande och att den rättvisa metoden är väldigt långsam men producerar bilder av god kvalitet.
Contents
1 Introduction 1
1.1 Previous work . . . 1
2 Background 2 2.1 Volume rendering & ray casting . . . 2
2.2 BCC & FCC grids . . . 3
2.3 Voreen . . . 4
3 Method & Implementation 5 3.1 Alternate volume storage format for Box-splines . . . 8
3.2 Cosine weighted B-spline interpolation (CWB) . . . 9
3.3 Multivariate Sinc Function reconstruction . . . 10
3.3.1 Method . . . 11
3.3.2 Implementation . . . 14
3.4 Test data . . . 15
3.5 Measuring frame rate . . . 17
3.6 Measuring rendering quality . . . 18
4 Results 18 4.1 Frame rate comparison . . . 18
4.2 Rendering quality comparison . . . 21
4.2.1 Multivariate Sinc Function reconstruction . . . 23
5 Discussion 23 5.1 Frame rate . . . 23
5.2 Rendering quality . . . 25
5.2.1 Multivariate Sinc Function reconstruction . . . 25
5.3 Known issues . . . 26
5.4 Future work . . . 26
6 Conclusions 27 7 Appendices 29 7.1 CWB interpolation shader implementation . . . 29
7.2 Multivariate Sinc Function reconstruction shader implemen- tation . . . 30
1 Introduction
Measuring reality by sampling can be done in many ways. It is common in, for example, medicine to store the data samples in a 3D grid. Volume rendering is the process of creating digital 2D images from data stored in such a grid for the purpose of being viewed on a monitor.
One common way of doing this, and the one used in this thesis, is ray casting[1]. The output image is made up of a lot of small elements, pix- els, and for each such pixel a ray is cast through the volume taking samples along the way and sets the color of the pixel according to the values of the samples found. The most common way of storing the data measurements, and perhaps the most natural, is to store them as voxels in a Cartesian grid.
This system of packing is called Cartesian cubic packing (hereafter CC), and is simple to work with and handle because it is easy to reduce dimensionality as the axes are linearly independent. However, the CC grid is not optimal.
It has been shown that both the body-centered cubic grid (hereafter BCC) and the face-centered cubic grid (FCC) are more efficient with regards to the number of voxels, volume elements, needed to represent a given data set[2].
These systems can be seen as variants of a hexagonal grid or a honeycomb pattern, except extended to 3D.
Research is being done on the BCC and FCC grids but software for visualiz- ing the data in an interactive fashion is not readily available. In this project, methods for rendering images that visualize the data stored in the CC, BCC and FCC grids are examined and implemented.
This project has three aims. First, to implement new methods capable of achieving interactive frame rates. Second, to implement a method producing images that can be compared fairly in terms of grid-type dependant aliasing.
And third, to improve one of the existing methods by implementing a new volume storage format.
1.1 Previous work
This project is a continuation of a previous master thesis project[3]. The aim of that project was to implement various interpolation techniques for the BCC and FCC grids, using ray casting (see Section 2.1) to render im-
ages of volume data using the software voreen[4]. In this project we aim to expand the functionality of the rendering software with different techniques for rendering images of data sampled on BCC and FCC grids and also to improve some of the already implemented methods.
2 Background
2.1 Volume rendering & ray casting
In order to render data it must first be stored. A natural way of doing this is using a CC grid. The voxels in an equidistant CC grid are shaped like cubes. One can think of such a grid as a stack of cubic boxes, as illustrated in Figure 2.1.
Figure 2.1: A cubic CC grid and a single voxel from that grid.
When ray casting, for each pixel in the image, a ray is cast through the volume in question and samples are taken along the ray. These samples are then used to determine the color value of the pixel. When the values for every pixel have been determined, the image is finished. In order to cast a ray, a starting point and ray direction are required. One way of finding these
vectors is to create images of the front and back faces of the bounding box of the data set and map the color values to the volume texture coordinates.
These color vectors are then subtracted to obtain a ray direction vector which is then used as the step-direction when stepping through the volume.
The final value of the pixel is determined by how the samples are selected and composed, a process called compositing. One common compositing method is maximum intensity projection (MIP), which extracts the largest intensity value found along the ray. Another method of settings the pixel values is using a transfer function, which is called Direct Volume Rendering (DVR).
The transfer function is the function describing which color and opacity cer- tain values of the data set should have in the rendered image.
As they are suited for the task, volume rendering is usually performed using GPUs. Shaders are small, parallel programs that run on the GPU and ray casting is often performed using them.
In this thesis, volume grids other than the Cartesian one are studied, of which it is not as straightforward to render images in a quick fashion because cur- rent graphics hardware is not optimized to handle such grids. For example, performing a nearest neighbour texture lookup on a CC grid is simple as all that has to be done is rounding the volume coordinates to the nearest integer value. In the case of BCC or FCC this is not possible because of the more complicated grid structure.
2.2 BCC & FCC grids
Packing spheres as densely as possible in space is a very old problem. For example, on early warships it was important to stack cannonballs as densely as possible in order to save space. The solution to this problem is a FCC grid, which is the densest pattern for non-overlapping spheres in 3D[2].
It has been proven that these grids are more efficient given a set number of sample points. For example, the BCC grid can capture about 30% more in- formation compared to a CC grid using the same number of sample points[2].
One way of representing a BCC grid is as two interleaved CC grids, one of them moved slightly. If the distance between two adjacent points in one grid
is h then the offset between the two CC grids is (h/2, h/2, h/2). This pro- duces a grid with the points aligned similarly to a checker board, except in three dimensions. Like the BCC grid, the FCC grid can also be expressed as several interleaved CC grids slightly offset to one another. If the first grid has a point in (0, 0, 0) with grid spacing h then the other grids will be offset by (0, h/2, h/2), (h/2, 0, h/2) and (h/2, h/2, 0).
The unit cell, is the smallest repeating structure in a volume grid and is useful for displaying the layout of different points in the grids, as illustrated in Figure 2.2. The length a is the smallest distance between two points in the same sub-grid.
Figure 2.2: Unit cells of the CC, BCC and FCC grids.1
The voronoi region of a grid point is defined as all points in continuous space closer to that grid point than to any other, which means it represents the shape of each voxel in the grid. In the case of a CC grid this region is a cube. However, in the case of the BCC and FCC grids the region becomes more complicated, a truncated octahedron and a rhombic dodecahedron re- spectively, as seen in figure 2.3.
2.3 Voreen
Voreen is an open source volume rendering engine that uses ray casting. The rendering processors in voreen use a graphical interface with different mod- ules, called processors, performing tasks while connected to each other in a network, as shown in figure 2.4.
1Image: Copyright Baszoetekouw. http://en.wikipedia.org/wiki/User:Baszoetekouw
Figure 2.3: Voronoi regions of points in BCC and FCC grids.2
In this particular network a volumesource unit reads the volume data from a file. The two modules on the right calculate the ray entry and exit point coordinates used for ray casting. This information is then sent to a ray cast- ing processor, which executes the ray casting with a shader program. Voreen allows writing your own shader programs. In this thesis, the different in- terpolation methods selected are implemented using a shader program that performs ray casting for each pixel. When the ray casting is done, the re- sulting image is drawn onto a window, called a canvas, showing the results.
Voreen has support for several compositing techniques, among which are the previously mentioned MIP and DVR techniques.
3 Method & Implementation
The first part of this project is to study different interpolation methods, com- pare them, and finally select some of them based on their different strengths and weaknesses. Since we are in this part of the project aiming at imple- menting algorithms that can achieve interactive frame-rates, they have to be efficient and ”fast enough” on current graphics hardware. Because of this the algorithms have to be parallel in a way that is implementable on the
2Image: GNU Free Documentation License. http://en.wikipedia.org/wiki/User:Cyp
Figure 2.4: Example of a ray casting network in voreen.
graphics hardware via shaders. Another important aspect is image quality.
If the method does not accurately visualize the data then it is not of much use.
When rendering images, aliasing is artefacts in the image created when sam- pling. Here, we consider two types of aliasing, pre- and post-aliasing. Pre- aliasing is the result of the sampling grid used. If a data set is sampled on CC, BCC and FCC grids the samples taken differ, which in turn causes pre-aliasing. Post-aliasing is artefacts created when using stored samples to render an image and differs from method to method. Most methods intro-
duce post-aliasing and this affects the image quality with respect to how much it resembles the data.
In order to know how efficient the sampling grids are, it is important to be able to compare the sampled volumes without bias as quality is dependant on how the data is aligned. It is difficult to compare renderings from the different grids without bias because the interpolation method chosen greatly affects the extent of post-aliasing effects. Some methods can be used with all grids studied in this thesis, but the extent of pre-aliasing varies depending on the choice of grid. One solution to this problem proposed in [5] is to use generalized sinc filtering[6]. One of the aims of this thesis is to write a GPU implementation of this method. The method is extremely slow, however, the aim of it is not to render images in real-time, but to create renderings without post-aliasing so that the pre-aliasing of the sampling grids used can be compared.
The third aim of this thesis is to examine a different volume storage solution and implement it in one of the existing methods in order to increase perfor- mance.
The previous work used version 3.0 of voreen, which was released in March 2012. Since then there has been a split in development and a new version 4.0 has been released. However, this version has changed many things and this has made it difficult to port the ray casting module to the new version.
Instead, we chose to upgrade to the newest 3.x version (Version 3.0.1). The upgrade include various bug fixes and performance improvements. The ex- tension module from the previous project is mostly compatible with the new version and only changes to the same files as before are needed in order for the module to work. The volume interleave processor that had been added to the base collection of Voreen in the previous project is moved to the exten- sion module since it was created for use with the BCC and FCC ray casting processors.
Compared to the CC grid, the data density of BCC and FCC grids is higher.
This means that the step length when ray casting has to be adjusted, other- wise, points can be skipped during sampling. This is discussed in [3] and is implemented similarly in this project.
3.1 Alternate volume storage format for Box-splines
In order for Voreen to load volume data it needs two files. Firstly, the raw data file, and secondly a text file containing meta-data describing how Voreen should read the data file. These file types have the extensions .raw and .dat respectively. Once data has been read into Voreen using volumesource pro- cessors it can be used by the various other processors. To perform ray casting the volume data has to be sent to the GPU, which is done using a texture sampler. This texture sampler usually has four channels: red, green and blue color channels (RGB), and an opacity channel (A, or alpha). The BCC and FCC ray casting processors implemented in the previous project[3] support two different volume reading methods. Both methods use the fact that BCC and FCC volume grids can be represented by two and four CC grids respec- tively. The first one reads each grid from a different file and links them to the ray casting processor separately. This method allows pre-calculation of the volume gradients that are used when shading the rendered volume. This pre-calculation is done with the volumegradient processor and the gradients are then interleaved with the intensity such that the gradients are stored in the RGB channels of the texture and the intensity of the volume fragment is stored in the alpha channel. The second method uses a single volume file con- taining data from all the required CC grids (two for BCC and four for FCC).
These grids, when read by Voreen, are stored in a volume texture in the RG channels in the case of BCC and RGBA channels in the case of FCC. This means that there is no room for the pre calculated volume gradients. Because of that, this method does not support shading using pre-calculated gradients.
Two of the most costly things to do on the GPU are texture lookups and branching. The implementation of Linear Box-Spline reconstruction for BCC grids in [3] uses, for simplicity’s sake or lack of time, the same storage method used in the DC-spline reconstruction method, while in [7] a different stor- age method is used for efficiency reasons. From here on I will call the lat- ter method Z-interleave for reasons soon apparent. Implementing the Z- interleaved storage method is mentioned in [3] as a possible point for future work. The methods implemented in [3] require four texture lookups after a branch, which probably means that the GPU performs eight texture lookups, since usually both sides of a branch are executed and the correct value is cho- sen at the end. Z-interleave reduces the number of texture lookups to four while only adding a few low cost index operations. The idea of Z-interlave is
to take the two CC grids representing the BCC volume and storing them in a single volumetexture such that the data along the x and y axes is stored the same as before, but along the z axis the data is stored in pairs contain- ing data from the two different CC grids. The difference of the two storage methods is illustrated in Figure 3.1. This means that the data can be sent to the shader using one texture sampler and the volume elements of the two grids can be accessed using only odd or only even z-indices respectively.
Figure 3.1: 2D Comparison between two separate CC grids and the Z-interleaved storage format for BCC grids.
Although the main application of this storage format is to speed up Box- spline reconstruction it can also be used with nearest neighbour reconstruc- tion. Thus, the Z-interleaved format is implemented into the existing BCC ray casting processor for use with the Box-spline as well as the nearest neigh- bour reconstruction methods using an extra option in the ray casting pro- cessor settings.
3.2 Cosine weighted B-spline interpolation (CWB)
This method, as proposed by Cs´ebfalvi in [8], uses two trilinear texture sam- ples from a BCC grid and linearly interpolates between them. That is, if
the point is exactly a grid point of one of the grids, it receives exactly that value, otherwise it receives a value somewhere between the two values. The linear interpolation is calculated using a weighting function as defined in equation (1). The value of the weighting function is 0 if the point x is ex- actly on the first CC grid and 1 if the point is exactly on the second CC grid that the BCC grid is comprised of. This method is chosen because it seems to be very efficient and also easy to implement into the existing code. The higher order methods described in [8] are not considered because they are not fast enough to achieve interactive frame-rates.
Wλ(x) = 1
2+ λcos(2πx1) + cos(2πx2) + cos(2πx3)
6 (1)
If the parameter λ is close to 0 the linear interpolation results in a value close to the middle point between the two grids. If it is 1 the method works as described above. It is shown in [8] that the ammount of oversmoothing and post-alisasing effects decrease with the value of λ. However, it is shown that not much is changed when λ takes values below 0.01. For this reason, the lower bound for λ is set to 0.01 in the implementation.
The resulting intensity value of the point is given by value = (1 − Wλ)sample1 + Wλsample0
where sample1 and sample0 are trilinearly interpolated samples from the two BCC volumes.
This method is added to the existing BCC ray casting processor as an extra option in the processor properties.
3.3 Multivariate Sinc Function reconstruction
To be able to compare the amount of pre-aliasing introduced when sampling on the CC, BCC and FCC grids a reconstruction method that minimizes post-aliasing is required. In [5], comparisons of the Marschner-Lobb signal were made. To make these comparisons as unbiased as possible they use reconstruction filters as described in [6] and then rotate the signal such that the worst case scenario in terms of pre-aliasing is achieved. The method used
introduces low post-aliasing and the resulting images contain almost only pre- aliasing. One of the aims of this thesis is to implement the reconstruction method described in [6] to enable fair comparisons.
3.3.1 Method
The signal is reconstructed as fr(x) = X
k∈Zd
f (Lk)sincw(x − Lk). (2)
Here, the stored volume data is given by f (Lk) where L is the sampling matrix of the volume grid and the reconstructed signal in a point is given as a sum of all points windowed by a sinc function. The 1D sinc function is defined as
sinc(x) = sin(πx) πx .
One notable property of this sinc function is that it is 0 at every integer except at 0, where it is 1. This sinc function is then windowed by another sinc function and a step function and we get
sincw(x) = sinc(x)sinc(x/a), x/a ∈ S{sinc(x/a)}
0, otherwise
where S{sinc(x/a)} is the support of the main lobe of sinc(x/a). The 1D windowed sinc function is illustrated in Figure 3.2.
The variable a determines the number of non-zero points in the sum in (2) since the width of the support of the main lobe of the sinc function increases with it. The amount of post-aliasing decreases when a increases because more and more points are used when calculating the sum. In the case of the CC-grid, if the required value is exactly at a sample point all other values except the middle one is weighted 0 and the middle one is weighted 1 by the window function. In the case of BCC and FCC the sinc function becomes more complicated since the property that the window function is 0 in every grid point except the middle is not preserved when the grid is changed. The full derivation can be found in [6]. The sinc function for the BCC and FCC grids is
Figure 3.2: The 1D sinc function for a = 5. Blue is sinc(x), Red is sinc(x/a) and black is sinc(x)sinc(x/a)
sincL(x) = |detL| X
B∈B(ΞL)
|detB|cos(2πhτB− cΞL, xi)Y
ξ∈B
sinchξ, xi. (3)
Here, L is the generator matrix of the grid in question and ΞLis a matrix de- fined by the type of grid used. The generator matrices, i.e., the matrices that can generate the points of the BCC and FCC grids using linear combinations, are defined as
LB =
−1 1 1
1 −1 1
1 1 −1
, LF =
0 1 1 1 0 1 1 1 0
when using the BCC and FCC grids respectively. Similarly, the Ξ matrices
B(ΞB) Columns δB
B1 1 2 3 0 0 0 0
B2 1 2 4 0 0 0 0
B3 1 3 4 0 0 0 0
B4 2 3 4 0 0 0 0
Table 3.1: Bases and δ values for the BCC grid.
are defined as
ΞB = [ξ1...ξ4] = 1 4
1 −1 −1 1
−1 1 −1 1
−1 −1 1 1
ΞF = [ξ1...ξ6] = 1 4
1 −1 1 1 0 0
1 1 0 0 1 −1
0 0 1 −1 1 1
.
The bases B are made out of the columns of ΞB and ΞF and they differ between the two grid types. Tables defining how to combine them for BCC can be found in Table 3.1 and in Table 3.2 for FCC. The contribution of each basis is then multiplied by three sinc functions, each using one of the three different column vectors that the base is comprised of and these contributions are finally added up in the sum. The variable τB is defined as the sum of cB and αB which are defined as
cB = 1 2
X
ξ∈B
ξ (4)
and
αB = ΞδB. (5)
In (4) the vectors ξ that the base B is made out of are summed. In (5), the value of δB is dependant on the type of grid used. The value of cΞL in (3) is calculated the same as in (4) except that in this case the sum is over all of the columns in Ξ instead of just the ones belonging to the basis in question.
B(ΞF) Columns δF
B1 1 2 4 0 0 1 0 1 1
B2 1 5 6 0 0 1 1 0 0
B3 3 4 5 0 0 0 0 0 1
B4 2 3 4 0 0 0 0 1 1
B5 1 2 6 0 0 1 1 1 0
B6 3 5 6 0 0 0 1 0 0
B7 1 3 5 0 0 0 1 0 0
B8 1 4 6 0 1 1 0 1 0
B9 2 4 5 0 0 0 0 0 1
B10 1 2 3 0 0 0 0 0 1
B11 1 2 5 0 0 0 1 0 0
B12 4 5 6 0 1 0 0 0 0
B13 3 4 6 0 1 0 0 1 0
B14 2 5 6 0 0 0 1 0 0
B15 1 3 4 0 1 0 0 1 0
B16 2 3 6 0 0 0 1 1 0
Table 3.2: Bases and δ values for the FCC grid.
3.3.2 Implementation
This reconstruction method requires, for each sample, a sum of all points, each weighted using a window function centred around the middle point as described in (2). However, looping over all points in the volume several times for each pixel is not computationally feasible. Instead, a sampling kernel containing the closest points is used. The kernel size is dependant on the parameter a, as it determines the area where the window function is non-zero. The sampling kernel is set to be a cube with side length 1 + 2a which means that the number of points sampled is (1 + 2a)3. Because of this kernel structure, some points along the corner of the volume will have sam- ples missing because the kernel is partly outside the volume and this results in some artefacts along the edge.
In the case of BCC and FCC, the sum in (2) is calculated using the same kernel as above, except it is done for each CC sub-grid separately. That is samples are taken and windowed separately for each grid and then added to the sum. To ensure that all non-zero points in the sum are included, the size
of the kernel is increased to include an extra layer of points along the edge, which means that one extra sample on each side for each axis is used.
Calculating the window function used in (2) is much more complicated than the one used for CC grids, and because of that, the calculations are opti- mized as much as possible in the shader. For example, many constants are combined. Also, when using the BCC grid, cΞL becomes 0 and τB becomes something similar to the current base matrix B. This allows for some sim- plifications in the implementation, as instead of using a pre-calculated τ , the already stored values of ξ can be used. The shader implementation of these functions can be found in the appendix (section 7.2).
As this method is not meant to achieve interactive frame rates it is imple- mented using a separate ray casting processor called UnbiasedVolumeRay- caster. The functionality of this processor is similar to the other ones except this one only renders the image when a button is pressed. It is deemed necessary to add this feature to prevent unintended renderings, as a single rendering may take several minutes to compute. It supports CC, BCC and FCC volumes using four in-ports and lets the user choose the type of grid used.
3.4 Test data
Volume data for the BCC and FCC grids are not readily available, and be- cause of that, the volume data generation tool written for the previous thesis, called mkvol, is used here as well [3]. It can generate CC, BCC and FCC volume data from several different functions, including the Marschner-Lobb test function and a spherical Guassian signal, on a format that can be read by Voreen. CC and BCC data sets of the Shepp-Logan signal are also created[9]
in order to test the performance on asymmetric data sets.
In Figure 3.3 and 3.4, renderings of the Marschner-Lobb and Shepp-Logan data sets can be seen. The transfer functions used when rendering these images can be seen in Figure 3.5.
Figure 3.3: Rendering of a Marschner-Lobb BCC data set using CWB reconstruc- tion and Phong shading.
Figure 3.4: Rendering of a Shepp-Logan BCC data set using CWB reconstruction and Phong shading.
Figure 3.5: The transfer functions used when rendering the Masrchner-Lobb (above) and Shepp-Logan (below) data sets as seen in Voreen.
3.5 Measuring frame rate
In order to measure the performance of different methods, a benchmark that can be used on all of them must be established. In this thesis, the tests were done using a python script that is included in Voreen. It measures the time taken to render a set number of frames while rotating the volume 360◦ around an axis and calculates the average frame rate. A sampling rate of 2.0 (Voreen parameter) along the ray is used when performing these tests.
Data sets generated from the Marschner-Lobb test signal sampled in a cubic volume created by the mkvol tool, is used as test data. The largest number of grid points of a volume used in testing is around two million. In a BCC grid this corresponds to a cube with dimensions 100x100x100, which is exactly two million points because of the two grid structure. The closest similarly sized cube volume for a CC grid is one with a side of 126 points.
The Shepp-Logan data set consists of a half outer shell and several inner ellipsoids that represent parts of a brain. This data set is varied between 0.16 and 16 million voxels, which corresponds to a 201x201x201 BCC volume.
3.6 Measuring rendering quality
Measuring rendering quality can be difficult because as long as the resulting image looks good it can be considered good enough in some sense. While most methods implemented here produce images that look good, something more quantifiable is required. In [5] both visual comparisons using data sets with small details and error analysis using a reference image are used. In this project the latter will be used to compare the image quality.
The same method used in the previous project is used here as well. A high- resolution CC volume (100 million voxels) of a spherical gaussian function is used as a reference and is compared to renderings of smaller resolution volumes of the same signal using the different methods. A difference image is calculated from the reference image and the output image. The data set is rotated over 10 frames during the test, but since the data set is symmetrical, instead of a full revolution the data set is only rotated 90◦. Using the differ- ence images the mean, max and root-mean square (RMS) error is calculated.
To ensure better quality, a higher sample rate of 4.0 is used when performing these tests. The transfer function used in these tests can be seen in Figure 3.6.
Figure 3.6: The transfer functions used in the rendering quality tests.
During the project a bug in the volume generation tool mkvol when gener- ating FCC data was found. Because of that, the image quality tests for the FCC ray caster are included here as well.
4 Results
4.1 Frame rate comparison
A comparison of the performance benefit of the z-interleaved volume format is illustrated in Figure 4.1.
A performance comparison of the methods implemented in this project com- pared to the methods from the previous project on the Marschner-Lobb data set can be seen in Figure 4.2. When using CWB reconstruction, changes in the value of λ did not influence the average frame rate in any noteworthy way and because of this a set value of λ is used.
A similar performance comparison of the Shepp-Logan data set can be seen in Figure 4.3.
The performance test procedure is described in section 3.5.
Figure 4.1: Performance comparison of the z-interleaved volume format versus the original format when rendering the Marschner-Lobb data set as 512x512 pixels without shading.
Figure 4.2: Comparison of the new methods (circles) versus some of the old ones on the Marschner-Lobb data set when rendering as 512x512 pixels without shading.
Figure 4.3: Comparison of the new methods (circles) versus some of the old ones when rendering the Shepp-Logan data set as 512x512 pixels without shading.
4.2 Rendering quality comparison
As described in Section 3.6 different error quantities were calculated from a series of 10 difference images taken from different angles. The results can be seen in Figures 4.4 and 4.5.
Figure 4.4: Comparison of the max error when rendering spheres without shading
Figure 4.5: Comparison of the mean and root-mean-square error when rendering spheres without shading.
4.2.1 Multivariate Sinc Function reconstruction
As this method is not meant to achieve interactive frame-rates, and is there- fore very slow, the image quality testing is not done to the same extent as for the other methods. A constant angle is used and instead of varying the data set size, the sampling kernel size is varied. The results can be seen in Figure 4.6. Some results from other methods were added as a comparison.
Large values of a for FCC are skipped as it took over 5 minutes to complete the rendering with a set to 7.
Due to the usage of a sampling kernel, there are artefacts along the edge as the kernel is partially outside the volume.
5 Discussion
5.1 Frame rate
The new volume storage format for the linear box spline and nearest neigh- bour methods results in a substantial frame rate improvement. For the Marschner-Lobb data set the linear box spline method with z-interleave is almost as fast as using Voreen’s standard ray caster on a CC grid of similar size. The CWB method achieves an even higher frame rate. This is probably due to the very simple nature of the algorithm as only two texture lookups and a few floating point operations are required per sample along the ray.
On the Shepp-Logan data set, the results are overall similar, with the ex- ception that the BCC nearest neighbour method is closer to the other BCC methods in terms of performance. I believe this has something to do with the fact that the intensity of the Marschner-Lobb function is increasing along one axis, causing the interpolating methods to render a lot of dots on the back-side of the volume. The noise like dots are not present when rendering using the BCC nearest neighbour method. This probably means that early ray termination happens much earlier on the back-side of the volume for the BCC nearest neighbour method, giving it an advantage over the other meth- ods when rendering the Marschner-Lobb signal. There is a drawback to using nearest neighbour methods however, as the rendering quality is lacking, as shown in Figure 5.1.
Figure 4.6: Mean and root-mean-square error of Multivariate Sinc Function recon- struction methods on a 1 million voxel grid
Figure 5.1: Rendering of the Marschner-Lobb BCC data set using nearest neigh- bour reconstruction and Phong shading.
5.2 Rendering quality
Overall, the rendering quality is satisfactory. The BCC methods perform similarly, which was expected as they are all first order methods. Notably, the newly implemented methods produce images of similar quality as the previous ones.
As the bug for FCC in the volume generation tool was fixed the FCC methods now perform on a similar level as the other methods. The BCC and FCC reconstruction methods all perform better than CC trilinear reconstruction for data sets smaller than 10000 voxels. However, as the number of voxels grow, the CC trilinear methods overtake the others in the mean error. This is probably due to the fact that the reference image is sampled on a CC grid.
Although this happens for the mean error, it does not happen for the root mean square error and max error.
5.2.1 Multivariate Sinc Function reconstruction
As expected, when a is small, the method performs poorly. However, as a is increased the rendering quality of this method seems to be on par with the other, fast, methods. The error does not decrease for larger a beyond a certain point. This is also noticeable when looking at renderings as they do not appear to improve in quality. The cause is probably due to the nature of the windowing function, as it decreases with the distance to the center
point. This means that the samples added to the kernel when a increases contribute less and less to the value of the sample point.
5.3 Known issues
• Sometimes when loading a new volume the image is not correctly ren- dered until the frame is rendered a second time when using the BCC and FCC ray casters and the separate volume format.
• There is a bug when loading new volumes using the z-interleaved format that sometimes causes the ray caster to render a previously loaded volume.
• The multivariate sinc function method does not work properly on Nvidia hardware and/or linux when the rendering time becomes large. The testing was done on a Windows PC using AMD graphics hardware.
A tweak to Timeout Detection and Recovery settings in the Windows registry is required for longer runs.
5.4 Future work
An image quality analysis using an analytical function calculated on-the-fly in the shading program used as reference image would make the comparison more fair. The reference image used in this project is probably biased to- wards CC trilinear reconstruction since the volume is stored in a CC grid.
In order to see the full benefit of the multivariate sinc function method test- ing on different data sets is required. It would also be interesting to perform testing using data sets rotated to the worst case scenario angle in terms of pre-aliasing as performed in [5].
6 Conclusions
There were three aims of this project. First, to implement new methods capable of interactive frame rates. Second, to implement a method capable of fairly comparing renderings of data stored on different grid types in terms of pre-aliasing. And third, to implement a new volume storage format for an existing method. All of these aims have been achieved. Some of the new methods are implemented as options in the existing ray casting processors and some are implemented as new processors. The Z-interleaved volume format and the CWB reconstruction methods prove to produce images of similar quality compared to the other methods at an improved frame-rate.
The bug fix in the volume generation tool improve the image quality for the FCC volumes and they are now reaching the expected image quality. The multivariate sinc function reconstruction method proved to be very slow, but also produces images of good quality.
In general the project is successful, but improvements can be made in order to see the full potential of the multivariate sinc function interpolation method.
Improving that method or the software in general by implementing additional methods could be a starting point for future projects.
References
[1] J. Kr¨uger and R. Westermann. Acceleration Techniques for GPU-based Volume Rendering. Proceedings of the 14th IEEE Visualization, VIS
’03, page 287, 2003.
[2] A. Entezari, Towards Computing on Non-Cartesian Lattices. IEEE Transactions on Visualization and Computer Graphics, 2006.
[3] Max Mor´en. Efficient Volume Rendering on the Face Centered and Body Centered Cubic Grids. 2012.
[4] Voreen Project. Homepage: http://www.voreen.org/
[5] Viktor Vad, Bal´azs Cs´ebfalvi, Peter Rautek and Eduard Grller. Towards an Unbiased Comparison of CC, BCC and FCC Lattices in Terms of Prealiasing. Eurographics Conference on Visualization (EuroVis), vol.
33, no. 3, 2014.
[6] Wenxing Ye and Alireza Entezari. A Geometric Construction of Mul- tivariate Sinc Functions. IEEE Transactions on Image Processing, vol.
21, no. 6, June 2012.
[7] B. Finkbeiner, A. Entezari, D. V. D. Ville and T. Mller. Efficient volume rendering on the body centered cubic lattice using box splines. Comput- ers & Graphics, 34(4):409–423, 2010.
[8] Bal´azs Cs´ebfalvi. Cosine-Weighted B-Spline Interpolation: A Fast and High-Quality Reconstruction Scheme for the Body-Centered Cubic Lat- tice. IEEE Transactions on Visualization and Computer Graphics, vol.
19, no. 9, September 2013.
[9] Leo Svenningsson. Fourier transform of BCC and BCC lattices for MRI applications. 2015.
7 Appendices
7.1 CWB interpolation shader implementation
v e c 4 r e c o n s t r u c t C W B ( in v e c 3 p ) {
c o n s t v e c 3 s i z e = v o l u m e S t r u c t 1 _ . d a t a s e t D i m e n s i o n s _ ; c o n s t f l o a t pi2 = 6 . 2 8 3 1 8 5 3 ;
v e c 3 pw = p * s i z e ; // t e x t u r e l o o k u p s
S A M P L E s a m p l e 0 = T E X 0 ( pw ) ; S A M P L E s a m p l e 1 = T E X 1 ( pw ) ; // c a l c u l a t e w e i g h t i n g f u n c t i o n v e c 3 p0 = pw - 0 . 5 ;
v e c 3 c = cos ( p0 * pi2 ) ;
f l o a t w = 0.5 + ( c . x + c . y + c . z ) / 6.0 * l a m b d a _ ; // l i n e a r i n t e r p o l a t i o n
S A M P L E v a l u e = mix ( sample1 , sample0 , w ) ;
# i f n d e f V O L U M E _ F O R M A T _ I N T E R L E A V E D
v a l u e . rgb = ( v a l u e . rgb - v e c 3 ( 0 . 5 ) ) * 2 . 0 ; r e t u r n v a l u e ;
# e l s e
r e t u r n v e c 4 (0.0 , 0.0 , 0.0 , v a l u e ) ;
# e n d i f }
7.2 Multivariate Sinc Function reconstruction shader implementation
# i n c l u d e " m o d u l e s / v r n _ s h a d e r i n c l u d e s . f r a g "
# d e f i n e T E X 0 ( p ) t e x t u r e ( v o l u m e S t r u c t 1 _ . volume_ , ( p - g 0 _ o f f )
* o n e O v e r V o x e l s ) . a
# d e f i n e T E X 1 ( p ) t e x t u r e ( v o l u m e S t r u c t 2 _ . volume_ , ( p - g 0 _ o f f )
* o n e O v e r V o x e l s ) . a
# d e f i n e T E X 2 ( p ) t e x t u r e ( v o l u m e S t r u c t 3 _ . volume_ , ( p - g 0 _ o f f )
* o n e O v e r V o x e l s ) . a
# d e f i n e T E X 3 ( p ) t e x t u r e ( v o l u m e S t r u c t 4 _ . volume_ , ( p - g 0 _ o f f )
* o n e O v e r V o x e l s ) . a
c o n s t v e c 3 g 0 _ o f f = v e c 3 (0.0 , 0.0 , 0 . 0 ) ;
# i f d e f R E C O N S T R U C T _ B C C
c o n s t v e c 3 g 1 _ o f f = v e c 3 (0.5 , 0.5 , 0 . 5 ) ;
# e n d i f
# i f d e f R E C O N S T R U C T _ F C C
c o n s t v e c 3 g 1 _ o f f = v e c 3 (0.0 , 0.5 , 0 . 5 ) ; c o n s t v e c 3 g 2 _ o f f = v e c 3 (0.5 , 0.0 , 0 . 5 ) ; c o n s t v e c 3 g 3 _ o f f = v e c 3 (0.5 , 0.5 , 0 . 0 ) ;
# e n d i f
v e c 4 r e s u l t = v e c 4 ( 0 . 0 ) ; v e c 4 r e s u l t 1 = v e c 4 ( 0 . 0 ) ; v e c 4 r e s u l t 2 = v e c 4 ( 0 . 0 ) ;
u n i f o r m S A M P L E R 2 D _ T Y P E e n t r y P o i n t s _ ; u n i f o r m S A M P L E R 2 D _ T Y P E e n t r y P o i n t s D e p t h _ ; u n i f o r m T E X T U R E _ P A R A M E T E R S e n t r y P a r a m e t e r s _ ; u n i f o r m S A M P L E R 2 D _ T Y P E e x i t P o i n t s _ ; u n i f o r m S A M P L E R 2 D _ T Y P E e x i t P o i n t s D e p t h _ ; u n i f o r m T E X T U R E _ P A R A M E T E R S e x i t P a r a m e t e r s _ ; u n i f o r m int a_ ;
u n i f o r m int n_ ;
u n i f o r m V O L U M E _ S T R U C T v o l u m e S t r u c t 1 _ ; u n i f o r m V O L U M E _ S T R U C T v o l u m e S t r u c t 2 _ ; u n i f o r m V O L U M E _ S T R U C T v o l u m e S t r u c t 3 _ ; u n i f o r m V O L U M E _ S T R U C T v o l u m e S t r u c t 4 _ ;
# i f d e f R E C O N S T R U C T _ C C v e c 3 o n e O v e r V o x e l s =
v e c 3 ( 1 . 0 ) /( v o l u m e S t r u c t 1 _ . d a t a s e t D i m e n s i o n s _ ) ;
# e l s e
v e c 3 o n e O v e r V o x e l s =
v e c 3 ( 1 . 0 ) /( v o l u m e S t r u c t 1 _ . d a t a s e t D i m e n s i o n s _ - . 5 ) ;
# e n d i f
c o n s t f l o a t pi = 3 . 1 4 1 5 9 2 ; c o n s t f l o a t pi2 = 6 . 2 8 3 1 8 5 3 ; f l o a t a d i v i d e = 1/ f l o a t ( a_ ) ;
# i f d e f R E C O N S T R U C T _ B C C
c o n s t v e c 3 xi [4] = v e c 3 [ ] ( 0 . 5 * v e c 3 ( 1 , -1 , -1) , 0.5 * v e c 3 ( -1 , 1 , -1) , 0.5 * v e c 3 ( -1 , -1 , 1) , 0.5 * v e c 3 ( 1 , 1 , 1) ) ;
# e n d i f
# i f d e f R E C O N S T R U C T _ F C C
c o n s t v e c 3 xi [6] = v e c 3 [ ] ( 0 . 5 * v e c 3 ( 1 , 1 , 0) , 0.5 * v e c 3 ( -1 , 1 , 0) , 0.5 * v e c 3 ( 1 , 0 , 1) , 0.5 * v e c 3 ( 1 , 0 , -1) , 0.5 * v e c 3 ( 0 , 1 , 1) , 0.5 * v e c 3 ( 0 , -1 , 1) ) ; c o n s t i v e c 3 b a s e s [ 1 6 ] = i v e c 3 []( i v e c 3 (1 ,2 ,4) -1 ,
i v e c 3 (1 ,5 ,6) -1 , i v e c 3 (3 ,4 ,5) -1 , i v e c 3 (2 ,3 ,4) -1 , i v e c 3 (1 ,2 ,6) -1 , i v e c 3 (3 ,5 ,6) -1 , i v e c 3 (1 ,3 ,5) -1 , i v e c 3 (1 ,4 ,6) -1 , i v e c 3 (2 ,4 ,5) -1 , i v e c 3 (1 ,2 ,3) -1 , i v e c 3 (1 ,2 ,5) -1 , i v e c 3 (4 ,5 ,6) -1 , i v e c 3 (3 ,4 ,6) -1 , i v e c 3 (2 ,5 ,6) -1 , i v e c 3 (1 ,3 ,4) -1 , i v e c 3 (2 ,3 ,6) -1) ;
c o n s t v e c 3 t a u _ B c p i [ 1 6 ] = v e c 3 []( pi * 0 . 5 * v e c 3 ( 1 , 0 , 3) , pi * 0 . 5 * v e c 3 ( 3 , -1 , 0) , pi * 0 . 5 * v e c 3 ( 0 , -3 , 1) ,
pi * 0 . 5 * v e c 3 ( -1 , -1 , 2) , pi * 0 . 5 * v e c 3 ( 2 , 1 , 1) , pi * 0 . 5 * v e c 3 ( 1 , -2 , -1) , pi * 0 . 5 * v e c 3 ( 2 , 0 , -2) , pi * 0 . 5 * v e c 3 ( 0 , 2 , 2) , pi * 0 . 5 * v e c 3 ( -2 , -2 , 0) , pi * 0 . 5 * v e c 3 ( 1 , 2 , -1) , pi * 0 . 5 * v e c 3 ( 0 , 1 , -3) , pi * 0 . 5 * v e c 3 ( -3 , 0 , -1) , pi * 0 . 5 * v e c 3 ( -2 , 1 , 1) , pi * 0 . 5 * v e c 3 ( -1 , -1 , -2) , pi * 0 . 5 * v e c 3 ( -1 , 3 , 0) , pi * 0 . 5 * v e c 3 ( 0 , 0 , 0) ) ;
# e n d i f
v e c 3 s i n c ( v e c 3 x ) {
if ( x == v e c 3 (0) ) r e t u r n v e c 3 (1) ; r e t u r n sin ( x * pi ) /( x * pi ) ; }
f l o a t s i n c ( f l o a t x ) {
if ( x == 0) r e t u r n 1;
r e t u r n sin ( x * pi ) /( x * pi ) ; }
v e c 3 c c _ W i n d o w e d _ S i n c ( v e c 3 x ) {
if ( l e n g t h ( x ) <= f l o a t ( a_ ) )
r e t u r n s i n c ( abs ( x ) ) * pow ( abs ( s i n c ( x * a d i v i d e ) ) , v e c 3 ( n_ ) ) ;
e l s e
r e t u r n v e c 3 (0) ; }
v e c 4 r e c o n s t r u c t C C ( in v e c 3 p ) {
v e c 3 pv = p * v o l u m e S t r u c t 1 _ . d a t a s e t D i m e n s i o n s _ ; f l o a t sum = 0;
v e c 3 o f f s e t = f r a c t ( pv ) ;
v e c 3 v ;
for ( v . x = - a_ ; v . x <= a_ ; v . x ++) {
for ( v . y = - a_ ; v . y <= a_ ; v . y ++) {
for ( v . z = - a_ ; v . z <= a_ ; v . z ++) {
v e c 3 L = c c _ W i n d o w e d _ S i n c ( o f f s e t - v ) ; f l o a t s a m p l e 0 = T E X 0 ( pv + v ) ;
sum += s a m p l e 0 * L . x * L . y * L . z ; }
} }
r e t u r n v e c 4 (0 , 0 , 0 , sum ) ; }
# i f d e f R E C O N S T R U C T _ B C C f l o a t B C C _ S i n c _ L ( v e c 3 x ) {
f l o a t ret = 0;
for ( int i = 0; i < 4; i ++) {
f l o a t t e m p = 1;
for ( int j = 0; j < 4; j ++) if ( i != j )
t e m p *= s i n c ( xi [ j ]. x * x . x + xi [ j ]. y * x . y + xi [ j ]. z * x . z ) ;
ret += t e m p * cos ( pi *( xi [ i ]. x * x . x + xi [ i ]. y * x . y + xi [ i ]. z * x . z ) ) ;
}
r e t u r n ret * 0 . 2 5 ; }
f l o a t B C C _ W i n d o w e d _ S i n c _ L ( v e c 3 x ) {
if ( abs ( x . x ) < a_ ) if ( abs ( x . y ) < a_ )
if ( abs ( x . z ) < a_ )
r e t u r n B C C _ S i n c _ L ( x ) *
pow ( abs ( B C C _ S i n c _ L ( x * a d i v i d e ) ) , f l o a t ( n_ ) ) ; r e t u r n 0;
}
v e c 4 r e c o n s t r u c t B C C ( in v e c 3 p ) {
v e c 3 pv = p * v o l u m e S t r u c t 1 _ . d a t a s e t D i m e n s i o n s _ ; v e c 3 pr = f l o o r ( pv ) ;
v e c 3 o f f s e t 0 = pv - pr ;
v e c 3 o f f s e t 1 = o f f s e t 0 - g 1 _ o f f ; f l o a t s i d e = f l o a t ( a_ ) + 1;
f l o a t sum = 0;
v e c 3 v ;
for ( v . x = - s i d e ; v . x <= s i d e ; v . x ++) {
for ( v . y = - s i d e ; v . y <= s i d e ; v . y ++) {
for ( v . z = - s i d e ; v . z <= s i d e ; v . z ++) {
f l o a t w i n d o w 0 = B C C _ W i n d o w e d _ S i n c _ L ( o f f s e t 0 - v ) ;
f l o a t w i n d o w 1 = B C C _ W i n d o w e d _ S i n c _ L ( o f f s e t 1 - v ) ;
sum += w i n d o w 0 * T E X 0 ( pr + v ) ; sum += w i n d o w 1 * T E X 1 ( pr + v ) ; }
} }
r e t u r n v e c 4 (0 , 0 , 0 , sum ) ; }
# e n d i f
# i f d e f R E C O N S T R U C T _ F C C f l o a t F C C _ S i n c _ L ( v e c 3 x ) {
f l o a t ret = 0;
for ( int i = 0; i < 16; i ++)
ret += cos ( t a u _ B c p i [ i ]. x * x . x + t a u _ B c p i [ i ]. y * x . y + t a u _ B c p i [ i ]. z * x . z )
* s i n c ( xi [ b a s e s [ i ]. x ]. x * x . x +
xi [ b a s e s [ i ]. x ]. y * x . y + xi [ b a s e s [ i ]. x ]. z * x . z )
* s i n c ( xi [ b a s e s [ i ]. y ]. x * x . x +
xi [ b a s e s [ i ]. y ]. y * x . y + xi [ b a s e s [ i ]. y ]. z * x . z )
* s i n c ( xi [ b a s e s [ i ]. z ]. x * x . x +
xi [ b a s e s [ i ]. z ]. y * x . y + xi [ b a s e s [ i ]. z ]. z * x . z ) ;
r e t u r n ret * 0 . 0 6 2 5 ; }
f l o a t F C C _ W i n d o w e d _ S i n c _ L ( v e c 3 x ) {
if ( abs ( x . x ) < a_ ) if ( abs ( x . y ) < a_ )
if ( abs ( x . z ) < a_ )
r e t u r n F C C _ S i n c _ L ( x ) *
pow ( abs ( F C C _ S i n c _ L ( x * a d i v i d e ) ) , f l o a t ( n_ ) ) ; r e t u r n 0;
}
v e c 4 r e c o n s t r u c t F C C ( in v e c 3 p ) {
v e c 3 pv = p * v o l u m e S t r u c t 1 _ . d a t a s e t D i m e n s i o n s _ ; v e c 3 pr = f l o o r ( pv ) ;
v e c 3 o f f s e t 0 = pv - pr ;
v e c 3 o f f s e t 1 = o f f s e t 0 - g 1 _ o f f ; v e c 3 o f f s e t 2 = o f f s e t 0 - g 2 _ o f f ; v e c 3 o f f s e t 3 = o f f s e t 0 - g 3 _ o f f ; f l o a t s i d e = f l o a t ( a_ ) + 1;
f l o a t sum = 0;
v e c 3 v ;
for ( v . x = - s i d e ; v . x <= s i d e ; v . x ++) {
for ( v . y = - s i d e ; v . y <= s i d e ; v . y ++) {
for ( v . z = - s i d e ; v . z <= s i d e ; v . z ++) {
f l o a t w i n d o w 0 = F C C _ W i n d o w e d _ S i n c _ L ( o f f s e t 0 - v ) ;
f l o a t w i n d o w 1 = F C C _ W i n d o w e d _ S i n c _ L ( o f f s e t 1 - v ) ;
f l o a t w i n d o w 2 = F C C _ W i n d o w e d _ S i n c _ L ( o f f s e t 2 - v ) ;
f l o a t w i n d o w 3 = F C C _ W i n d o w e d _ S i n c _ L ( o f f s e t 3 - v ) ;
sum += w i n d o w 0 * T E X 0 ( pr + v ) ; sum += w i n d o w 1 * T E X 1 ( pr + v ) ; sum += w i n d o w 2 * T E X 2 ( pr + v ) ; sum += w i n d o w 3 * T E X 3 ( pr + v ) ; }
} }
r e t u r n v e c 4 (0 , 0 , 0 , sum ) ; }
# e n d i f
v o i d r a y T r a v e r s a l ( in v e c 3 first , in v e c 3 l a s t ) {
f l o a t t = 0 . 0 ; f l o a t t I n c r = 0 . 0 ; f l o a t t E n d = 1 . 0 ; v e c 3 r a y D i r e c t i o n ;
r a y S e t u p ( first , last , v o l u m e S t r u c t 1 _ . d a t a s e t D i m e n s i o n s _ , r a y D i r e c t i o n , tIncr , t E n d ) ;
# i f d e f r e c o n s t r u c t B C C
t I n c r /= 1 . 2 5 9 9 2 1 0 4 9 8 9 4 8 7 3 ;
# e n d i f
# i f d e f r e c o n s t r u c t F C C
t I n c r /= 1 . 5 8 7 4 0 1 0 5 1 9 6 8 2 0 0 ;
# e n d i f
R C _ B E G I N _ L O O P {
v e c 3 s a m p l e P o s = f i r s t + t * r a y D i r e c t i o n ;
v e c 4 v o x e l = R C _ A P P L Y _ R E C O N S T R U C T I O N ( s a m p l e P o s ) ; v e c 4 c o l o r = R C _ A P P L Y _ C L A S S I F I C A T I O N ( t r a n s f e r F u n c _ , v o x e l ) ;
c o l o r . rgb = R C _ A P P L Y _ S H A D I N G ( v o x e l . xyz , s a m p l e P o s , v o l u m e S t r u c t 1 _ , c o l o r . rgb , c o l o r . rgb , v e c 3 ( 1 . 0 , 1 . 0 , 1 . 0 ) ) ;
if ( c o l o r . a > 0 . 0 ) { R C _ B E G I N _ C O M P O S I T I N G
r e s u l t = R C _ A P P L Y _ C O M P O S I T I N G ( result , color , s a m p l e P o s , v o x e l . xyz , t , t D e p t h )
r e s u l t 1 = R C _ A P P L Y _ C O M P O S I T I N G _ 1 ( result1 , color , s a m p l e P o s , v o x e l . xyz , t , t D e p t h )
r e s u l t 2 = R C _ A P P L Y _ C O M P O S I T I N G _ 2 ( result2 , color , s a m p l e P o s , v o x e l . xyz , t , t D e p t h )
R C _ E N D _ C O M P O S I T I N G }
} R C _ E N D _ L O O P ( r e s u l t ) ;
}
v o i d m a i n () {
v e c 3 f r o n t P o s = t e x t u r e L o o k u p 2 D ( e n t r y P o i n t s _ , e n t r y P a r a m e t e r s _ , g l _ F r a g C o o r d . xy ) . rgb ;
v e c 3 b a c k P o s = t e x t u r e L o o k u p 2 D ( e x i t P o i n t s _ , e x i t P a r a m e t e r s _ , g l _ F r a g C o o r d . xy ) . rgb ;
if ( f r o n t P o s == b a c k P o s ) d i s c a r d ;
e l s e
r a y T r a v e r s a l ( f r o n t P o s , b a c k P o s ) ;
# i f d e f OP0
F r a g D a t a 0 = r e s u l t ;
# e n d i f
# i f d e f OP1
F r a g D a t a 1 = r e s u l t 1 ;
# e n d i f
# i f d e f OP2
F r a g D a t a 2 = r e s u l t 2 ;
# e n d i f }
