Converting area to solid angle.

473 views
Skip to first unread message

renderdan

unread,
Dec 16, 2010, 6:51:41 AM12/16/10
to pbrt
Hi,
In /src/core/shape.cpp there is the following code:

// Convert light sample weight to solid angle measure
float pdf = DistanceSquared(p, ray(thit)) /
(AbsDot(dgLight.nn, -wi) * Area());


From looking at various documentation this appears to be the wrong way
up ?
Shouldn't it be ( AbsDot() * Area / r^2 ) ??

Thanks,
Dan

kr...@polarlights.net

unread,
Dec 16, 2010, 8:15:38 AM12/16/10
to pb...@googlegroups.com
Hi,

I'm currently looking at the way the matte metal have been implemented in PBRT but I don't understand. What I talk about is the method CreateMetalMaterial.

Mainly, I would like to know what the following line is doing ?

Spectrum::FromSampled(CopperWavelengths, CopperN, CopperSamples);

By example, copperN and copperK are statics ! So why do we need all theses stuffs to just have some constants ? (If they are constants) ?

Thx for you help

Matt Pharr

unread,
Dec 19, 2010, 12:46:11 PM12/19/10
to pb...@googlegroups.com
It goes through that step because the computation done by FromSampled() depends on the spectral representation in the Spectrum class. So if you use sampled spectra rather than RGB, or implement a new spectrum type, then different values will be computed in resampling the sampled copper data into the actual spectral representation being used.

Thanks,
-matt

> --
> You received this message because you are subscribed to the Google Groups "pbrt" group.
> To post to this group, send email to pb...@googlegroups.com.
> To unsubscribe from this group, send email to pbrt+uns...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pbrt?hl=en.
>

Matt Pharr

unread,
Dec 19, 2010, 12:54:56 PM12/19/10
to pb...@googlegroups.com
I agree that this can be a little tricky, but that code is correct.

Check out the "Transforming Between Distributions" section (p. 660 in 2nd edition) for the background theory. That in conjunction with the relationship between solid angle and surface area measures from "Integrals Over Area" on p292 of the second edition should make it more clear. (If not, then ask again!) (That stuff is also covered in corresponding parts of the first edition, but I don't have the page #s handy.)

Thanks,
-matt

renderdan

unread,
Jan 7, 2011, 9:34:05 AM1/7/11
to pbrt
I guess the thing i'm struggling to understand is that it looks as
though for a constant area ( btw, is it constant light sample area, or
is it ray differential area ? I don't have the code to hand just now )
then as a light source moves further away, its sample PDFs go sky high
( r^2 ) and quickly overpower the PDF weights from the brdf which
messes the MIS power heuristic up. Although I can see from rendering
with pbrt this isn't a problem, but i'm trying to understand why my
own implementation isn't behaving in the same way.
Thanks again for your help,
Dan.

On Dec 19 2010, 5:54 pm, Matt Pharr <matt.ph...@gmail.com> wrote:
> I agree that this can be a little tricky, but that code is correct.
>
> Check out the "Transforming Between Distributions" section (p. 660 in 2nd edition) for the background theory.  That in conjunction with the relationship between solid angle and surface area measures from "Integrals Over Area" on p292 of the second edition should make it more clear.  (If not, then ask again!)  (That stuff is also covered in corresponding parts of the first edition, but I don't have the page #s handy.)
>
> Thanks,
> -matt
>
> On Dec 16, 2010, at 3:51 AM, renderdan wrote:
>
>
>
> > Hi,
> > In /src/core/shape.cpp there is the following code:
>
> >    // Convertlightsample weight to solid angle measure
> >    floatpdf= DistanceSquared(p, ray(thit)) /
> >                (AbsDot(dgLight.nn, -wi) * Area());
>
> > From looking at various documentation this appears to be the wrong way
> > up ?
> > Shouldn't it be ( AbsDot() * Area / r^2 ) ??
>
> > Thanks,
> > Dan
>
> > --
> > You received this message because you are subscribed to the Google Groups "pbrt" group.
> > To post to this group, send email to pb...@googlegroups.com.
> > To unsubscribe from this group, send email to pbrt+uns...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/pbrt?hl=en.- Hide quoted text -
>
> - Show quoted text -

Matt Pharr

unread,
Jan 13, 2011, 11:59:14 AM1/13/11
to pb...@googlegroups.com

On Jan 7, 2011, at 6:34 AM, renderdan wrote:

> I guess the thing i'm struggling to understand is that it looks as
> though for a constant area ( btw, is it constant light sample area, or
> is it ray differential area ? I don't have the code to hand just now )
> then as a light source moves further away, its sample PDFs go sky high
> ( r^2 )

This part is correct; basically, as the light moves farther away, it subtends a smaller part of the hemisphere around that point. Its PDF (with respect to solid angle over the hemisphere) therefore has to become larger so that it is still normalized--i.e. when you integrate the PDF over the hemisphere, it should be a constant--as the light gets smaller, more of the hemisphere has a zero PDF for sampling the light since the light isn't visible at all in those directions, so the PDF in the remaining part of the hemisphere has to get larger to compensate.

The 1/cos theta stuff is there for similar reasons; as the light tilts toward being more oblique as seen by the point, less of the hemisphere is covered by the light -> the PDF has to get bigger to compensate.

> and quickly overpower the PDF weights from the brdf which
> messes the MIS power heuristic up.

Remember that the MIS estimator is written as w(x) f(x) / p(x), where w(x) is the MIS weight, p(x) is the PDF, and f(x) is the function being integrated. The intuition is that although w(x) gets big, the 1/p(x) term cancels out that effect. (It's worthwhile to do the thought exercise to work through what happens to w(x) and p(x) (and the w(x)/p(x) term) under various scenarios of p(x) being a good fit to the integrand, p(x) being a poor fit but another sampling strategy being a good fit, etc...

-matt

renderdan

unread,
Jan 19, 2011, 3:56:59 AM1/19/11
to pbrt
Ah, I understand now ( I think! ). In the "mis" scene, there are two
spheres, but in my test case, I have samples on a plane as my area
light.
But I can see now that the Sphere's Pdf is done using the
UniformConePdf, which also causes the Pdf to increase as the light
recedes into the distance ( due to the cone angle Theta decreasing in
the 1 / (1 - cosThetaMax) term ).

Thanks for all your help.
Dan
> >>> For more options, visit this group athttp://groups.google.com/group/pbrt?hl=en.-Hide quoted text -
Reply all
Reply to author
Forward
0 new messages