Graphics image rendering with radiance self-transfer for low-frequency lighting environments

[0001] This application claims priority from U.S. Provisional Patent Application No. 60/366,920, filed Mar. 21, 2002.

[0002] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by any one of the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.

[0003] The present invention relates to computer graphics image rendering techniques, and more particularly relates to lighting and shadowing of a modeled object in the rendered image.

[0004] Lighting from area sources, soft shadows, and interreflections are important effects in realistic image synthesis. Unfortunately, general methods for integrating over large-scale lighting environments, including Monte Carlo ray tracing, radiosity, or multi-pass rendering that sums over multiple point light sources, are impractical for real-time rendering. (Monte Carlo ray tracing is described by, inter alia, Cook, R, Porter, T, and Carpenter, L, Distributed Ray Tracing, SIGGRAPH '84, 137-146; Jensen, H, Global Illumination using Photon Maps, Eurographics Workshop on Rendering 1996, 21-30; and Kajiya, J, The Rendering Equation, SIGGRAPH '86, 143-150.) (A radiosity technique is described in Cohen, M, and Wallace, J, Radiosity and Realistic Image Synthesis, Academic Press Professional, Cambridge, 1993.) (Various multi-pass rendering techniques are described by, inter alia, Haeberli, P, and Akeley, K, The Accumulation Buffer: Hardware Support for High-Quality Rendering, SIGGRAPH '90, 309-318; Keller, A, Instant Radiosity, SIGGRAPH '97, 49-56; and Segal, M, Korobkin, C, van Widenfelt, R, Foran, J, and Haeberli, P, Fast Shadows and Lighting Effects Using Texture Mapping, SIGGRAPH '92, 249-252.) Real-time, realistic global illumination encounters three difficultiesit must model the complex, spatially-varying bidirectional reflectance distribution functions (BRDFS) of real materials (BRDF complexity), it requires integration over the hemisphere of lighting directions at each point (light integration), and it must account for bouncing/occlusion effects, like shadows, due to intervening matter along light paths from sources to receivers (light transport complexity). Much research has focused on extending BRDF complexity (e.g., glossy and anisotropic reflections), solving the light integration problem by representing incident lighting as a sum of directions or points. Light integration thus tractably reduces to sampling an analytic or tabulated BRDF at a few points, but becomes intractable for large light sources. A second line of research samples radiance and pre-convolves it with kernels of various sizes. (See, e.g., Cabral, B, Olano, M, and Nemec, P, Reflection Space Image Based Rendering, SIGGRAPH '99,165-170; Greene, N, Environment Mapping and Other applications of World Projections, IEEE CG&A, 6(11):21-29,1986; Heidrich, W, Seidel H, Realistic, Hardware-Accelerated Shading and Lighting, SIGGRAPH '99, 171-178; Kautz, J, Vazquez, P, Heidrich, W, and Seidel, H, A Unified Approach to Pre-filtered Environment Maps, Eurographics Workshop on Rendering 2000, 185-196; and Ramamoorthi, R, and Hanrahan, P, An Efficient Representation for Irradiance Environment Maps, SIGGRAPH '01, 497-500.) This solves the light integration problem but ignores light transport complexities like shadows since the convolution assumes the incident radiance is unoccluded and unscattered. Finally, clever techniques exist to extend complexity of light transport, especially shadows. Light integration becomes the problem; almost all these techniques. are unsuitable for very large light sources.

[0005] A real-time image rendering technique described herein better accounts for light integration and light transport complexity in real-time. This technique focuses on low-frequency lighting environments, using a low-order spherical harmonic (SH) basis to represent such environments efficiently without aliasing. An aspect of the technique is to represent how an object scatters this light onto itself or its neighboring space, in a way that decouples the scattering from the incident lighting. For example, FIG. 8 compares an unshadowed image of a modeled man's head with an image produced as described herein with radiance self-transfer.

[0006] To briefly summarize the described technique, assume initially we have a convex, diffuse object lit by an infinitely distant environment map. The object's shaded response to its environment can be viewed as a transfer function, mapping incoming to outgoing radiance, which in one case simply performs a cosine-weighted integral. A more complex integral captures how a concave object shadows itself, where the integrand is multiplied by an additional transport factor representing visibility along each direction.

[0007] The described technique's approach is to precompute for a given object the expensive transport simulation required by complex transfer functions like shadowing.

[0008] The resulting transfer functions are represented as a dense set of vectors or matrices over its surface. Meanwhile, incident radiance need not be precomputed. During later real-time rendering, the graphics hardware can dynamically sample incident radiance at a limited number of points, which the technique converts to the spherical harmonic (SH) basis with a fast calculation. Analytic models, such as skylight models or simple geometries like circles, can also be used.

[0009] By representing both incident radiance and transfer functions in the SH basis, the described technique reduces the light integral to a simple dot product between their coefficient vectors (diffuse receivers) or a simple linear transform of the lighting coefficient vector through a small transfer matrix (glossy receivers). Low-frequency lighting environments require very few coefficients (9-25), enabling graphics hardware to compute the result in a single pass. Unlike Monte-Carlo and multi-pass light integration methods, the run-time computation with this technique can be kept constant no matter how many or how big the light sources. Keeping a constant amount of run-time computation relies on large-scale, smooth lighting to limit the number of SH coefficients necessary.

[0010] The described technique represents complex transport effects like interreflections and caustics in the transfer function. Since these are all simulated as a preprocess, only the transfer function's basis coefficients change, not the run-time computation. The approach of the described technique handles both surface and volume-based geometry. With more SH coefficients, the technique can even handle glossy (but not highly specular) receivers as well as diffuse, including interreflection. For example, 25 SH coefficients suffice for useful glossy effects. In addition to transfer from a rigid object to itself, called self-transfer, the technique generalizes to neighborhood-transfer from a rigid object to its neighboring space, allowing cast soft shadows, glossy reflections, and caustics on dynamic receivers.

