Hey Warren, nice to hear from you again,
I'm cc'ing this mail to the mailing list, since I generally find it a good
place for in depth discussion, hope you don't mind.
On Tue, May 18, 2010 at 2:19 PM, Warren Baltz <warrenbaltz@...> wrote:
> I started off by taking the formula in section 14.2 on this page:
I assume you mean the equation 14-1, Shadow Approximation?
> But I'm not getting good results. I'm getting numbers in the 30's and 40's
> and I'm expecting numbers between zero and 1.
Ah, which numbers are these? Numbers for the amount of occlusion at a point?
While the GPU gems 2 method is simple, I'd strongly encourage you to look at
the Christensen paper if you haven't already:
In this paper they move away from the vague heuristic approximations made in
the GPU gems work, and instead render a point-based representation of the
scene into microbuffers for each pixel. I think this idea has much more
potential for high quality graphics of the type we'd like to implement in
If you think that's too complicated, we'd still be happy to have the lower
quality method implemented, but IMHO it's much less compelling with all the
approximations they make ;-) There's also a bunch of parameters that need
fine tuning on a scene by scene basis which can be thrown out if this is done
with a microbuffer type approach.
> I think this equation was derived integrating over the area of a disk
> combined with the lambertian contribution to the receiver from the points on
> the disk.
Sounds very reasonable. They admit that there's an approximation in there
though. It looks like what they've done is computed the solid angle of the
disk, and then weighted it with something like the lambertian contribution
coming from the centre of the disk. I really don't understand that factor of
4 though in the max(1, 4*cos(theta_R)).
> But I'm out of practice enough that I can't rederive it to see where I'm
> going wrong. Do you have any ideas?
Hmm, the equation doesn't make much sense to me either. For instance, if you
consider the limit when r becomes large, the second term becomes constant.
But surely you'd expect that as the emitter gets further away the solid angle
becomes smaller and smaller, and the effect of it would be less? Odd.
Here's a suggestion, not sure if it'll work, but it's something to start with:
Since everything is represented by *micro*polygons in our system, we should
generally expect that the emitter is small compared to the hemisphere of
radius r. In that case we can make a really simple approximation for the
If the emitter is small then projecting it onto the hemisphere of radius r
centered at the receiver gives a projected area of
A_proj = pi * L * L*cos(theta_E) = A*cos(theta_E)
where L and A are the radius and area of the emitter respectively. It's this
projected area that the receiver sees. The total area of the hemisphere is
A_H = 2 * pi * r^2
so the fractional area of the hemisphere taken up by the emitter is just
f = A_proj/A_H = A*cos(theta_E) / 2*pi*r^2
(The fractional area is proportional to the solid angle.) Now, add in the
lambertian, and you get the amount of occlusion at the receiver
occ = f * cos(theta_R)/2*pi
2*pi is the integral of cos(theta_R) over the hemisphere, I think.
Assuming that we only have this single disk, we end up with the light
intensity at the receiver:
intens = 1 - occ = 1 - A*cos(theta_E)*cos(theta_R)/(2*pi*r)^2
Note that this probably won't work that well for emitters that are really
close, but it might get us started and it tells us the asymptotic form
expected when r is large, or A small.
> By the way, I'm using area(P) in rsl to approximate the area of each disk
> during the baking phase.
Sounds reasonable. area(P) is computed as the area of the parallelogram
formed by the surface differentials at the point P. This is roughly the
> Also, sorry I didn't make it to the developer meeting on IRC. Maybe I can
> attend one in the future.
Yeah no worries, it's entirely up to you of course. If you want to see what
happens in a typical IRC meeting you can check out the meeting page from last
week, http://wiki.aqsis.org/dev/meeting/20100516. #aqsis is a logged IRC
channel anyway, so anything which goes on there can always be found at