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

[Alen L. <ale...@cr...>]

Fabian wrote at 4/28/2009:
> The second order SH basis functions aren't (and their symmetries are
> rotations by multiplies of 90 degrees, not 180, around the Z axis),
> so you'll get undershooting in other places too.

That makes sense. Thanks!

Sam wrote at 4/28/2009:
> - 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.

Do you mean to generate a cubemap by evaluating SHs with synthetic
values like (1, 0, 0,..., 0) and see if they transform back to
themselves? Sounds interesting. Will have to try that.

> - 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.

Hm, the current result seems to be of correct brightness so perhaps,
that is not it. When integrating across a cubemap, I use these
coefficients:

static const FLOAT c[5] = {
  0.282095f*0.282095f * 1.0f,
  0.488603f*0.488603f * 2.0f/3.0f,
  1.092548f*1.092548f * 1.0f/4.0f,
  0.315392f*0.315392f * 1.0f/4.0f,
  0.546274f*0.546274f * 1.0f/4.0f
};

in these equations:

FLOAT SHC[9] = {
c[0],
c[1] * v.x,
c[1] * v.y,
c[1] * v.z,
c[2] * v.x * v.z,
c[2] * v.z * v.y,
c[2] * v.y * v.x,
c[3] * (3.0f* v.z*v.z -1.0f),
c[4] * (v.x*v.x - v.y*v.y)
}

integrated over the cube and additionally weight each pixel by
differential angle expressed as R^(-3/2) (to compensate for the cube
shape).

When approximating just one directional light, I use these
coefficients:

static const FLOAT c[5] = {
  0.282095f*0.282095f * PI*16.0f/17.0f * 1.0f,
  0.488603f*0.488603f * PI*16.0f/17.0f * 2.0f/3.0f,
  1.092548f*1.092548f * PI*16.0f/17.0f * 1.0f/4.0f,
  0.315392f*0.315392f * PI*16.0f/17.0f * 1.0f/4.0f,
  0.546274f*0.546274f * PI*16.0f/17.0f * 1.0f/4.0f
}

But that is just a fixed multiplier for all coeficients, and that
should be covered as the current brightness seems correct (testing
with simple blue/red cubemaps etc.)

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

> I guess you could also test a known cubemap + SH coeffs to compare your
> output with other peoples?
Sounds like a good idea. Do you know of any such examples? Google
didn't find anything useful.

Thanks,
Alen