[0011] FIG. 1 is a block diagram of a computer graphics software architecture incorporating pre-computed radiance self-transfer for real-time image rendering in dynamic, low-frequency lighting environments.

[0012] FIG. 2 is a flow diagram of a self-transfer precomputation in the image rendering system of FIG. 1.

[0013] FIG. 3 is a flow diagram of a real-time rendering of radiance transfer in the image rendering system of FIG. 1.

[0014] FIG. 4 is a flow diagram of processing run-time diffuse surface self-transfer in the real-time rendering of FIG. 3.

[0015] FIG. 5 is a flow diagram of processing run-time glossy surface self-transfer in the real-time rendering of FIG. 3.

[0016] FIG. 6 is a block diagram of a suitable computing environment for the image rendering system of FIG. 1.

[0017] FIG. 7 is a drawing depicting simulated interreflection in the self-transfer precomputation of FIG. 2.

[0018] FIG. 8 depicts images produced both unshadowed and via the real-time rendering of FIG. 3.

[0019] FIG. 9 depicts images produced both unshadowed and via the real-time rendering of FIG. 3, which illustrate effects of diffuse surface self-transfer.

[0020] FIG. 10 depicts images produced both unshadowed and via the real-time rendering of FIG. 3, which illustrate effects of glossy surface self-transfer.

[0021] FIG. 11 depicts images produced via the real-time rendering of FIG. 3 with incident radiance sampled at a single point, iterated closest point algorithm (ICP) points, and multiple samples, respectively.

[0022] FIG. 12 depicts images of volumetric self-transfer produced via the real-time rendering of FIG. 3.

[0023] FIG. 13 depicts images of neighborhood transfer produced via the real-time rendering of FIG. 3.

[0024] With reference to FIG. 1, a software architecture of a computer graphics image rendering system 100 provides real-time image rendering of a modeled object with interreflection and self-shadowing using a radiance self-transfer image rendering technique described herein. In general, the software architecture includes a global illumination simulator 120, a real-time image rendering engine 140, and a graphics display driver 180. In the radiance self-transfer rendering technique described more fully below, the global illumination simulator 120 performs a pre-processing stage of the technique, which precomputes radiance self-transfer data 140 from a geometric object model 110. The geometric model 110 can be a triangulated mesh, wavelet composition, or any other representation of the geometry of the object being modeled. The real-time rendering engine 140 then uses the precomputed radiance self-transfer data to render images of the modeled object for a dynamically variable lighting environment 150 and viewing direction 160, which can be selectively varied or set with user controls 170. The graphics display driver 180 outputs the images to an image output device (e.g., to a monitor, projector, printer or like).

[0025] In some embodiment of the graphics image rendering system, the radiance self-transfer precomputation of simulator 120 and image rendering by the engine 140 can be implemented on a single computer, such as that described in Section 6, Computing Environment, below. More generally, the simulator 120 can be run on a separate computer, and the resulting data then.transferred to the computer on which the rendering engine 140 runs to produce the graphics images.

[0026] Radiance Self Transfer Technique Overview. As a preprocess, the global illumination simulator 120 runs an illumination simulation over the model 110 that captures how the modeled object shadows and scatters light onto itself. The result is recorded in the radiance self-transfer data 130 as a dense set of vectors (diffuse case) or matrices (glossy case) over the model. At image rendering-time, the rendering engine 140 projects incident radiance for the lighting environment 150 to the spherical harmonic (SH) basis (described below). The model's field of transfer vectors or matrices is then applied to the lighting's coefficient vector. If the object is diffuse, a transfer vector at points on the object is dotted with the lighting's coefficients to produce correctly self-scattered shading. If the object is glossy, a transfer matrix is applied to the lighting coefficients to produce the coefficients of a spherical function representing self-scattered incident radiance at the points. This function is convolved with the object's bi-directional reflectance distribution function (BRDF) and then evaluated at the view-dependent reflection direction to produce the final shading for the object in the image being rendered.

[0027] 1. Review of Spherical Harmonics

[0028] Definition. Spherical harmonics define an orthonormal basis over the sphere, S, analogous to the Fourier transform over the 1D circle. Using the parameterization

[0029] the basis functions are defined as $Y_l^m\left(,\right)=K_l^m{}^m{P}_l^{\left|m\right|}\left(\cos \right),lN,-lml$

[0030] where P_l^m are the associated Legendre polynomials and K_l^m are the normalization constants $K_l^m=\sqrt{\frac{\left(2l+1\right)}{4}\frac{\left(l-\left|m\right|\right)!}{\left(l+\left|m\right|\right)!}}.$

