<p>I'm going to provide the simple/naive/brute force answer to this question, which does work, and gives accurate results.</p>

<p>There are better answers however, which make the rendering converge faster with fewer samples, but uses more advanced math.  I'm hoping someone else will provide an answer along those lines.</p>

<p>The simple answer is this:
Area lights are just geometry which have an emissive value.</p>

<p>To add support for emissive values to path tracing is pretty easy luckily.</p>

<p>As you know, the amount of light heading towards a pixel is the amount of light leaving the surface that a ray down that pixel would intersect.</p>

<p>That is calculated recursively by seeing how much light is hitting that point, integrating the BRDF, multiplying by the cosine and all that jazz.</p>

<p>Emissive lighting is just added to that result.  So, whatever you have now as "outgoing light" from a surface, just add to it the emissive color of that surface.  (You could also optionally do something similar to texture mapping and have emissive values vary over the object, possibly based on a texture).</p>

<p>That's all there is to it, it's very simple and easy.</p>

<p>In the rendering equation below, $L_e(\omega_o)$ represents the emissive term (that's what the e stands for, emissive), and the rest of the equation is the light integrated over the hemisphere.  You can see that you just add the emissive to the result you return as your outgoing light from a point ($L_o( \omega_o)$) to apply that emissive lighting.</p>

<p>$L_o( \omega_o)= L_e(\omega_o)+\int_{\Omega}{f(\omega_i, \omega_o)L_i(\omega_i)(\omega_i \cdot n)\mathrm{d}\omega_i}$</p>

<p>You can read more about a simple path tracer with area lights at this link, which also has commented C++ source code.</p>

<p><a href="http://blog.demofox.org/2016/09/21/path-tracing-getting-started-with-diffuse-and-emissive/" rel="noreferrer">http://blog.demofox.org/2016/09/21/path-tracing-getting-started-with-diffuse-and-emissive/</a></p>

<p><a href="https://i.sstatic.net/8miKf.png" rel="noreferrer"><img src="https://i.sstatic.net/8miKf.png" alt="enter image description here"></a></p>

CC BY-SA 3.0
2016-12-03T06:08:12.217Z
Great Answer this really clarified everything, although I'm going off topic a little would you know of any good resources on how to implement depth of field?
Arjan Singh
CC BY-SA 3.0
2016-12-03T06:09:40.617Z
No sorry, but I am interested too. Ask another question IMO!
Alan Wolfe
CC BY-SA 3.0
2017-05-28T12:53:09.150Z
How do I calculate the light direction for use in a Ray Tracer to first calculate the Direct Lighting though? Do I even need to do that? I am little confused here.
Arjan Singh
CC BY-SA 3.0
2017-05-28T14:20:07.700Z
You don't need to do that, no.  You just shoot random rays in the hemisphere, and some of them will hit the light, some of them won't.  There are techniques to shoot rays at the lights more directly while still accounting for the probability of you having chosen them randomly (to make the image look the same), but it's not required, no.
Alan Wolfe
CC BY-SA 3.0
2017-05-28T14:31:47.553Z
I'm still really confused (I'm sorry), but wouldn't this only work for Indirect lighting and not Direct Lighting? Could you add some code to your answer to illustrate this clearer? I looked at the source for path tracer in the blog post on GitHub but I couldn't understand what was going on.
Arjan Singh
CC BY-SA 3.0
2017-05-28T14:35:09.933Z
Also, does this mean I can remove the direct lighting raytracer component from my Renderer entirely since the path tracer can handle this?
Arjan Singh
CC BY-SA 3.0
2017-05-28T14:38:01.137Z
The light leaving a surface in a specific direction is made up of two components: One is the $L_e$ term which is the emissive light, or how much the object glows.  That is the direct lighting. The other component is the rest of the integration, which is how much light is reflected from other lighting sources (direct and indirect lighting sources), this is indirect lighting.  Those two components are added together as light leaving the surface.  Path tracing as I described finds them both because they are treated the same (they are summed and treated as "lighting" not direct or indirect).
Alan Wolfe
CC BY-SA 3.0
2017-05-28T14:40:26.307Z
Yes, you can remove the direct lighting code from your path tracer if you want to.  You will still get accurate results.  However, as I explained from the first couple sentences of the answer, it will take longer to make a good looking image if you do so.  It takes more complex math to have "direct lighting" in your path tracer, and have the results come out correctly, but it does speed things up to have that. You get better results in fewer samples.  But yeah, "direct lighting" code is totally optional, and path tracing works fine without it.
Alan Wolfe
CC BY-SA 3.0
2016-12-02T18:33:39.380Z
2016-12-02T18:41:30.103Z
2016-12-02T18:41:30.103Z
Alan Wolfe
<p>I have been following the <a href="https://www.scratchapixel.com/" rel="noreferrer"><strong>scratchapixel</strong></a> ray tracing tutorials online which have been great at explaining the theory behind everything &amp; how to implement it. However, I reached the point where I want to implement Area Lights but I am clueless on how to do it. The tutorial on the website hasn't been uploaded yet (all though there is a placeholder link with a bunch of others).</p>

<p>There's not much online regarding implementation so this has lead me here. <strong>Could someone please explain how I can implement Area Lights with Ray Tracing</strong> as opposed to Point Lights?</p>

