<h2>1</h2>
<p>For each texel of the generated diffuse cube map (which has <span class="math-container">$6$</span> faces times <span class="math-container">$32 \times 32$</span> texels), the diffuse equation combines all texels of the environment map (which has <span class="math-container">$6$</span> faces times <span class="math-container">$64 \times 64$</span> texels). Thus <span class="math-container">$32 \times 32 \times 6 \times 64 \times 64 \times 6$</span> as stated.</p>
<p>Since the article considers SH with <span class="math-container">$9$</span> coefficients, and each coefficient needs to combine all texels of the environment map, that's <span class="math-container">$9 \times 64 \times 64 \times 6$</span>.</p>
<h2>2</h2>
<p><em>&quot;Bruteforce&quot;</em> doesn't necessarily refer to graph theory. In this article it refers to the naive approach of going through every single texel of the diffuse map and each time combine every single texel of the environment map.</p>
<hr />
<h3>Appendix</h3>
<p>Let's describe the problem at hand.</p>
<p><strong>As an input</strong>, we have an environment map: it's a set of six textures forming a cube, that represents the light coming from all directions. The light is assumed to be coming from sources far enough that, at our scale, it's as if they were infinitely far. An environment map typically looks like the left figure of this illustration from the GPU Gems article:</p>
<p><a href="https://i.sstatic.net/ZFIHb.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ZFIHb.jpg" alt="Environment map and diffuse irradiance" /></a></p>
<p><strong>As an output</strong>, for a any point of a given object that we're rendering, we want to know the diffuse irradiance affecting it. <em>What does that mean?</em></p>
<h3>A parenthesis</h3>
<p>Models describing how the perceived color of a surface varies depending the light reaching it, typically consist in <a href="https://en.wikipedia.org/wiki/Rendering_equation" rel="nofollow noreferrer">integrating all incoming light over an hemisphere</a>, with a weight that depends both on the direction of the light and of the observer.</p>
<p>For opaque materials, it is common to consider two components contributing to that color: the diffuse and the specular. The diffuse is due to light slightly penetrating the surface, getting partly absorbed, then getting out in random directions. The specular is due to light bouncing off the surface without entering it.</p>
<p><a href="https://i.sstatic.net/85Pmg.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/85Pmg.png" alt="Diffuse and specular reflections" /></a></p>
<h3>Back to the problem</h3>
<p>So we want to know the color of the points of an object, we know that to compute it we need to integrate light in all directions, and we have a cube map that represents light coming from all directions. So far so good.</p>
<p>A problem though is <em>integrating</em> basically means we need to go over every single texel of the hemisphere (so half the environment map: <span class="math-container">$(64 \times 64 \times 6) / 2$</span> texels), do some math, and add that to the result. That's a lot of computation for each point, which we'd like to avoid if possible.</p>
<p>We know that the contribution of one light depends on the light direction. If we consider the environment to be static (the lighting doesn't change), then we can isolate the part of the computation that only depends on the light and surface normal (and not on the material or the observer), pre-compute it and store it to use later. For the diffuse term, that's the <em>diffuse irradiance</em> mentioned earlier, and it typically looks like the center figure of the illustration. Each pixel represents the irradiance term for a given surface normal. The right figure is the specular environment map, computed in a similar way but with a different integral.</p>
<p><a href="https://i.sstatic.net/ZFIHb.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ZFIHb.jpg" alt="Environment map and diffuse irradiance" /></a></p>
<p>With that texture, instead of painfully integrating, we just fetch the precomputed result, combine it with the rest of the equation (the material diffuse color, etc.) and voilà.</p>
<h3>Finding the 32x32x6x64x64x6</h3>
<p>Since the result looks very blurry, it probably doesn't need to be <span class="math-container">$64 \times 64$</span> for storing, and the article assumes <span class="math-container">$32 \times 32$</span>. But still, each of those <span class="math-container">$32 \times 32 \times 6$</span> texels' color is computed separately, by integrating over the entire corresponding hemisphere. That part never disappeared: we just moved it from the rendering stage to a pre-computation stage.</p>
<p>So that's still <span class="math-container">$(32 \times 32 \times 6) \times (64 \times 64 \times 6) / 2$</span>. That's half the figure stated in the article. I suppose the author was either assuming a model that integrates of the entire sphere, or just dropped the <span class="math-container">$0.5$</span> factor for the sake of clarity.</p>
<h3>Finding the 9x64x64x6</h3>
<p>We can't help but notice this irradiance diffuse environment map is really blurry: surely there must be a way to store its information using a lot less than <span class="math-container">$32 \times 32 \times 6$</span> terms, and hopefully reduce the amount of work as well. That's what <a href="https://en.wikipedia.org/wiki/Spherical_harmonics" rel="nofollow noreferrer">spherical harmonics</a> do, by compressing the irradiance in just a few coefficients.</p>
<p>I am not familiar enough with the math to engage in an explanation, but suffice to say it is generally considered that for diffuse, order three SH are sufficient. Order three SH involve nine coefficient, and again, for each of these we need to integrate over the entire hemisphere.</p>
<p>So that's <span class="math-container">$(9 \times 64 \times 64 \times 6) / 2$</span> texels to fetch and process. Here too a <span class="math-container">$2$</span> factor is missing from the article.</p>

CC BY-SA 3.0
2016-09-26T08:56:04.340Z
Thanks for your guides. for generate a cube map with 32x32x6, we only use 32x32x6 texels from 64x64x6 ( i mean we only compute 32x32x6 texels), so why we have to multiply 32x32x6 to 64x64x6 again ? (i think my question would be answered if i understand why diffuse equation combines all texels of the environment maps. and also i can't understand the relation of diffuse equation and cube map). since i have learned computer graphics by myself, some stupid questions arise when i'm facing to bigger problems. sorry about that :D
Joe
CC BY-SA 3.0
2016-09-26T04:28:05.190Z
2016-09-26T12:58:48.857Z
2020-06-18T08:32:12.800Z
Julien Guertault
<p>I have read about spherical harmonics from <a href="http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter10.html">Here</a> about the usage of SH for generating Irradiance Environment Maps and how it can make the process of generating EM faster than the regular operations. what they say is : </p>

<p>"<em>if we want to generate a diffuse cube map with an edge length of just 32 texels, from an input cube map with an edge length of 64 texels, the cost is 32x32x6x64x64x6 around 151 million operations. real-time generation of irradiance environment maps cannot be achieved using such a brute-force algorithm. 
the runtime complexity for Spherical harmonics method in the example is just 9 x 64 x 64 x 6 around thousand operations per function</em>"</p>

<p>my questions are :</p>

<ol>
<li><p>how the cost of generating cube map with the edge length of 32 texels from a 64 one has been calculated as 32x32x6x64x64x6 and why not 32x32x6+64*64*6? and why for SH, the cost of generating is 9x64x64x6 ?</p></li>
<li><p>brute-force algorithm finds the shortest path from one node to another. how this algorithm used for that cubemap generation ?</p></li>
</ol>

<uv-mapping><mapping>
The Process of Spherical Harmonics
Joe
# The Process of Spherical Harmonics

(Asked by: username_0 on 2016-09-25)

I have read about spherical harmonics from [Here](http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter10.html) about the usage of SH for generating Irradiance Environment Maps and how it can make the process of generating EM faster than the regular operations. what they say is :

"*if we want to generate a diffuse cube map with an edge length of just 32 texels, from an input cube map with an edge length of 64 texels, the cost is 32x32x6x64x64x6 around 151 million operations. real-time generation of irradiance environment maps cannot be achieved using such a brute-force algorithm.
the runtime complexity for Spherical harmonics method in the example is just 9 x 64 x 64 x 6 around thousand operations per function*"

my questions are :

1. how the cost of generating cube map with the edge length of 32 texels from a 64 one has been calculated as 32x32x6x64x64x6 and why not 32x32x6+64\*64\*6? and why for SH, the cost of generating is 9x64x64x6 ?
2. brute-force algorithm finds the shortest path from one node to another. how this algorithm used for that cubemap generation ?

**Tags:** uv-mapping, mapping


---

## 1 answers

### Answer by username_1 on 2016-09-26. Score: 6 | Accepted answer

## 1

For each texel of the generated diffuse cube map (which has $6$ faces times $32 \times 32$ texels), the diffuse equation combines all texels of the environment map (which has $6$ faces times $64 \times 64$ texels). Thus $32 \times 32 \times 6 \times 64 \times 64 \times 6$ as stated.

Since the article considers SH with $9$ coefficients, and each coefficient needs to combine all texels of the environment map, that's $9 \times 64 \times 64 \times 6$.

## 2

*"Bruteforce"* doesn't necessarily refer to graph theory. In this article it refers to the naive approach of going through every single texel of the diffuse map and each time combine every single texel of the environment map.

---

### Appendix

Let's describe the problem at hand.

**As an input**, we have an environment map: it's a set of six textures forming a cube, that represents the light coming from all directions. The light is assumed to be coming from sources far enough that, at our scale, it's as if they were infinitely far. An environment map typically looks like the left figure of this illustration from the GPU Gems article:

[![Environment map and diffuse irradiance](https://i.sstatic.net/ZFIHb.jpg)](https://i.sstatic.net/ZFIHb.jpg)

**As an output**, for a any point of a given object that we're rendering, we want to know the diffuse irradiance affecting it. *What does that mean?*

### A parenthesis

Models describing how the perceived color of a surface varies depending the light reaching it, typically consist in [integrating all incoming light over an hemisphere](https://en.wikipedia.org/wiki/Rendering_equation), with a weight that depends both on the direction of the light and of the observer.

For opaque materials, it is common to consider two components contributing to that color: the diffuse and the specular. The diffuse is due to light slightly penetrating the surface, getting partly absorbed, then getting out in random directions. The specular is due to light bouncing off the surface without entering it.

[![Diffuse and specular reflections](https://i.sstatic.net/85Pmg.png)](https://i.sstatic.net/85Pmg.png)

### Back to the problem

So we want to know the color of the points of an object, we know that to compute it we need to integrate light in all directions, and we have a cube map that represents light coming from all directions. So far so good.

A problem though is *integrating* basically means we need to go over every single texel of the hemisphere (so half the environment map: $(64 \times 64 \times 6) / 2$ texels), do some math, and add that to the result. That's a lot of computation for each point, which we'd like to avoid if possible.

We know that the contribution of one light depends on the light direction. If we consider the environment to be static (the lighting doesn't change), then we can isolate the part of the computation that only depends on the light and surface normal (and not on the material or the observer), pre-compute it and store it to use later. For the diffuse term, that's the *diffuse irradiance* mentioned earlier, and it typically looks like the center figure of the illustration. Each pixel represents the irradiance term for a given surface normal. The right figure is the specular environment map, computed in a similar way but with a different integral.

[![Environment map and diffuse irradiance](https://i.sstatic.net/ZFIHb.jpg)](https://i.sstatic.net/ZFIHb.jpg)

With that texture, instead of painfully integrating, we just fetch the precomputed result, combine it with the rest of the equation (the material diffuse color, etc.) and voilà.

### Finding the 32x32x6x64x64x6

Since the result looks very blurry, it probably doesn't need to be $64 \times 64$ for storing, and the article assumes $32 \times 32$. But still, each of those $32 \times 32 \times 6$ texels' color is computed separately, by integrating over the entire corresponding hemisphere. That part never disappeared: we just moved it from the rendering stage to a pre-computation stage.

So that's still $(32 \times 32 \times 6) \times (64 \times 64 \times 6) / 2$. That's half the figure stated in the article. I suppose the author was either assuming a model that integrates of the entire sphere, or just dropped the $0.5$ factor for the sake of clarity.

### Finding the 9x64x64x6

We can't help but notice this irradiance diffuse environment map is really blurry: surely there must be a way to store its information using a lot less than $32 \times 32 \times 6$ terms, and hopefully reduce the amount of work as well. That's what [spherical harmonics](https://en.wikipedia.org/wiki/Spherical_harmonics) do, by compressing the irradiance in just a few coefficients.

I am not familiar enough with the math to engage in an explanation, but suffice to say it is generally considered that for diffuse, order three SH are sufficient. Order three SH involve nine coefficient, and again, for each of these we need to integrate over the entire hemisphere.

So that's $(9 \times 64 \times 64 \times 6) / 2$ texels to fetch and process. Here too a $2$ factor is missing from the article.

> **Comments:**
> **username_0**: Thanks for your guides. for generate a cube map with 32x32x6, we only use 32x32x6 texels from 64x64x6 ( i mean we only compute 32x32x6 texels), so why we have to multiply 32x32x6 to 64x64x6 again ? (i think my question would be answered if i understand why diffuse equation combines all texels of the environment maps. and also i can't understand the relation of diffuse equation and cube map). since i have learned computer graphics by myself, some stupid questions arise when i'm facing to bigger problems. sorry about that :D  

---

