Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Ben Yeoh <shuttlecork@gm...>  20091110 08:58:20
Attachments:
Message as HTML

Has anyone implemented SH exponentiation AND managed to approximate the optimal linear (OL) values for 2 or more sphere occluders? The SH paper briefly mentioned/implied that the authors managed to fit the OL approximation to multiple spheres, which still has some artifacts with inaccurate/lighter occlusion, but is still preferable to the single sphere approximation when dealing with multiple sphere occluders, which is common in most "practical" cases. If anyone has some idea how the fitting to multiple spheres thing is done  that'll be awesome. 
From: Ben Yeoh <shuttlecork@gm...>  20091110 08:58:20
Attachments:
Message as HTML

Has anyone implemented SH exponentiation AND managed to approximate the optimal linear (OL) values for 2 or more sphere occluders? The SH paper briefly mentioned/implied that the authors managed to fit the OL approximation to multiple spheres, which still has some artifacts with inaccurate/lighter occlusion, but is still preferable to the single sphere approximation when dealing with multiple sphere occluders, which is common in most "practical" cases. If anyone has some idea how the fitting to multiple spheres thing is done  that'll be awesome. 
From: PeterPike Sloan <peter_pike_sloan@ho...>  20091110 18:30:12
Attachments:
Message as HTML

I'm not really sure what you are talking about. You might want to email John directly, I think we just computed a bunch of pairs and then built the table as a function of log magnitude (after DC isolation.) You could pose computing the ab texture itself as a least squares problem, and include training examples that were the result of multiple spheres (instead of just single spheres), but I don't think we did that... Are you referring to figure 3 in the paper? It is really just showing the OL pretty much just works as long as the magnitude is small enough... PeterPike Sloan Date: Tue, 10 Nov 2009 16:58:04 +0800 From: shuttlecork@... To: gdalgorithmslist@... Subject: [Algorithms] More SH exponentiation questions Has anyone implemented SH exponentiation AND managed to approximate the optimal linear (OL) values for 2 or more sphere occluders? The SH paper briefly mentioned/implied that the authors managed to fit the OL approximation to multiple spheres, which still has some artifacts with inaccurate/lighter occlusion, but is still preferable to the single sphere approximation when dealing with multiple sphere occluders, which is common in most "practical" cases. If anyone has some idea how the fitting to multiple spheres thing is done  that'll be awesome. 
From: Ben Yeoh <shuttlecork@gm...>  20091111 04:04:24
Attachments:
Message as HTML

