# Rendering equation for spherical lights

I am currently implementing spherical lights in my DirectX game engine. I decided to build the shading formula from the classical rendering equation. Here is what I get:

The simplifications show that the cosine term should be removed for spherical lights since power is a Flux. Here the problem. While looking for recourses online I found that engines always multiply by the cosine term, even for spherical lights.

Is it wrong or am I missing something?

• Yes, everything after the first equation is wrong. The cosine in the denominator is not the same as the cosine in the numerator. As a matter of fact, if your light is a point light, the radiance for it is not technically defined, since dA makes no sense (it has no area). – lightxbulb Nov 18 '19 at 0:00
• Thanks for the reply. The light has an area of LightRadius (see last line). In fact equations 2 to 4 are from the photon mapping algorithm(see page 26). Please could you clarify the difference between the cosines? – B Lee Nov 18 '19 at 2:09
• If you have a light with radius you need stochastic sampling, which I doubt is what you are going for. The cosine in the denominator should be with respect to the normal at the point on the surface of the light from which the ray emanates, while the cosine in the rendering equation is with respect to the normal at the point being shaded. Please link an article describing the "omni light" you are going for. – lightxbulb Nov 18 '19 at 7:36
• If i understand well the photon mapping simplification is wrong? Lights are simple isotropic spherical lights. – B Lee Nov 18 '19 at 15:31
• Photon mapping in general is not "wrong". What you wrote however, seems wrong. If your lights are spherical, then you need to sample their surface, but this is not what omnidirectional lights are in realtime graphics. So my belief is that you are just confusing different terms and notions. – lightxbulb Nov 18 '19 at 17:48

If you just want to explicitly sample an area light, then here's the general procedure you should follow. Pick light $$i$$ out of $$L$$ lights with some probability $$p_i$$ (the other probabilities being $$p_1,...,p_L$$, a light may be picked through inverse transform sampling). Pick a point $$\pmb{y}$$ on the surface of the light with some probability $$q_i(\pmb{y})$$. Then your estimator is:

$$I_N = \frac{1}{N}\sum_{k=1}^{N}\frac{1}{p_{i_k}q_{i_k}(\pmb{y}_k)}f(\pmb{z} \leftarrow \pmb{x} \leftarrow \pmb{y}_k)L_e(\pmb{y}_k\rightarrow\pmb{x})\frac{\cos\theta_x\cos\theta_{y_k}}{\|\pmb{x}-\pmb{y}_k\|^2_2}V(\pmb{x},\pmb{y}_k)$$

Note that this is only for direct illumination at point $$\pmb{x}$$. I have generalized it to a secondary estimator using $$N$$ samples, so essentially you pick $$N$$ points $$\pmb{y}_1,...,\pmb{y}_N$$ on possibly different lights. This is an estimator that can directly be derived from the area formulation of the rendering equation:

$$L(\pmb{z} \leftarrow \pmb{x}) = L_e(\pmb{x} \leftarrow \pmb{z}) + \int_{\Omega}f(\pmb{z} \leftarrow \pmb{x} \leftarrow \pmb{y})L(\pmb{y}\rightarrow\pmb{x})\frac{\cos\theta_x\cos\theta_y}{\|\pmb{x}-\pmb{y}_k\|^2_2}V(\pmb{x},\pmb{y})\,dA(\pmb{y})$$

The area formulation can be derived from the solid angle one, by using the identity:

$$d\omega = \frac{\cos\theta_y}{r^2}dA$$,

as well as:

$$L_i(\pmb{x}, \omega) = L(r(\pmb{x},\omega) \rightarrow \pmb{x}) = L(\pmb{y} \rightarrow \pmb{x})V(\pmb{x},\pmb{y})$$

• Marvelous thanks! This is what I was looking for. What is the meaning of the lower exponent of ∥xx−yyk∥? Also is it possible to have information about where the procedure is from? – B Lee Nov 19 '19 at 1:08
• @BLee It's indicating that this is the 2-norm/Euclidean norm. I don't think the procedure is from somewhere specifically - it's just using an estimator for the area formulation of the rendering equation. If you are asking where the area formulation was introduced - see Kajiya's paper: "The rendering equation". – lightxbulb Nov 19 '19 at 14:57
• Thank you! One last question please. As you explained the cosine simplification I initially made was wrong. Since Photon Mapping is using it, isn't Photon Mapping wrong too? – B Lee Nov 24 '19 at 0:42
• @BLee The photon mapping algorithm is not "wrong", it's the image you pasted and your comments on it that are wrong. The cosine "simplification" in photon mapping is just rewriting the radiance as a double derivative of the flux, whereas you wrote intensity and you are talking about spherical lights as opposed to photons. Notably this is wrong: "The simplifications show that the cosine term should be removed for spherical lights since power is a Flux.", it follows not from the eq. even if you were to write them correctly. Please make a new question for future discussions. – lightxbulb Nov 24 '19 at 8:04
• I never talked about intensity... "I" is the "flux" as mentioned at line 2. As I said equations 1 to 5 should be either valid, either wrong for any kind of light. The emitter could be photons, spherical, or any light with a random power distribution. – B Lee Nov 24 '19 at 17:10