Java-Gaming.org Hi !
 Featured games (90) games approved by the League of Dukes Games in Showcase (780) Games in Android Showcase (233) games submitted by our members Games in WIP (856) games currently in development
 News: Read the Java Gaming Resources, or peek at the official Java tutorials
 Home Help Search Login Register
Pages: [1]
 ignore  |  Print
 Rendering: Clearing Doubts About The Rendering Equation  (Read 5796 times) 0 Members and 1 Guest are viewing this topic.
ShadedVertex
 « 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: 654

 « 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
ShadedVertex
 « 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

Thanks for the reply

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
 Games published by our own members! Check 'em out!
KaiHH

JGO Kernel

Medals: 654

 « 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.
ShadedVertex
 « 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

 hadezbladez (695 views) 2018-11-16 13:46:03 hadezbladez (342 views) 2018-11-16 13:41:33 hadezbladez (677 views) 2018-11-16 13:35:35 hadezbladez (167 views) 2018-11-16 13:32:03 EgonOlsen (2359 views) 2018-06-10 19:43:48 EgonOlsen (2460 views) 2018-06-10 19:43:44 EgonOlsen (1461 views) 2018-06-10 19:43:20 DesertCoockie (2126 views) 2018-05-13 18:23:11 nelsongames (1888 views) 2018-04-24 18:15:36 nelsongames (2557 views) 2018-04-24 18:14:32
 Deployment and Packagingby mudlee2018-08-22 18:09:50Java Gaming Resourcesby gouessej2018-08-22 08:19:41Deployment and Packagingby gouessej2018-08-22 08:04:08Deployment and Packagingby gouessej2018-08-22 08:03:45Deployment and Packagingby philfrei2018-08-20 02:33:38Deployment and Packagingby philfrei2018-08-20 02:29:55Deployment and Packagingby philfrei2018-08-19 23:56:20Deployment and Packagingby philfrei2018-08-19 23:54:46
 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