Hi Peter, Thanks for chiming in! Okay, let me elaborate a bit. Basically, I'm trying to avoid doing any factorization to reduce the log magnitude (besides DC isolation) in the pixel shader for performance reasons. It still looks prohibitively expensive even with 3rd order SHs and John's code generator. I was hoping that the artifacts arising with just the OL approach with overlapping sphere occluders would be similar to what is shown in the bunny example in Figure 9 in the paper, which looks to me like fainter shadows. I think I'm willing to live with that if that's the case... So the pure OL approach (fit to a single sphere) with 1 sphere occluder in the scene works fine. But when I have multiple overlapping spheres though as in the bunny example, there's some pretty objectionable "shadow saturation"/ringing artifacts when those overlapping spheres are "close" to the receiver. In fact, it looks very different compared to the Figure 9 example. I'm guessing that's because the OL approximation in Figure 9 was fit to multiple spheres (ie, 63 spheres for the bunny?), wheares I was only fitting to a single sphere. Am I right to assume this? Now, going along this line, I've tried a couple of things to "fit" the AB table to multiple sphere occluders (which didn't work) : 1. Multiply the log visibility coeffs by 2 (for 2 sphere occluders) and use that to find AB instead. 2. Do a triple product on the sphere visibility coeffs (ie, F * F) and use that to find the log and AB. On Wed, Nov 11, 2009 at 2:29 AM, PeterPike Sloan < peter_pike_sloan@...> wrote: > > I'm not really sure what you are talking about. You might want to email > John directly, I think we just computed a bunch of pairs and then built the > table as a function of log magnitude (after DC isolation.) > > You could pose computing the ab texture itself as a least squares problem, > and include training examples that were the result of multiple spheres > (instead of just single spheres), but I don't think we did that... > > Are you referring to figure 3 in the paper? It is really just showing the > OL pretty much just works as long as the magnitude is small enough... > > PeterPike Sloan > >  > Date: Tue, 10 Nov 2009 16:58:04 +0800 > From: shuttlecork@... > To: gdalgorithmslist@... > Subject: [Algorithms] More SH exponentiation questions > > Has anyone implemented SH exponentiation AND managed to approximate the > optimal linear (OL) values for 2 or more sphere occluders? > > The SH paper briefly mentioned/implied that the authors managed to fit the > OL approximation to multiple spheres, which still has some artifacts with > inaccurate/lighter occlusion, but is still preferable to the single sphere > approximation when dealing with multiple sphere occluders, which is common > in most "practical" cases. > > If anyone has some idea how the fitting to multiple spheres thing is done  > that'll be awesome. > > > >  > Let Crystal Reports handle the reporting  Free Crystal Reports 2008 30Day > trial. Simplify your report design, integration and deployment  and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobjjuly > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist > 
From: Ben Yeoh <shuttlecork@gm...>  20091111 04:26:26
Attachments:
Message as HTML

Sorry, hit enter a bit prematurely. Regarding Figure 3, I wanted to also ask how the values for AB were derived for multiple overlapping spheres. It's basically what I'm trying to accomplish... On Wed, Nov 11, 2009 at 12:04 PM, Ben Yeoh <shuttlecork@...> wrote: > Hi Peter, > > Thanks for chiming in! > > Okay, let me elaborate a bit. > > Basically, I'm trying to avoid doing any factorization to reduce the log > magnitude (besides DC isolation) in the pixel shader for performance > reasons. It still looks prohibitively expensive even with 3rd order SHs and > John's code generator. I was hoping that the artifacts arising with just the > OL approach with overlapping sphere occluders would be similar to what is > shown in the bunny example in Figure 9 in the paper, which looks to me like > fainter shadows. I think I'm willing to live with that if that's the case... > > So the pure OL approach (fit to a single sphere) with 1 sphere occluder in > the scene works fine. But when I have multiple overlapping spheres though as > in the bunny example, there's some pretty objectionable "shadow > saturation"/ringing artifacts when those overlapping spheres are "close" to > the receiver. In fact, it looks very different compared to the Figure 9 > example. I'm guessing that's because the OL approximation in Figure 9 was > fit to multiple spheres (ie, 63 spheres for the bunny?), wheares I was only > fitting to a single sphere. Am I right to assume this? > > Now, going along this line, I've tried a couple of things to "fit" the AB > table to multiple sphere occluders (which didn't work) : > > 1. Multiply the log visibility coeffs by 2 (for 2 sphere occluders) and use > that to find AB instead. > > 2. Do a triple product on the sphere visibility coeffs (ie, F * F) and use > that to find the log and AB. > > > > > > > > On Wed, Nov 11, 2009 at 2:29 AM, PeterPike Sloan < > peter_pike_sloan@...> wrote: > >> >> I'm not really sure what you are talking about. You might want to email >> John directly, I think we just computed a bunch of pairs and then built the >> table as a function of log magnitude (after DC isolation.) >> >> You could pose computing the ab texture itself as a least squares problem, >> and include training examples that were the result of multiple spheres >> (instead of just single spheres), but I don't think we did that... >> >> Are you referring to figure 3 in the paper? It is really just showing the >> OL pretty much just works as long as the magnitude is small enough... >> >> PeterPike Sloan >> >>  >> Date: Tue, 10 Nov 2009 16:58:04 +0800 >> From: shuttlecork@... >> To: gdalgorithmslist@... >> Subject: [Algorithms] More SH exponentiation questions >> >> Has anyone implemented SH exponentiation AND managed to approximate the >> optimal linear (OL) values for 2 or more sphere occluders? >> >> The SH paper briefly mentioned/implied that the authors managed to fit the >> OL approximation to multiple spheres, which still has some artifacts with >> inaccurate/lighter occlusion, but is still preferable to the single sphere >> approximation when dealing with multiple sphere occluders, which is common >> in most "practical" cases. >> >> If anyone has some idea how the fitting to multiple spheres thing is done >>  that'll be awesome. >> >> >> >>  >> Let Crystal Reports handle the reporting  Free Crystal Reports 2008 >> 30Day >> trial. Simplify your report design, integration and deployment  and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobjjuly >> _______________________________________________ >> GDAlgorithmslist mailing list >> GDAlgorithmslist@... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist >> > > 
From: Ben Yeoh <shuttlecork@gm...>  20091111 14:05:16
Attachments:
Message as HTML

Okay. Figured out the issue. PIX saved me on this one. So multiplying the log visibility coefficients by N amount of spheres and fitting it to the single sphere case to derive the AB table actually does work. And all this time I'm wondering why it didn't. Turns out that I was also stupidly storing the postmultiplied log coefficients in the sphere visibility lookup table instead of the original log values... Sigh. 
Sign up for the SourceForge newsletter:
No, thanks