Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (739)
Games in Android Showcase (224)
games submitted by our members
Games in WIP (820)
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 2098 times)
0 Members and 1 Guest are viewing this topic.
Offline 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"?
Offline KaiHH

JGO Kernel


Medals: 446



« 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
Offline 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 Cheesy

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 Smiley
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline KaiHH

JGO Kernel


Medals: 446



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

 
Ecumene (53 views)
2017-09-30 02:57:34

theagentd (76 views)
2017-09-26 18:23:31

cybrmynd (184 views)
2017-08-02 12:28:51

cybrmynd (182 views)
2017-08-02 12:19:43

cybrmynd (189 views)
2017-08-02 12:18:09

Sralse (198 views)
2017-07-25 17:13:48

Archive (747 views)
2017-04-27 17:45:51

buddyBro (881 views)
2017-04-05 03:38:00

CopyableCougar4 (1429 views)
2017-03-24 15:39:42

theagentd (1320 views)
2017-03-24 15:32:08
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!