Re: Undershooting in spherical harmonics generated bycubemap convolution

"Sam Martin" <[email protected]>
Newsgroups gmane.games.devel.algorithms
Message-ID <A78F73023D9DAC4B967091570A1540CF481BC8@THHS2EXBE1X.hostedservice2.net>
Hi Alen,

<snip>
Am I wrong to think that the difference is not just a scaler in some
of those cases? When trying to get irradiance SH from a cubemap which
represents radiance, I'm convolving not just by the SH, but also by
clamped cosine. When convolving with cosine, I'm effectively
generating a "blurry" SH from a "non-blurry" cubemap. Converting that
"blurry" SH into a cubemap will generate a "blurry" cubemap, which
cannot be easily compared to the "non-blurry" original (save for doing
O(P^2) convolution in the cubemap space and comparing to that).
</snip>

It really is just a scalar - this is one of the very cool things about SH. When represented in SH, the blurry version is just a scaled version of the non-blurry version. This is true when convolving against any radially symmetric function. The radially symmetic bit effectively means the result doesn't depend on the m-components of the function, and turns into just one scalar for each L. Incidentally, the fact all the odd bands from L3 upwards disappear is the main proof you can't invert this convolution - it does actually lose information. 

You should think of the L-bands in SH as frequencies. When you convolve with the clamped cosine you remove a load of high frequencies - but not all due to the presence of the clamp. So when you blur your SH version of the cubemap all you need to do is scale the frequencies appropriately. (This scaling is the A terms in the paper).  

<snip>
That passes. But it seems like (and is intuitive to be that way) this
kind of test covers only existence of correct x/y/z powers in the
polynomials. Putting any coefficients in front passes the test. (E.g.
if c0-c4 are all 1, this test passes.) Or am I missing something?
</snip>

Providing you test each coefficient in isolation, sure, it only tests that something else isn't getting into your code causing 'talk' between the coefficients. Testing you haven't made a mistake with the scaling is harder.

Cheers,
Sam

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com

_______________________________________________
GDAlgorithms-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.