<p><a href="https://i.sstatic.net/KKjbF.jpg" rel="noreferrer"><img src="https://i.sstatic.net/KKjbF.jpg" alt="enter image description here"></a></p>

CC BY-SA 3.0
2016-12-02T17:54:20.873Z
Just checking... this is ray tracing right, not path tracing?
Alan Wolfe
CC BY-SA 3.0
2016-12-02T18:17:52.507Z
I meant to say Path Tracing, will change the title.
Arjan Singh
<rendering><raytracing><physically-based><area>
Area Lights in Path Tracing
Arjan Singh
# Area Lights in Path Tracing

(Asked by: username_0 on 2016-12-02)

I have been following the [**scratchapixel**](https://www.scratchapixel.com/) ray tracing tutorials online which have been great at explaining the theory behind everything & how to implement it. However, I reached the point where I want to implement Area Lights but I am clueless on how to do it. The tutorial on the website hasn't been uploaded yet (all though there is a placeholder link with a bunch of others).

There's not much online regarding implementation so this has lead me here. **Could someone please explain how I can implement Area Lights with Ray Tracing** as opposed to Point Lights?

[![enter image description here](https://i.sstatic.net/KKjbF.jpg)](https://i.sstatic.net/KKjbF.jpg)

**Tags:** rendering, raytracing, physically-based, area

> **Comments:**
> **username_1**: Just checking... this is ray tracing right, not path tracing?  
> **username_0**: I meant to say Path Tracing, will change the title.  

---

## 1 answers

### Answer by username_1 on 2016-12-02. Score: 9 | Accepted answer

I'm going to provide the simple/naive/brute force answer to this question, which does work, and gives accurate results.

There are better answers however, which make the rendering converge faster with fewer samples, but uses more advanced math. I'm hoping someone else will provide an answer along those lines.

The simple answer is this:
Area lights are just geometry which have an emissive value.

To add support for emissive values to path tracing is pretty easy luckily.

As you know, the amount of light heading towards a pixel is the amount of light leaving the surface that a ray down that pixel would intersect.

That is calculated recursively by seeing how much light is hitting that point, integrating the BRDF, multiplying by the cosine and all that jazz.

Emissive lighting is just added to that result. So, whatever you have now as "outgoing light" from a surface, just add to it the emissive color of that surface. (You could also optionally do something similar to texture mapping and have emissive values vary over the object, possibly based on a texture).

That's all there is to it, it's very simple and easy.

In the rendering equation below, $L\_e(\omega\_o)$ represents the emissive term (that's what the e stands for, emissive), and the rest of the equation is the light integrated over the hemisphere. You can see that you just add the emissive to the result you return as your outgoing light from a point ($L\_o( \omega\_o)$) to apply that emissive lighting.

$L\_o( \omega\_o)= L\_e(\omega\_o)+\int\_{\Omega}{f(\omega\_i, \omega\_o)L\_i(\omega\_i)(\omega\_i \cdot n)\mathrm{d}\omega\_i}$

You can read more about a simple path tracer with area lights at this link, which also has commented C++ source code.

<http://blog.demofox.org/2016/09/21/path-tracing-getting-started-with-diffuse-and-emissive/>

[![enter image description here](https://i.sstatic.net/8miKf.png)](https://i.sstatic.net/8miKf.png)

> **Comments:**
> **username_0**: Great Answer this really clarified everything, although I'm going off topic a little would you know of any good resources on how to implement depth of field?  
> **username_1**: No sorry, but I am interested too. Ask another question IMO!  
> **username_0**: How do I calculate the light direction for use in a Ray Tracer to first calculate the Direct Lighting though? Do I even need to do that? I am little confused here.  
> **username_1**: You don't need to do that, no.  You just shoot random rays in the hemisphere, and some of them will hit the light, some of them won't.  There are techniques to shoot rays at the lights more directly while still accounting for the probability of you having chosen them randomly (to make the image look the same), but it's not required, no.  
> **username_0**: I'm still really confused (I'm sorry), but wouldn't this only work for Indirect lighting and not Direct Lighting? Could you add some code to your answer to illustrate this clearer? I looked at the source for path tracer in the blog post on GitHub but I couldn't understand what was going on.  
> **username_0**: Also, does this mean I can remove the direct lighting raytracer component from my Renderer entirely since the path tracer can handle this?  
> **username_1**: The light leaving a surface in a specific direction is made up of two components: One is the $L_e$ term which is the emissive light, or how much the object glows.  That is the direct lighting. The other component is the rest of the integration, which is how much light is reflected from other lighting sources (direct and indirect lighting sources), this is indirect lighting.  Those two components are added together as light leaving the surface.  Path tracing as I described finds them both because they are treated the same (they are summed and treated as "lighting" not direct or indirect).  
> **username_1**: Yes, you can remove the direct lighting code from your path tracer if you want to.  You will still get accurate results.  However, as I explained from the first couple sentences of the answer, it will take longer to make a good looking image if you do so.  It takes more complex math to have "direct lighting" in your path tracer, and have the results come out correctly, but it does speed things up to have that. You get better results in fewer samples.  But yeah, "direct lighting" code is totally optional, and path tracing works fine without it.  

---

