Update Tuesday, Obtober 14: Here's a comparison image of the skull using Gordon's 2D transfer function to similar nearby isosurfaces.
![]() Isosurface at isovalue 1180 | ![]() Surface extracted using 2D transfer function. Lies between isosurfaces at 1180 and 1320. | ![]() Isosurface at isovalue 1320 |
Update Thursday, October 2: I added some more comparisons to the global illumination solution on the CFD data set. I'm using a 270 MB dataset from the center of one 8 GB timestep in the following images. On the top left is the version computed using my global illumination, using a 10e9 resolution texture, in the top center is a lambertian material with ambient component based on the normal's dot product with the up direction, on the top right is a plain lambertian material. The bottom left is a fog-based approach, which adds an OpenGL-esq fog term based on distance from the eye. The bottom middle and bottom right are the lambertian materials shown in the top row, without shadows.
![]() | ![]() | ![]() |
![]() | ![]() | ![]() |
![]() | ![]() | ![]() |
![]() | ![]() | ![]() |
![]() | ![]() | ![]() |
![]() | ![]() | ![]() |
![]() | ![]() | ![]() |
![]() | ![]() | ![]() |
Update Monday, September 15: I've been playing around with various datasets, trying to get them to load into RTRT and my global illumination code. I've got the engine block data set loaded (and should be able to get any other small datasets in Gorden's NRRD format loaded). I've looked at the 8GB/timestep CFD dataset from LLNL, but I'm still having trouble getting it loaded, due to 32-bit/64-bit issues in the code. I'll be looking at it some more, and should get some code from Dave that he used to load it into RTRT.
Here are some videos (in DivX 5 format) of this technique. Both videos were captured live on muse, using 16 CPUs at 450 x 450 resolutions. They run at about 10-16 fps.
![]() The engine block rotating around with isosurface 50. (1.7 MB) | ![]() The Visibile Female's head at varying isosurfaces. (2.0 MB) |
Here's some comparisons of the engine block using trilinear interpolation and nearest neighbor on the global illumination. These results use to different global illumination resolutions.
![]() Engine block, nearest neighbor, resolution: 10e5 | ![]() Engine block, trilinear interp, resolution: 10e5 |
![]() Engine block, nearest neighbor, resolution: 10e7 | ![]() Engine block, trilinear interp, resolution: 10e7 |
Update Wednesday, August 27: I've been trying to get rid of these ridging artifacts. I implemented a tricubic B-spline kernel to interpolate the gradient in the volume. It makes a really nice image when used for Lambertian shading, but doesn't help much when used with our global illumination technique.
![]() Lambertian shading using trilinearly computed normals. | ![]() Lambertian shading using tricubic B-spline interpolated normals. |
![]() Global Illum using trilinear normals. | ![]() Global Illum using tricubic B-spline normals. |
Note that there aren't any significant differences between the two, and even in the 900x900 images, I couldn't see a substantial difference anywhere, except for the fact that the image using trilinear normals used one additional bounce.
The next idea was to try an offset (in the gradient direction) to get out of the "ruts" and compute a smooth global illumination solution. This improves things, but also adds some artifacts, as you can see in the next set of images. However, these images do explain what the mysterious orange "glow" is (in the eyesocket near the eyebrow line) I've been seeing in all the global illumination solutions. I've had to offset in the gradient direction by some small amount already to avoid self intersections. This glow is just an artifact of that tiny offset.
![]() Global Illum using trilinear normals (same as above). | ![]() Offseting the hit position in the direction of the gradient on the order of one voxel length. |
![]() Global Illum using trilinear normals (same as above). | ![]() Offsetting the hit position except during the direct lighting computation on the initial ray intersection. |
You can see that this offset does help a little (see left forehead, the left top near the back of the skull, and the nose -- though you can't really see the nose improvement in these reduced resolution images). However, this small improvement is gained by offsetting the origianl ray intersection point (from the eye rays), not the subsequent bounces. This first bounce is also what causes the artifacts in the direct lighting computation, however. (Because the new, offset position may not be in shadow when it should).
For comparison, here's the result of offsetting the hit position in the gradient direction in a strictly lambertian rendering:
![]() Lambertian shading with tricubic B-Spline interpolated normals and offset hit position in the gradient direction. | ![]() Lambertian shading using tricubic B-spline interpolated normals. |
After seeing this and getting a bit frustrated, I was just playing around a bit, and noticed the following: Changing the isosurface value radically alters the number of artifacts seen. Presumably this has to do with having nearby voxels with radically different values. Here's some images showing my point.
![]() Tricubic B-Splines on isovalue 1224.5 | ![]() Tricubic B-Splines on isovalue 1902.4 |
|
|
Perhaps this suggests an adaptive lattice for global illumination?
Last Modified: August 27, 2003
Chris Wyman (wyman@cs.utah.edu)