Through direct volume rendering ,see Wilhelms and Van Gelder, it is possibility to visualize a 3D dataset in a single image. Processing such images can be very compute intensive and without support from texture hardware, good high quality renderings are far from interactive. Techniques available are ray-casting, splatting, shear/warp projection and texture mapping based. See vrviz. Projection approaches to texture mapping based methods process the volume region by region as opposed to ray-casting or ray-tracing methods where it is processed ray by ray. Texture based methods use coherence to provide greater speed than ray casting and generate the image in a layered way. It is a great advantage that rendering fits into texture hardware and so offering very efficient renderings, see Cabral et al. 1994. Presently, dedicated hardware for accelerating ray-casting or ray tracing processes are not commercially available.
As we have seen in the previous chapter, a main approach for visualizing 3D scalar fields are through extraction of isosurfaces. While producing isosurfaces, a decision has to be made to which quantity of the field we want to construct the isosurface. For that particular quantity say s_0, the isosurface is constructed and rendered, a tedious process for large datasets. The resulting isosurface is a single valued "slice" of the data, that is topologically a 2D geometric object, embedded in 3D space. Information outside the 2D object is not shown. To reveal another (in most cases tiny) fraction of that information, another scalar value say s_1 has to be selected, giving another isosurface. By making the isosurfaces transparent, a few of them can be rendered in the same scene, giving valuable information, but if they become is too close and the number of them too large, it is difficult to extract useful information from them. In practice, only a small fraction of the total information of the volume can be presented in one scene. Direct volume rendering can use transparency to render a far larger fraction of the volume in a single scene at the same time, compared to use of isosurfaces. In the figure below is shown a volumetric and an isosurface rendering of the same data for comparison. The isosurface rendering depends on a light model, the texture based direct rendering is not.
|
|
The render algorithm used by the render Viz (a render developed at FFI) is very simple. It is not dependent on 3D texture hardware but works on 2D texture hardware. The difference between 2D and 3D texture hardware is essentially that for the 2D texture hardware the textures are data addressed by only two indexes (i,j). 3D texture hardware can be addressed by three indexes (i,j,k). It is possible to do volume rendering using 2D textures, but imagine a cubic voxel data set, to be rendered it has to be sliced into a three sets of parallel quad planes, each set normal to each of the cube axis. The number of quad planes can be smaller or equal to the number of data points in each direction. Since the address space has only two indexes, one has to keep track of each quad plane (they are stored in different locations of texture memory) and stack them correctly when rendered back to front. Another drawback is that a separate set of quad planes is needed for each principal axis of the cube which imply that three times as much texture memory is used compared to 3D texture hardware. Conveniences like tri-linear interpolation does not exist for 2D texture hardware. Starting with a L x M x N sized voxel set, and a color table containing "hue,saturation,value,alpha" entry for each of the data values associated with the voxel set. A "world" coordinate system is defined so that the voxels near the lower left corners becomes (0,0,0), and the voxel farthest away at the opposite diagonal has coordinates (L,M,N). Before rendering, it is necessary to set viewing angle by deriving the "major" axis. The major axis is the coordinate axis which direction is closest to the screen normal. The voxel data set is then rendered in 3D using a set of quadrilaterals (quads) shown in the figure below. In general the quads are derived from the interpolated value at the intersection of the voxel set with a set of planes perpendicular to the major axis of the cube. The quads are rendered back to front. The number of quads need not be the same as the number of voxel-planes in that particular direction. The number of quads can be larger (over sampling) or smaller (sub sampling) than the number of voxels in the actual direction.
If the number of quads and the number of voxels are the same, the quads are centered within each voxel. Then there are two possibilities, the quads can be colored according to the closest voxel, or a tri-linear interpolated value could be used. If the number of quads is larger than the number of voxels and tri-linear interpolation is used, a "smoother" rendering is obtained compared to the one plane per voxel/nearest neighbor value, see the figures below. Tri-linear interpolation is a functionality that comes with 3D texture hardware. This functionality is not available for 2D textures.
|
Viz utilizes quads oriented perpendicular to the coordinate axis and display the quads-textures that has the normal closest to the screen normal. This can be done with 2D texture hardware, but the presence of 3D texture hardware is advantageous as mentioned above. The set of quads are changed as the volume is rotated. The set of quads which has its normal closest to the screen normal is selected and rendered. This is shown in the figure below.
|
As mentioned above the number of "sample planes" can be increased to give a smoother rendering. This is shown in the figure below. The figures marked U is not interpolated, the figures marked I are interpolated, the number of quad planes per voxel is 1 or 8.
|
A texture based render should:
|
|
The the texture based voxel render algorithm consists of the following steps: Building a texture image from the data. Selecting texture mapping function (closest voxel or tri-linear interpolation). Binding the texture data to the current graphics context which can be planes or more general, polygons slicing the cube. A data value (in 3D texture memory) can be interpolated to a point at the closest polygon surface. A color and opacity is assigned to that point, contributing to a final image when rendered back to front. Usually the polygons are quads as utilized by the volume visualization software Viz developed at FFI.
When it comes to data visualization, there are some basic differences compared to visual simulation or virtual reality. A goal in data visualization is to give a computer graphics representation of your data which communicate to you the consequence of your data as uniquely an clear as possible. In scene simulations, it might be a goal to build up a virtual scene that is as close to reality as possible. In this case the "radiation field" is not a local quantity, and what appears finally on the computer screen can be a result of for example multiple scatterings of light. In data visualization we want the final image to represent as uniquely as possible the consequence of your data, then scattering of light should be neglected. Also redistribution of energy between various colors along a particular ray should not occur. All these simplifications make the radiation model quite simple to handle, and it is quite easy to show that a continuous model can be discretized into the same form as applied to light passing through multiple transparent planes as we have discussed in an earlier section, the results are very well suited to express what happens in volume visualization using texture based rendering.
|
We will below apply the equations of radiative transfer for a plane parallel slab, and show how to derive expressions used by Wilhelms and Van Gelder or in the book by Shroeder, Martin and Lorensen.
Let us now consider what is going on along a particular ray of light: Light can be emitted or absorbed along that ray, but as scattering processes are neglected, there is no influence from light propagating in other directions. Also there is no redistribution of energy among colors. Consider a plane parallel slab and a particular ray forming a specific angle between the slab-normal and the ray as in the figure below.
|
|
A general solution of the radiative transfer equation is obtained by using optical depth as a free variable instead of physical depth.
|
This equation is an ordinary linear differential equation that can be solved by writing I=uv, then we get
|
|
|
Exercise: Go through all steps in the solution of the radiative transfer equation.
Comments to scattering. In deriving the general solution above, scattering is implicitly included. In general, emission and scattering contribute to the source function since these processes add energy to the ray. In the same way, absorption and scattering can remove energy from the ray and contribute to the extinction. Although scattering is not wanted in data-visualization, as a curiosity we write the scattering term in the general form:
|
A closer look show that this expression is very close in form to the radiosity expression discussed by Foley et al, or in Basic Computer Graphics I. The scattering term will be ignored in the further treatment. The local emission term is mirroring the local data value. This term is the only one considered.
Take a closer look at the solution of the transfer equation, an approximative discrete form of the integral is a finite sum. The exponent of the optical depth can be expressed as products where the extinction coefficient enters. Compare this to the expressions derived for ray tracing of multiple colored and transparent planes as treated in Basic Computer Graphics II
|
VoluViz is another volume render developed at FFI, it is based on the API OpenGL Volumizer2 or just Volumizer2 as we will call it in this presentation. It is a software development kit developed by SGI for volume-data interpretation. Volumizer2 is a user friendly object oriented software library designed for building volume visualization applications for huge data sets. Volumizer2 is based on the utilization of 3D texture hardware and texture lookup tables. This is done to get optimal interactivity. Volume visualization and the kind of technology that Volumizer2 represents is expected to have a great potential in the future. Volumizer2 is based on top of OpenGl and can be integrated with user applications and software packages as shown in the figure below.
|
Volumizer2 has the following features
Volumizer2 offers the possibility to combine various volumes and geometries into a single scene. A node called the shape node encapsulates a volume in a manner that allows you to separate its geometry from its appearance. The volume's geometry defines its spatial attributes and a region of interest while the volume's appearance defines its visual attributes. The appearance itself consists of a list of parameters that are specific to the particular rendering technique being applied to the shape. This is shown in the figure below.
|
The shape node contains all information required to render itself. Hence, it can be treated as the leaf node of a scene graph. More complex scene graphs can be created by inserting these shape nodes to represent the volumetric components of the scene, as shown in the figure below. This allows to combine volumetric elements and geometric objects in a single scene.
|
We have previously discussed the volume render Viz and how texture hardware is used to render volumetric data given on a Cartesian mesh. Viz has no ability to render data given on non-Cartesian grids. Volumizer2 offers that ability to some degree since it can utilize tetrahedral meshes together with voxels. The data are given on a Cartesian mesh, but are rendered on surfaces built by a tetrahedral mesh. Volumizer2 utilizes general volumetric geometry classes.
Volumizer2 utilize 3D texture mapping, it utilizes a volume slicing technique which differs from Viz. It utilizes sampling planes parallel to the view-port. This is feature impossible to achieve with 2D texture hardware. It does a back-to-front rendering, using the OpenGl OVER operator. This opens for various render possibilities, like expressing the maximum encountered data value etc... How the sampling planes are used is shown in the figure below.
|
|
The technique that was described above is called volume slicing. It depends on the presence of 3D texture hardware. The data are drawn on planes which slice the voxels at slanted angles. Volume shading can in addition be implemented. It is achieved by computing gradients of the field using the texture hardware. It is our impression that the volume slicing technique is somewhat somewhat more resource demanding compared to the "quad plane" technique. Its interactivity is not as smooth as with Viz for the same data-sizes, but it has more flexibility and functionality compared to Viz. The datasets are divided into sub-datasets or bricks. If they do not fit into texture memory, the main memory is used for storage and data are "swapped" in and out of main memory. Texture memory is used as "cache".