Java-Gaming.org Hi !
 Featured games (90) games approved by the League of Dukes Games in Showcase (731) Games in Android Showcase (217) games submitted by our members Games in WIP (798) games currently in development
 News: Read the Java Gaming Resources, or peek at the official Java tutorials
Pages: [1]
 ignore  |  Print
 Rendering: Clearing Doubts About The Rendering Equation  (Read 519 times) 0 Members and 2 Guests are viewing this topic.
 « Posted 2017-06-12 05:01:14 »

From what I understand, the rendering equation can be considered in two ways:

1) as a double integral with respect to the horizontal and vertical angles in a hemisphere, in spherical coordinates
2) as a (single) integral where the differential is dw, a differential solid angle.

The rendering equation is recursive, because the incoming light can be thought of as the outgoing light from a different surface, thus, the rendering equation accounts for indirect illumination as well.

Due to the continuous nature of the equation, in order to solve it in realtime, one has to discretize it by breaking it up into a bunch of samples (e.g. SSAO) or by voxelizing the scene (e.g. GI with Voxel Cone Tracing).

If the (1) is true, why is it that in SSAO, the sample points are in the space within the hemisphere? Shouldn't the sample points be located at a random point on the hemisphere's "surface"?
KaiHH

JGO Kernel

Medals: 416

 « Reply #1 - Posted 2017-06-12 07:28:13 »

Quote
If the (1) is true, why is it that in SSAO, the sample points are in the space within the hemisphere? Shouldn't the sample points be located at a random point on the hemisphere's "surface"?
The hemisphere has no "surface." It is the infinitely large half-sphere above a surface point P. The meaning/reason of this is that any potential source of light within this infinitely large half-sphere has potentially a contribution on the incident light of point P.

However, even Screen-Space Ambient Occlusion is such a huge approximation of the rendering equation, such that:
- Essentially SSAO is "somewhat" a local lighting model, because:
- we assume the scene is being lit by a constant "ambient" white light coming from everywhere within the local hemisphere of a given surface point P
- we break the recursiveness of the rendering equation by not taking into account the incident light of point P coming from other surfaces
 « Reply #2 - Posted 2017-06-12 10:07:52 »

Quote
If the (1) is true, why is it that in SSAO, the sample points are in the space within the hemisphere? Shouldn't the sample points be located at a random point on the hemisphere's "surface"?
The hemisphere has no "surface." It is the infinitely large half-sphere above a surface point P. The meaning/reason of this is that any potential source of light within this infinitely large half-sphere has potentially a contribution on the incident light of point P.

However, even Screen-Space Ambient Occlusion is such a huge approximation of the rendering equation, such that:
- Essentially SSAO is "somewhat" a local lighting model, because:
- we assume the scene is being lit by a constant "ambient" white light coming from everywhere within the local hemisphere of a given surface point P
- we break the recursiveness of the rendering equation by not taking into account the incident light of point P coming from other surfaces

But in the case of SSAO, since we're specifying a radius for the hemisphere so that there's sort of a bound within which the sample points can be generated, doesn't that mean the hemisphere isn't infinitely sized?

Besides, what I really don't get is, assuming that we could solve the rendering equation in its continuous form, would the size of the hemisphere really matter? Any arbitrarily-sized hemisphere would capture every possible direction of light.

Also, can you confirm that my understanding of the rendering equation (what I described in the main post before I asked the question about SSAO) is correct? Thanks
KaiHH

JGO Kernel

Medals: 416

 « Reply #3 - Posted 2017-06-12 10:23:51 »

The thing is: The rendering equation says that "I want to know the incident light coming from any direction in the hemisphere." And that is summed over all possible directions via the integral.

However, what we have to break it down to in order to actually implement it is:
"Yeah, we know that we have to get the incident light coming from that direction somehow. And if we were to do it correctly we'd have to actually shoot a ray into that direction and gather the incident light that this ray would contribute."

With SSAO however, we are not really interested in the actual incident light coming from any direction, but we are interested in the direction this light _would not come from_, since that direction is blocked somewhere by other geometry. And since we also don't want to shoot actual rays and intersect them with the geometry, we sample. So we have to just decide where we would like to sample. The simplest approach is just define _some_ distance and sample there. Another solution could be sample multiple times with some stepping interval/strategy.
 « Reply #4 - Posted 2017-06-12 10:33:16 »

The thing is: The rendering equation says that "I want to know the incident light coming from any direction in the hemisphere." And that is summed over all possible directions via the integral.

However, what we have to break it down to in order to actually implement it is:
"Yeah, we know that we have to get the incident light coming from that direction somehow. And if we were to do it correctly we'd have to actually shoot a ray into that direction and gather the incident light that this ray would contribute."

With SSAO however, we are not really interested in the actual incident light coming from any direction, but we are interested in the direction this light _would not come from_, since that direction is blocked somewhere by other geometry. And since we also don't want to shoot actual rays and intersect them with the geometry, we sample. So we have to just decide where we would like to sample. The simplest approach is just define _some_ distance and sample there. Another solution could be sample multiple times with some stepping interval/strategy.

Ahhh, I see what you mean. So the "hemisphere radius" we define is just something we do because we can't have an indefinite radius, since we need a bound for our samples, and the "hemispherically-bounded" sampling kernel in SSAO isn't the hemisphere that the rendering equation involves.

What about the first part of my main post?:
Quote
From what I understand, the rendering equation can be considered in two ways:

1) as a double integral with respect to the horizontal and vertical angles in a hemisphere, in spherical coordinates
2) as a (single) integral where the differential is dw, a differential solid angle.

The rendering equation is recursive, because the incoming light can be thought of as the outgoing light from a different surface, thus, the rendering equation accounts for indirect illumination as well.

Due to the continuous nature of the equation, in order to solve it in realtime, one has to discretize it by breaking it up into a bunch of samples (e.g. SSAO) or by voxelizing the scene (e.g. GI with Voxel Cone Tracing).

^Is my understanding of the rendering equation correct?
Pages: [1]
 ignore  |  Print

 Archive (336 views) 2017-04-27 17:45:51 buddyBro (535 views) 2017-04-05 03:38:00 CopyableCougar4 (978 views) 2017-03-24 15:39:42 theagentd (1014 views) 2017-03-24 15:32:08 Rule (993 views) 2017-03-19 12:43:22 Rule (973 views) 2017-03-19 12:42:17 Rule (971 views) 2017-03-19 12:36:21 theagentd (1071 views) 2017-03-16 05:07:07 theagentd (990 views) 2017-03-15 22:37:06 theagentd (760 views) 2017-03-15 22:32:18
 theagentd 13x orange451 13x philfrei 12x J0 10x Damocles 8x Sickan 7x Guerra2442 7x Riven 7x Coldstream24 7x Unimatrix325 7x KaiHH 7x Apo 4x 65K 4x Ecumene 4x VaTTeRGeR 4x Archive 4x
 List of Learning Resourcesby elect2017-03-13 14:05:44List of Learning Resourcesby elect2017-03-13 14:04:45SF/X Librariesby philfrei2017-03-02 08:45:19SF/X Librariesby philfrei2017-03-02 08:44:05SF/X Librariesby SkyAphid2017-03-02 06:38:56SF/X Librariesby SkyAphid2017-03-02 06:38:32SF/X Librariesby SkyAphid2017-03-02 06:38:05SF/X Librariesby SkyAphid2017-03-02 06:37:51
 java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org