[0031] The above definition forms a complex basis; a real-valued basis is given by the simple transformation $y_l^m=\{\begin{array}{cc}\sqrt{2}\mathrm{Re}\left(Y_l^m\right),& m>0\\ \sqrt{2}\mathrm{lm}\left(Y_l^m\right),& m<0=\\ Y_l^0,& m=0\end{array}\{\begin{array}{cc}\sqrt{2}{K}_l^m\cos \left(m\right)P_l^m\left(\cos \right),& m>0\\ \sqrt{2}{K}_l^m\sin \left(-m\right)P_l^{-m}\left(\cos \right),& m<0\\ K_l^0{P}_l^0\left(\cos \right),& m=0\end{array}$

[0032] Low values of I (called the band index) represent low-frequency basis functions over the sphere. The basis functions for band I reduce to polynomials of order I in x, y, and z. Evaluation can be done with simple recurrence formulas. (See, e.g., Edmonds, A, Angular Momentum in Quantum Mechanics, Princeton University, Princeton, 1960; and Zare, R, Angular Momentum: Understanding Spatial Aspects in Chemistry and Physics, Wiley, N.Y., 1987.)

[0033] Projection and Reconstruction. Because the SH basis is orthonormal, a scalar function f defined over S can be projected into its coefficients via the integral

[0034] These coefficients provide the n-th order reconstruction function $\begin{array}{cc}\stackrel{}{f}\left(s\right)=\underset{l=0}{\overset{n-1}{}}\underset{m=-1}{\overset{1}{}}{f}_l^m{y}_l^m\left(s\right)& \left(2\right)\end{array}$

[0035] which approximates f increasingly well as the number of bands n increases. Low-frequency signals can be accurately represented with only a few SH bands. Higher frequency signals are bandlimited (i.e., smoothed without aliasing) with a low-order projection.

[0036] Projection to n-th order involves n² coefficients. It is often convenient to rewrite (2) in terms of a singly-indexed vector of projection coefficients and basis functions, via $\begin{array}{cc}\stackrel{}{f}\left(s\right)=\underset{i=1}{\overset{n^2}{}}{f}_i{y}_i\left(s\right)& \left(3\right)\end{array}$

[0037] where iI(I1)m1. This formulation makes it obvious that evaluation at s of the reconstruction function represents a simple dot product of the n²-component coefficient vector f_i with the vector of evaluated basis functions y_i(s).

[0038] Basic Properties. A property of SH projection is its rotational invariance; that is, given g(s)f(Q(s)) where Q is an arbitrary rotation over S then

[0039] This is analogous to the shift-invariance property of the 1D Fourier transform. Practically, this property means that SH projection causes no aliasing artifacts when samples from f are collected at a rotated set of sample points, projected, and then {tilde over (f)} rotated back.

[0040] Orthonormality of the SH basis provides the useful property that given any two functions a and b over S, their projections satisfy $\begin{array}{cc}\stackrel{}{a}\left(s\right)\stackrel{}{b}\left(s\right)s=\underset{i=1}{\overset{n^2}{}}{a}_i{b}_i.& \left(5\right)\end{array}$

[0041] In other words, integration of the product of bandlimited functions reduces to a dot product of their projection coefficients.

[0042] Convolution. The convolution of a circularly symmetric kernel function h(z) with a function f is denoted as h*f. Note that h must be circularly symmetric (and hence can be defined as a simple function of z rather than s) in order for the result to be defined on S rather than the higher-dimensional rotation group SO, as per equation (3) above. Projection of the convolution satisfies $\begin{array}{cc}{\left(h*f\right)}_l^m=\sqrt{\frac{4}{2l+1}}{h}_l^0{f}_l^m={}_l^0{h}_l^0{f}_l^m.& \left(6\right)\end{array}$

[0043] In other words, the coefficients of the projected convolution are simply scaled products of the separately projected functions. This property provides a fast way to convolve an environment map with a hemispherical cosine kernel, defined as h(z)max(z,0), to get an irradiance map (as described in Ramamoorthi, R, and Hanrahan, P, An Efficient Representation for Irradiance Environment Maps, SIGGRAPH '01, 497-500). In this case, the projection coefficients of h can be obtained using an analytic formula. The convolution property can also be used to produce prefiltered environment maps with narrower kernels. Note that because h is circularly symmetric about z, its projection coefficients are nonzero only for m0.

[0044] Product Projection Projection of the product of a pair of spherical functions c(s)a(s)b(s) where a is known and b unknown can be viewed as a linear transformation of the projection coefficients b_j via a matrix : $\begin{array}{cc}\begin{array}{c}{c}_i=a\left(s\right)\left(b_j{y}_j\left(s\right)\right)y_i\left(s\right)s\\ =\left(a\left(s\right)y_i\left(s\right)y_j\left(s\right)s\right)b_j={\hat{a}}_{\mathrm{ij}}{b}_j\end{array}& \left(7\right)\end{array}$

[0045] where summation is implied over the duplicated j index. Note that is a symmetric matrix.

[0046] Rotation. A reconstruction function rotated by Q, {tilde over (f)}(Q(s)), can be projected using a linear transformation of f's projection coefficients, f_i. Because of the rotation invariance property, this linear transformation treats the coefficients in each band independently. The most efficient implementation is achieved using a zyz Euler angle decomposition of the rotation Q, using a fairly complicated recurrence formula. (See, e.g., Chirikjian, G, and Stein, D, Kinematic Design and Commutation of a Spherical Stepper Motor, IEEE Transactions on Mechatronics, 4(4), Dec. 1999; Edmonds, A, Angular Momentum in Quantum Mechanics, Princeton University, Princeton, 1960; and Zare, R, Angular Momentum: Understanding Spatial Aspects in Chemistry and Physics, Wiley, N.Y., 1987.) When dealing only with low-order functions, the explicit rotation formulas described in these references can be implemented using symbolic integration.

[0047] 2. Radiance Self-Transfer

[0048] Radiance self-transfer encapsulates how an object O shadows and scatters light onto itself. Radiance self-transfer is represented by first parameterizing incident lighting at points p o, denoted L_p(s), using the SH basis. Incident lighting is therefore represented as a vector of n² coefficients (L_p)_i. In practice, this lighting can be sampled dynamically and sparsely near the surface, perhaps at only a single point. The assumption is that lighting variation over O not due to its own presence is small (see Section 4.1, Spatial Sampling of the Incident Radiance Field). Radiance self-transfer also can be precomputed and stored densely over O as transfer vectors or matrices.

[0049] A transfer vector (M_p)_i can be used for diffuse surfaces and represents a linear transformation on the lighting vector producing scalar exit radiance, denoted L_p, via the inner product $\begin{array}{cc}{L}_P^{}=\underset{i=1}{\overset{n^2}{}}{\left(M_P\right)}_i{\left(L_P\right)}_i& \left(8\right)\end{array}$

[0050] In other words, each component of (M_p)_i represents the linear influence that a lighting basis function (L_p)_i has on shading at p.

[0051] A transfer matrix (M_p)_ij can be used for glossy surfaces and represents a linear transformation on the lighting vector which produces projection coefficients for an entire spherical function of transferred radiance L_p(s) rather than a scalar; i.e, $\begin{array}{cc}{\left(L_P^{}\right)}_i=\underset{j=1}{\overset{n^2}{}}{\left({}_p\right)}_{\mathrm{ij}}{\left(L_p\right)}_j.& \left(9\right)\end{array}$

[0052] The difference between incident and transferred radiance is that L_p(s) includes shadowing and scattering effects due to the presence of O while L_p(s) represents incident lighting assuming O was removed from the scene. Components of (M_p)_ij represent the linear influence of the j-th lighting coefficient of incident radiance (L_p)_j to the i-th coefficient of transferred radiance L_p(s). The next sections show how to derive transfer vectors for diffuse surfaces and transfer matrixes for glossy surfaces due to self-scattering on O.

[0053] 2.1 Diffuse Transfer

[0054] First assume O is diffuse. The simplest transfer function at a point p O represents unshadowed diffuse transfer, defined as the scalar function

[0055] producing exit radiance which is invariant with view angle for diffuse surfaces. Here, _p is the object's albedo at p, L_p is the incident radiance at p assuming O was removed from the scene, N_p is the object's normal at p, and H_NP(s)max(N_ps,0) is the cosine-weighted, hemispherical kernel about N_p. By SH-projecting L_p and H_Np separately, equation (5) reduces T_DU to an inner product of their coefficient vectors. The resulting factors are referred to herein as the light function, L_p, and transfer function, M_p. In this first simple case, MPDU(s) $M_p^{\mathrm{DU}}\left(s\right)=H_{Np}\left(s\right).$

[0056] Because N_p is known, the SH-projection of the transfer function $\left(M_p^{\mathrm{DU}}\right)$

[0057] can be precomputed, resulting in a transfer vector. In fact, storing is unnecessary because a simple analytic formula yields it given N_p. Because $M_p^{\mathrm{DU}}$

[0058] is inherently a low-pass filter, second-order projection (9 coefficients) provides good accuracy in an arbitrary (even non-smooth) lighting environment.

[0059] To include shadows, we define shadowed diffuse transfer as

[0060] where the additional visibility function, V_p(s)0,1, equals 1 when a ray from p in the direction s fails to intersect O again (i.e., is unshadowed). As with unshadowed transfer, this integral can be decomposed into two functions, using an SH-projection of L_p and the transfer function $\begin{array}{cc}{M}_p^{\mathrm{DS}}\left(s\right)=H_{Np}\left(s\right)V_p\left(s\right).& \left(10\right)\end{array}$

[0061] Separately SH-projecting L_p and M_p again reduces the integral in T_DS to an inner product of coefficient vectors.

[0062] Transfer is now nontrivial; Radiance self-transfer can be precomputed using a transport simulator (as described in Precomputing Self-Transfer Section below), storing the resulting transfer vector (M_p)_i at many points p over 0. Unlike the previous case, second-order projection of $M_p^{\mathrm{DS}}$

[0063] may be inaccurate even for'smooth lighting environments since V_p can create higher-frequency lighting locally, e.g., by self-shadowing pinholes. Using 4-th or 5-th order projection provides good results on typical meshes in smooth lighting environments. Compare, for example, the unshadowed and shadowed images of the diffuse surface object in FIG. 9.

[0064] Finally, to capture diffuse interreflections (see, for example, the interreflected image in FIG. 9) as well as shadows, the interreflected diffuse transfer can be defined as

[0065] where {tilde over (L)}_p(s) is the radiance from O itself in the direction s. The difficulty is that unless the incident radiance emanates from an infinitely-distant source, the radiance {tilde over (L)}_p(s) is not known given the incident radiance only at p because {tilde over (L)}_p depends on the exit radiance of points arbitrarily far from p and local lighting varies over O. If lighting variation is small over O then {tilde over (L)}_p is well-approximated as if O were everywhere illuminated by L_p. T_DI thus depends linearly on L_p and can be factored as in the previous two cases into a product of two projected functions: one light-dependent and the other geometry-dependent.

[0066] Though precomputed interreflections must make the assumption of spatially invariant incident lighting over O, simpler shadowed transfer need not. The difference is that shadowed transfer depends only on incident lighting at p, while interreflected transfer depends on many points qp over O at which L_qL_p. Thus, as long as the incident radiance field is sampled finely enough (as discussed in Spatial Sampling of the Incient Radiance Field Section below), local lighting variation can be captured and shadowed transfer will be correct.

[0067] The presence of {tilde over (L)} makes it hard to explicitly denote the transfer function for interreflections, $M_p^{\mathrm{DI}}\left(s\right).$

[0068] The Precomputing Self-Transfer Section below discusses how to compute its projection coefficients numerically.

[0069] 2.2 Glossy Transfer

[0070] Self-transfer for glossy objects can be defined similarly, but generalizes the kernel function to depend on a (view-dependent) reflection direction R rather than a (fixed) normal N. Analogous to the H kernel from before, radiance self-transfer can model glossy reflection as the kernel G(s,R,r) where a scalar r defines the glossiness or broadness of the specular response.

[0071] The analogous three glossy transfer functions for the unshadowed, shadowed, and interreflected cases can be defined as

[0072] which output scalar radiance in direction R as a function of L_p and R, quantities both unknown at precomputation time. Since transfer is no longer solely a function of s, it can't be reduced to a simple vector of SH coefficients Instead of parameterizing scalar transfer by R and r, a more useful decomposition is to transfer the incident radiance L_p(s) into a whole sphere of transferred radiance, denoted L_p(s). Assuming the glossy kernel G is circularly symmetric about R, L_p(s) can then be convolved with G^*_r(z)G(s,(0,0,1),r) and evaluated at R to produce the final result.

[0073] Transfer to L_p is now represented as a matrix rather than a vector. For example, glossy shadowed transfer can be defined as $\begin{array}{cc}{M}_p^{\mathrm{GS}}\left(L_p,s\right)=L_p\left(s\right)V_p\left(s\right).& \left(11\right)\end{array}$

[0074] a linear operator on L_p whose SH-projection can be represented as the symmetric matrix {circumflex over (V)}_p via equation (7). Even with very smooth lighting, more SH bands are used for L_p as the glossiness of O increases; non-square matrices (e.g., 259) mapping low-frequency lighting to higher-frequency transferred radiance are useful under these conditions.

[0075] An important limitation of precomputed radiance self-transfer is that material properties of O influencing interreflections in T_DI and T_GI (like albedo or glossiness) are baked in to the preprocessed transfer and can't be changed at run-time. On the other hand, the simpler shadowed transfers without interreflection do allow run-time change and/or spatial variation over O of the material properties. Error arises if blockers or light sources intrude into O's convex hull. O can only move rigidly, not deform or move one component relative to the whole. Recall also the assumption of low lighting variation over O required for correct interreflections.

[0076] Finally, note that diffuse transfer as defined above produces radiance after leaving the surface, since it has already been convolved with the cosine-weighted normal hemisphere, while glossy transfer produces radiance incident on the surface and is convolved with the local BRDF to produce the final exit radiance. It's also possible to bake in a fixed BRDF for glossy O, making the convolution with G unnecessary at run-time but limiting flexibility.

[0077] FIG. 9 illustrates unshadowed, shadowed and interreflected images of a glossy surface object.

[0078] 3. Precomputing Self-Transfer

[0079] With reference now to FIG. 2, the illumination simulator 120 (FIG. 1) precomputes the radiance self-transfer of the modeled object in a global illumination simulation 200 (also referred to as self-transfer precomputation) performed over an object O using the SH basis over the infinite sphere as emitters (the reference lighting environment for the simulation). The simulation is parameterized by an n-th order SH projection of the unknown sphere of incident light L; i.e., by n² unknown coefficients L_i. Though the simulation results can be computed independently for each L_i using the SH basis function y_i(s) as an emitter, it is more efficient to compute them all at once. The reference lighting environment (infinitely-distant sphere L) will be replaced at run-time by the actual incident radiance around O, L_p.

[0080] The simulation 200 begins with a pass (shadow pass 202) that simulates direct shadows from paths leaving L and directly reaching sample points p o. In subsequent passes (interreflections passes 204), interreflections are added, representing paths from L that bounce a number of times off O before arriving at p (Lp, LDp, LDDp, etc.). In each pass, energy is gathered to every sample point on the p surface. Large emitters (i.e., low-frequency SH basis) make a gather more efficient then a shooting-style update.

[0081] To capture the sphere of directions at sample points p o, the simulation generate a large (10 k-30 k), quasi-random set of directions S_d, S_d s . The simulation also precomputes evaluations for all the SH basis functions at each direction S_d. The directions S_d are organized in hierarchical bins formed by refining an initial icosahedron with 12 bisection into equal-area spherical triangles (14 subdivision does not lead to equal area triangles on the sphere as it does in the plane). The simulation uses 6 to 8 subdivision levels, creating 512 to 2048 bins. Every bin at each level of the hierarchy contains a list of the S_d within it.

[0082] In the first or shadow pass 202, for each p o, the simulation 200 tags (at 211) those directions from the point p that are self-occluded by the object. The simulation casts shadow rays in the hemisphere about p's normal N_p, using the hierarchy to cull directions outside the hemisphere. The simulation tags each direction S_d with an occlusion bit, 1V_p(S_d), indicating whether S_d is in the hemisphere and intersects O again (i.e., is self-shadowed by O). An occlusion bit is also associated with the hierarchical bins, indicating whether any sd within it is occluded. Self-occluded directions and bins are tagged so that we can perform further interreflection passes on them; completely unoccluded bins/samples receive only direct light from the environment.

[0083] Next, at 212, the simulation 200 integrates the transfer radiance for the points p. For diffuse surfaces, at each point p o,the simulation further computes the transfer vector by SH-projecting M_p from equation (10). For glossy surfaces, the simulation computes the transfer matrix by SH-projecting M_p from equation (11). In either case, the result represents the radiance collected at p, parameterized by L. SH-projection to compute the transfers is performed by numerical integration over the direction samples S_d, summing into an accumulated transfer using the following rules:

	diffuse:	( M p ) i o += ( p / ) V p ( s d ) H N ( s d ) y i ( s d )
	glossy:	( p ) ij o += V p ( s d ) y j ( s d ) y i ( s d )
	Transfer integration over sd shadow pass, iteration 0

[0084] The superscript O refers to the iteration number. The vector M_p or matrix M_p at each point p is initialized to O before the shadow pass, which then sums over all S_d at every p. The rules are derived using equation (1) for diffuse transfer integration, and equation (7) for glossy transfer integration.

[0085] With reference also to FIG. 7, later interreflection passes 204 traverse the bins having the occlusion bit set during the shadow pass to now integrate the interreflection transfer at 221. Instead of shadow rays, the simulation shoots rays that return transfer from exiting illumination on O. If the ray (p,S_d) intersects another point q o (where q is closest to p), we sample the radiance exiting from q in the directionS_d. The following update rules are used, where the superscript b is the bounce pass iteration:

diffuse:	( M p ) i o += ( p / ) ( 1 - V p ( s d ) ) ( M q ) i b - 1 H N ( s d )
glossy:	( p ) ij o += ( p / ) ( 1 - V p ( s d ) ) ( M q ) i b - 1 H N ( s d ) ( k k ( G r q * ) k ( q ) kj b - 1 y k ( reflect ( - s d , N q ) ) ) y i ( s d )
Transfer integration over sd interreflection passes, iteration b

[0086] As in the shadow pass 202, the interreflections pass(es) 204 begin by initializing transfer vectors or matrices to 0 before accumulating transfer over directions S_d. The diffuse rules are derived from the definition of T_DI and equation (1); glossy rules from the definition of T_GI and equations (6) and (7). The middle factor in the glossy transfer definition represents radiance emanating from q back to p from the previous bounce pass, b1. Since M_q stores incident radiance, it must be convolved with O's BRDF at q to obtain exiting radiance in the S_d direction, yielding a summation over k. Recall that _k is the k-th convolution coefficient, expressed in singly-indexed notation. The reflect operator simply reflects its first vector argument with respect to its second. Observe that equation (7) implies (M_p)_ij is a symmetric matrix for shadowed glossy transfer since it is formed by the product of two spherical functions; this is untrue for interreflected glossy transfer.

[0087] As shown at 230, interreflection passes 204 are repeated until an end criteria is met, such as the total energy of a given pass falls below a threshold of significance. For typical materials, interreflection diminishes quite rapidly. The sum of transfers from all bounce passes then accounts for interreflections.

[0088] Alternatively, a simple enhancement to this simulation allows mirror-like surfaces within O. The simulation does not record transfers on such surfaces. Instead, a ray striking a mirrored surface is always reflected and then propagated until a non-mirrored surface is reached. Thus, the paths at successive iterations can be represented as (LS*p, LS*DS*p, LS*DS*DS*p, etc.), where D is a diffuse or glossy bounce and S is a specular one. This captures caustics onto diffuse or glossy receivers that respond dynamically to lighting change.

[0089] 4. Run-time Rendering of Radiance Transfer

[0090] The simulation 200, (FIG. 2) just described provides a model capturing radiance transfer at many points p over the object's surface, represented as vectors or matrices. With reference now to FIG. 3, the real-time rendering engine 140 (FIG. 1) then uses this model in a run-time procedure 300 to compute the object's self-transfer radiance during real-time image rendering of the object in a chosen lighting environment and viewing direction. FIGS. 4 and 5 separately illustrate the processing flow according to run-time procedure 300 for diffuse and glossy surfaces, respectively.

[0091] In the procedure 300, the rendering engine 140 performs the following actions at run-time: at 310, compute incident lighting L_Pi at one or more sample points P_i near O in terms of the SH basis; at 320, rotate these L_Pi to O's coordinate frame and blend them (see below) to produce a field of incident lighting L_p over 0; and at 330-390, perform a linear transformation on (L_p)_i at each point p on O to obtain exit radiance. This linear transformation is a dot product with (M_p)_i for diffuse surfaces (equation (8)) at action 350, or a matrix-vector multiplication with (M_p)_ij for glossy surfaces (equation (9)) at action 360. Glossy surfaces have further actions 370 and 380 in which the radiance vector resulting from the multiplication 360 is convolved with O's BRDF at p, and then evaluated at the view-dependent reflection direction R.

[0092] For action 310, the rendering engine 140 can load a precomputed environment map, evaluate analytic lighting models in software, or sample radiance using graphics hardware, as representations for the incident lighting of the chosen lighting environment. The rotation for action 320 is outlined in Section 1, Review of Spherical Harmonics, and is done once per object, not for each p. The rotation is performed because transfer is stored using a common coordinate system for O. If O is rigidly moving, it is more efficient to rotate the few radiance samples in Lpi to align with O than it is to rotate O's many transfer functions.

[0093] For diffuse surfaces, a simple implementation of action 350 is to store the transfer vector per vertex and perform the dot product in a vertex shader. The transfer vectors can also be stored in texture maps rather than per-vertex and evaluated using a pixel shader. Since the coefficients are signed quantities not always in the 1,1 range, DirectX 8.1 pixel shaders (V1.4) or their OpenGL counterpart (extension by ATI) can be used, since they provide a larger range of 8,8. In one implementation, the pixel shader needs only 8 instructions to perform the dot-product and stores L_p's projection coefficients in constant registers.

[0094] For colored environments or simulation of color bleeding on O, three passes are performed, each performing a separate dot-product for the r, g, and b channels. Otherwise, a single pass suffices.

[0095] For glossy self-transfer, the matrix transform from equation (10) can be performed in software because the transfer matrix can be too large to be manipulated in either current vertex or pixel shaders. The result is (L_p)_i the SH coefficients of transferred radiance at points p over O. Then in a pixel shader, the convolution 370 can be performed with a simple cosine-power (Phong lobe) kernel for G^*and evaluate the result in the reflection direction R. The result can be written $\begin{array}{cc}\underset{i=1}{\overset{n^2}{}}{}_i{G}_i^{*}\left(\underset{j=1}{\overset{n^2}{}}{\left(M_p\right)}_{\mathrm{ij}}{\left(L_p\right)}_j\right)y_i\left(R\right)& \left(12\right)\end{array}$

[0096] SH-projections up to 5-th order can be evaluated on current graphics hardware.

[0097] 4.1 Spatial Sampling of the Incident Radiance Field

[0098] A simple and useful approach for dynamically sampling incident radiance is to sample the incident radiance at O's center point. To handle local lighting variation over O, a more accurate technique samples incident lighting at multiple points. A good set of sample points can be obtained using the ICP (iterated closest point) algorithm (see, Linde, Y, Buzo, A, and Gray, R, An algorithm for Vector Quantizer Design, IEEE Transaction on Communication COM-28, 1980, 84-95) as a preprocess, given a desired number of points as input. This produces a representative set of points P_i near O and distributed uniformly over O where incident lighting can be sampled at run-time. The rendering engine 140 also can precompute coefficients at each p over O that blend contribution from each of the resulting sampled radiance spheres L_Pi to produce an incident radiance field over O, denoted previously by L_p.

[0099] FIG. 11 depicts images resulting from sampling incident radiance at a single point, ICP points, and multiple samples, and rendering using the run-time procedure 300 of FIG. 3.

[0100] 4.2 Sampling SH Radiance on Graphics Hardware

[0101] Graphics hardware is useful to capture the radiance samples L_Pi in a dynamic scene. To do this, 6 images are rendered from each P_i corresponding to the 6 faces of the cube map spherical parameterization. O itself should be removed from these renderings. Cube map images are then projected to their SH coefficients using the integral in equation (1).

[0102] For efficiency, textures are precomputed for the basis functions weighted by differential solid angle, B_l^m(s)y_l^m(s)ds(s), each evaluated over the cube map parameterization for s. The resulting integral then becomes a simple dot product of the captured samples of L_P(S) with the textures B_l^m(s).

[0103] Ideally, this computation would be performed on the graphics hardware. Alternatively, due to precision issues and inability to do inner products in hardware, the sampled radiance images may be read back and then projected in software. In this case, it is helpful to reduce the resolution of read-back images as much as possible.

[0104] Low-order SH projection can be computed with very low-resolution cube maps, assuming they have been properly bandlimited. For example, spherical signals already bandlimited to 6-th order can be projected using 644 images with about 0.3% average-case squared error and about 1% worst-case squared error, where error is normalized by assuming unit-power signals (i.e., signals whose integrated square over the sphere is 1). (More precisely, average-case error is the integrated squared difference between the reference and reconstruction signals, averaged over all unit-power signals. Worst-case error is the same integrated error, but for the worst-case unit-power signal.) For 688 maps, this error reduces to 0.003% mean and 0.02% worst-case. Unfortunately, typical signals aren't spherically bandlimited. Another analysis shows that, assuming continuous bilinear reconstruction over the sampled 2D images, projection to 6-th order using 688 images yields 0.7% and 2% average and worst-case squared error, while 61616 yields 0.2% and 0.5% error.

[0105] In an illustrative implementation, 61616 images are extracted from the hardware. As is always true in point-sampled rendering, aliasing of the 2D images is still a problem because the above analysis uses bilinear reconstruction from point samples as the reference. To reduce aliasing, the cube map images can be supersampled (e.g., by a factor of 2) in each dimension, and a box-filtered decimation performed in hardware before reading back and projecting. The basis function textures are also supersampled and decimated in the same way as a preprocess. For a radiance sample, including read-back and SH projection, this illustrative implementation takes about 1.16 ms on a PIII-933 PC with ATI Radeon 8500.

[0106] 4.3 Self-Transfer for Volumetric Models

[0107] Self-transfer on volumetric data uses the same framework as surfaces. The resulting precomputed model allows run-time changes to the lighting, with correct shadowing and interreflections in any low-frequency lighting environment. FIG. 12 illustrates images of a cloud model for which volumetric self-transfer was used in a volumetric self-transfer variation (described hereafter) of run-time procedure 300 to capture how the cloud model shadows and scatters light to itself.

[0108] As with surface transfer, a preprocessing step simulates lighting on the volume using the SH basis functions as emitters. For shadowed transfer without interreflection (i.e., direct shadowing), the simulator gathers energy from the emitter to every voxel p of the volume, attenuated by its path through the volume. The required numerical integration over directions S_d can be expressed as

[0109] where A(pq) is the volume's integrated attenuation along the path from p to q, and D is the distance until the ray (P,S_d) exits the volume. To include interreflections, the simulation traverses every voxel p and forward-scatter its transfer along random directions S_d. The transfer is deposited to all voxels q along sd until exiting the volume, using the rule ${\left(M_q\right)}_i^b+=A\left(pq\right){\left(M_p\right)}_i^{b-1}$

[0110] More passes over the volume produce further indirect bounces.

[0111] Rendering is performed in the traditional way: by drawing slices through the 3D volume in back to front order using alpha blending to account for transparency. Each slice is a 2D image containing samples of the transfer vector. A pixel shader computes the dot-product between the lighting's coefficients and the transfer vector's required to shade each slice.

[0112] 5. Radiance Neighborhood-Transfer

[0113] Neighborhood-transfer precomputes an object O's influence on its neighboring environment with respect to parameterized, low-frequency lighting. FIG. 13 illustrates images of a hang glider casting soft shadows onto a neighboring bumpy terrain captured with a neighborhood transfer variation (described hereafter) of the simulation 200 (FIG. 2) and run-time rendering procedure 300 (FIG. 3). Transport simulation is identical to that for self-transfer in Section 3, Precomputing Self-Transfer, but takes place with respect to points in a 3D space surrounding O, not on it. At run-time, an arbitrary receiver R can be placed in this volume to capture shadows, reflections, and caustics cast by O onto R without knowing R in advance. For example, a moving vehicle O can cast shadows over a terrain R. Cast shadows and lighting also respond to lighting change; for example, moving the lights move soft shadows on R. This generalizes irradiance volumes (see, e.g., Greger, G., Shirley, P, Hubbard, P, and Greenberg, D, The Irradiance Volume, IEEE Computer Graphics and Applications, 6(11):21-29, 1986) by accounting for glossy transfer and allowing dynamic lighting.

[0114] Because R is unknown during the precomputation step, O's neighborhood volume stores a transfer matrix rather than a vector. This is true even for diffuse receivers, because it is not known in advance what R's normal will be.

[0115] In one implementation, the simulator precomputes the transfer matrix M_p at each point within a simple 3D grid surrounding O. At run-time, the rendering engine performs the matrix transform from equation (9) in software at each point in the volume and uploads the result to the graphics hardware. The result is a volume texture containing coefficients of transferred radiance (L_p), which is applied to R.

[0116] Then, in a pixel shader, this transferred radiance is used to light the receiver. A diffuse receiver convolves the radiance with the cosine weighted hemisphere H* using equation (6) and then evaluates the resulting SH projection at R's normal vector. Glossy receivers perform equation (12).

[0117] Receivers having precomputed self-transfer raise the difficulty that O and R do not share a common coordinate system. Thus, one of the two object's dense set of transfer samples must be dynamically rotated to align with the other's. Although its complexity is O(n⁴), identical to the complexity of performing the matrix transform in equation (9), rotation of higher-order projections is substantially more expensive than that operation. Improving hardware should soon ease this difficulty.

[0118] Compared to self-transfer, neighborhood-fransfer incurs some additional approximation errors. Cast shadow or light from multiple neighborhood-transfer objects onto the same receiver is hard to combine. Local lighting variation not due to O or R's presence is also a problem; lighting must be fairly constant across O's entire neighborhood to provide accurate results. In particular, errors such as missing shadows will result when objects besides O and R intrude into O's neighborhood. O's neighborhood must also be large enough to encompass any cast shadow or light it may cast on R. Nevertheless, neighborhood transfer captures effects impossible to obtain in real-time with previous methods.

[0119] 6. Computing Environment

[0120] FIG. 6 illustrates a generalized example of a suitable computing environment (600) in which the illustrative embodiment may be implemented. The computing environment (600) is not intended to suggest any limitation as to scope of use or functionality of the invention, as the present invention may be implemented in diverse general-purpose or special-purpose computing environments.

[0121] With reference to FIG. 6, the computing environment (600) includes at least one processing unit (610) and memory (620). In FIG. 6, this most basic configuration (630) is included within a dashed line. The processing unit (610) executes computer-executable instructions and may be a real or a virtual processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. The memory (620) may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two. The memory (620) stores software (680) implementing graphics image rendering with radiance self-transfer.

[0122] A computing environment may have additional features. For example, the computing environment (600) includes storage (640), one or more input devices (650), one or more output devices (660), and one or more communication connections (670). An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing environment (600). Typically, operating system software (not shown) provides an operating environment for other software executing in the computing environment (600), and coordinates activities of the components of the computing environment (600). As already mentioned, the computing environment desirably includes graphics processing hardware and software, such as the DirectX and OpenGL function libraries, and ATI Radeon or NVidia GeForce video cards.

[0123] The storage (640) may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, or any other medium which can be used to store information and which can be accessed within the computing environment (600). The storage (640) stores instructions for the software (680) implementing the image rendering system (FIG. 1).

[0124] The input device(s) (650) may be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing environment (600). For audio, the input device(s) (650) may be a sound card or similar device that accepts audio input in analog or digital form. The output device(s) (660) may be a display, printer, speaker, or another device that provides output from the computing environment (600).

[0125] The communication connection(s) (670) enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, compressed audio or video information, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired or wireless techniques implemented with an electrical, optical, RF, infrared, acoustic, or other carrier.

[0126] The invention can be described in the general context of computer-readable media. Computer-readable media are any available media that can be accessed within a computing environment. By way of example, and not limitation, with the computing environment (600), computer-readable media include memory (620), storage (640), communication media, and combinations of any of the above.

[0127] The invention can be described in the general context of computer-executable instructions, such as those included in program modules, being executed in a computing environment on a target real or virtual processor. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Computer-executable instructions for program modules may be executed within a local or distributed computing environment.

[0128] For the sake of presentation, the detailed description uses terms like determine, get, adjust, and apply to describe computer operations in a computing environment. These terms are high-level abstractions for operations performed by a computer, and should not be confused with acts performed by a human being. The actual computer operations corresponding to these terms vary depending on implementation.

[0129] Having described and illustrated the principles of our invention with reference to an illustrative embodiment, it will be recognized that the illustrative embodiment can be modified in arrangement and detail without departing from such principles. It should be understood that the programs, processes, or methods described herein are not related or limited to any particular type of computing environment, unless indicated otherwise. Various types of general purpose or specialized computing environments may be used with or perform operations in accordance with the teachings described herein. Elements of the illustrative embodiment shown in software may be implemented in hardware and vice versa.

[0130] In view of the many possible embodiments to which the principles of our invention may be applied, we claim as our invention all such embodiments as may come within the scope and spirit of the following claims and equivalents thereto.