## aqsis-development

 Re: [Aqsis-development] point based occlusion/color bleeding From: Chris Foster - 2010-05-18 07:00:31 ```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 wrote: > I started off by taking the formula in section 14.2 on this page: > http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter14.html 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: http://graphics.pixar.com/library/PointBasedColorBleeding/paper.pdf 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 aqsis. 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 solid angle. 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 micropolygon area. > 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 chat.aqsis.org. Cheers, ~Chris ```