AreaLight sampling PDF

[Volodymyr Kachurovskyi]

I think the PDF for the AreaLight is computed incorrectly.
AreaLight::Pdf() calls Shape::Pdf() method which in turn calls virtual
Shape::Intersect() method. For area lights this method finds the
intersection with any of the shapes from the ShapeSet. I think it
should find *ALL* intersections and compute the aggregated PDF value
for all of them. This is so because when Sampling the area light the
sample can be generated on any of those intersected shapes thus the
true PDF value would be greater than the one returned by the method.
In other words, if we integrate the PDF returned by the ShapeSet it
will not always sum up to one.
Please let me know if I missed something...

[Volodymyr Kachurovskyi]

Any response?
I have revisited the work-around approach I suggested above, but the
way it is currently done in pbrt seems to be incorrect anyway.
A simple example is a triangulated sphere with area light emission
properties.

On Sep 30, 8:05 pm, Volodymyr Kachurovskyi

[Matt Pharr]

You are right, there was a bug there--nice find! The fix that made the most sense ended up being that after ShapeSet::Sample() lets one of the shapes choose a sample point to then find the closest intersection along that ray from the point being lit with all of the shapes; if there is a closer one, then to use that one instead as the emission point.

The rough logic being that during sampling, the shapes are collectively defining a sampling distribution on the (hemi)sphere; although they sample points on their surfaces, in the end, this is just a route to choosing directions. As such, it's wrong to just assume that the originally sampled point is the one to check and see if it's illuminating the point being shaded, but that instead the sampled direction should be converted back again to a point on the light source to get the illumination point.

FWIW I used the scene file below to test it: it has a small stack of triangle light sources almost on top of each other. In the old implementation, as one added more such triangles in a single Shape call, the scene would get darker (it should have basically stayed the same brightness).

Thanks,
-matt



LookAt 0 8 -8 0 0 .5 0 1 0

Film "image" "integer xresolution" 300 "integer yresolution" 300

Sampler "lowdiscrepancy" "integer pixelsamples" [4]
Camera "perspective"

WorldBegin

AttributeBegin
AreaLightSource "diffuse" "color L" [10 10 10] "integer nsamples" [8]
Translate 2 5 0
#Shape "trianglemesh" "integer indices" [ 0 1 2 ]
# "point P" [ 0 0 0 4 0 0 0 0 10 ]
#Shape "trianglemesh" "integer indices" [ 0 1 2 ]
# "point P" [ 0 .1 0 4 .1 0 0 .1 10]
#Shape "trianglemesh" "integer indices" [ 0 1 2 ]
# "point P" [ 0 .2 0 4 .2 0 0 .2 10]
Shape "trianglemesh" "integer indices" [ 0 1 2 3 4 5 6 7 8 ]
"point P" [ 0 0 0 4 0 0 0 0 10 0 .1 0 4 .1 0 0 .1 10
0 .2 0 4 .2 0 0 .2 10]
AttributeEnd

Material "matte"
Shape "trianglemesh" "integer indices" [ 0 1 2 ]
"point P" [ 0 2 0 4 -1 0 0 -1 10]


Material "matte"
Shape "trianglemesh" "integer indices" [ 0 1 2 ]
"point P" [ -100 -1 -100 100 -1 -100 0 -1 100]

WorldEnd

> --~--~---------~--~----~------------~-------~--~----~
> 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
> -~----------~----~----~----~------~----~------~--~---
>

[Volodymyr Kachurovskyi]

Thank you for the response!

I have been thinking about this issue for quite a while and I just
wonder whether you use correct PDF for the power heuristic when you
sample BSDF.
When you sample area light which is a (for example) triangulated
sphere you have exactly two points on the surface corresponding to the
same light direction. If you always use the closest one you as the
emission point than the PDF for the sampled direction should still be
computed based on *both* intersection points.

[Matt Pharr]

I think it currently does that, though--

float ShapeSet::Pdf(const Point &p, const Vector &wi) const {
float pdf = 0.f;
for (uint32_t i = 0; i < shapes.size(); ++i)
pdf += areas[i] * shapes[i]->Pdf(p, wi);
return pdf / sumArea;
}

Is that what you mean, or am I missing something somewhere along the way?

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

[Volodymyr Kachurovskyi]

Yes, I think this should work.
I did not know this part was already changed in pbrt 2.0