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

<p><span class="math-container">$$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)$$</span></p>

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

<p><span class="math-container">$$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})$$</span></p>

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

<p><span class="math-container">$$d\omega = \frac{\cos\theta_y}{r^2}dA$$</span>,</p>

<p>as well as:</p>

<p><span class="math-container">$$L_i(\pmb{x}, \omega) = L(r(\pmb{x},\omega) \rightarrow \pmb{x}) = L(\pmb{y} \rightarrow \pmb{x})V(\pmb{x},\pmb{y})$$</span></p>

CC BY-SA 4.0
2019-11-19T01:08:32.330Z
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
CC BY-SA 4.0
2019-11-19T14:57:21.947Z
@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
CC BY-SA 4.0
2019-11-24T00:42:54.190Z
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
CC BY-SA 4.0
2019-11-24T08:04:29.637Z
@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
CC BY-SA 4.0
2019-11-24T17:10:46.147Z
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
CC BY-SA 4.0
2019-11-24T17:57:16.833Z
@BLee I is standard notation for intensity while $\Phi$ is standard notation for flux. The $(I \mapsto flux)$ is actually notation for function mapping, so it made even less sense (e.g. $f(x) = x^2 \iff x \mapsto x^2$). If that is flux, then 1,2,3 are correct (note that $*$ is generally used for convolution and not mult). 4 and 5 you have to formalize if you want them to mean something. I am not sure what 6 is about or where you took it from. Then again, are you doing photon mapping or do you just want to sample lights? I recommend formulating that in a new question, with more details.
lightxbulb
CC BY-SA 4.0
2019-11-18T22:00:09.013Z
2019-11-18T22:00:09.013Z
lightxbulb
<p>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:
<a href="https://i.sstatic.net/MiwIQ.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/MiwIQ.jpg" alt="enter image description here"></a></p>

<p>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.</p>

<p>Is it wrong or am I missing something?</p>

CC BY-SA 4.0
2019-11-18T00:00:04.553Z
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
CC BY-SA 4.0
2019-11-18T02:09:52.583Z
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](https://graphics.stanford.edu/courses/cs348b-00/course8.pdf)(see page 26).
Please could you clarify the difference between the cosines?
B Lee
CC BY-SA 4.0
2019-11-18T07:36:19.000Z
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
CC BY-SA 4.0
2019-11-18T15:31:18.910Z
If i understand well the photon mapping simplification is wrong? Lights are simple isotropic spherical lights.
B Lee
CC BY-SA 4.0
2019-11-18T17:48:40.380Z
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
CC BY-SA 4.0
2019-11-18T18:19:38.697Z
Lines 2 to 4 are from the photon mapping algorithm.  The specialization to omnilights only appears at the last line. Then the first lines does not rely to any specific type of lights. If it is wrong it should be for all algorithm. I am not confused about the type of light. It is possible to cast rays in realtime with Direct x 12.
B Lee
CC BY-SA 4.0
2019-11-18T18:50:12.240Z
Not in a form I am familiar with, nor does it match the form its creator introduces in his book, so idk about that. There's no "specialization to omnilights" as far as I am aware. I am not even sure what omni-lights should have to do with the photon mapping formulation. It is possible to cast rays in realtime with dx12, however you cast those to spherical lights, which are usually not called omnilights, and then you don't have the funny simplifications you are trying to derive. Since it seems like you have multiple questions, I'd recommend you hop onto the CG discord, so I could clarify all.
lightxbulb
CC BY-SA 4.0
2019-11-18T19:36:52.307Z
Thanks again for your help. I updated the question to make it clear it is about spherical lights. What I meant was the first 5 lines should be valid/invalid for any kind of light. What is the CG discord?
B Lee
<rendering><3d><lighting><brdf><directx>
Rendering equation for spherical lights
B Lee
# Rendering equation for spherical lights

(Asked by: username_0 on 2019-11-17)

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:
[![enter image description here](https://i.sstatic.net/MiwIQ.jpg)](https://i.sstatic.net/MiwIQ.jpg)

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?

**Tags:** rendering, 3d, lighting, brdf, directx

> **Comments:**
> **username_1**: 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).  
> **username_0**: 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](https://graphics.stanford.edu/courses/cs348b-00/course8.pdf)(see page 26). Please could you clarify the difference between the cosines?  
> **username_1**: 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.  
> **username_0**: If i understand well the photon mapping simplification is wrong? Lights are simple isotropic spherical lights.  
> **username_1**: 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.  
> **username_0**: Lines 2 to 4 are from the photon mapping algorithm.  The specialization to omnilights only appears at the last line. Then the first lines does not rely to any specific type of lights. If it is wrong it should be for all algorithm. I am not confused about the type of light. It is possible to cast rays in realtime with Direct x 12.  
> **username_1**: Not in a form I am familiar with, nor does it match the form its creator introduces in his book, so idk about that. There's no "specialization to omnilights" as far as I am aware. I am not even sure what omni-lights should have to do with the photon mapping formulation. It is possible to cast rays in realtime with dx12, however you cast those to spherical lights, which are usually not called omnilights, and then you don't have the funny simplifications you are trying to derive. Since it seems like you have multiple questions, I'd recommend you hop onto the CG discord, so I could clarify all.  
> **username_0**: Thanks again for your help. I updated the question to make it clear it is about spherical lights. What I meant was the first 5 lines should be valid/invalid for any kind of light. What is the CG discord?  

---

## 1 answers

### Answer by username_1 on 2019-11-18. Score: 1 | Accepted answer

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})$$

> **Comments:**
> **username_0**: 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?  
> **username_1**: @username_0 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".  
> **username_0**: 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?  
> **username_1**: @username_0 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.  
> **username_0**: 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.  
> **username_1**: @username_0 I is standard notation for intensity while $\Phi$ is standard notation for flux. The $(I \mapsto flux)$ is actually notation for function mapping, so it made even less sense (e.g. $f(x) = x^2 \iff x \mapsto x^2$). If that is flux, then 1,2,3 are correct (note that $*$ is generally used for convolution and not mult). 4 and 5 you have to formalize if you want them to mean something. I am not sure what 6 is about or where you took it from. Then again, are you doing photon mapping or do you just want to sample lights? I recommend formulating that in a new question, with more details.  

---

