Re: [Algorithms] Undershooting in spherical harmonics generated bycubemap convolution

[Sam M. <sam...@ge...>]

Hi Alan,

SH can suffer from ringing and that really bright sun isn't going to
help, but there's a myriad of other things that can go wrong and produce
the same problems. Ringing is usually less of a problem for representing
irradiance as its low frequency (as opposed to radiance or visibility).
>From your description it sounds like you could well have other problems
so it's worth ruling those out first. 

Some suggestions on things to check:

- Check your maths and implementation to make sure your coeffs are
scaled appropriately. It can be helpful to project cube maps with the
single SH basis elements in them to ensure you get the coeffs out you
expect and at the right scale. 

- Check you are including the scaling for the cosine convolution. If you
are missing it your L2 SH will be too bright and can produce this kind
of artefact.

- Check for bugs by testing the rotational invariance. Ie. rotate your
cube map and ensure the projection rotates as expected.

I guess you could also test a known cubemap + SH coeffs to compare your
output with other peoples?

Hope that helps,
Sam

-----Original Message-----
From: Alen Ladavac [mailto:ale...@cr...] 
Sent: 28 April 2009 08:31
To: Game Development Algorithms
Subject: [Algorithms] Undershooting in spherical harmonics generated
bycubemap convolution

Hi all,

When generating 2nd order SHs by convolving environment cubemaps, In
some rare cases I get some strange artefacts that seem as if that is
just a limitation of 2nd order SHs, but I'm not sure, so I figured I'd
ask...

The problematic case is where there is only a handful of very bright
(~2000x the cubemap average) pixels in one narrow direction (~0.5
deg). (This example is generated by a sun disk in the skies, when seen
through a small window in a dark room).

In this case I get large undershooting (manifesting as a black spot)
in some other direction. Depending on the bright direction, the black
spot is sometimes on the opposite side, but sometimes it is e.g. 90 or
135 degrees from the bright side, etc. I was expecting to see
something like this in the exact opposite direction, but I'm a bit
surprised to see it move around. Then again, I'm not an SH expert, so
I'm probably wrong.

So to ask a concrete question: Is it normal for SH approximation
errors in such "spiky" cases to generate undershooting in directions
that are not directly opposite to the brightest point?

Thanks,
Alen



------------------------------------------------------------------------
------
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t