Re: Undershooting in spherical harmonics generated bycubemap convolution

Hi Alen,

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

Yep, exactly. You can turn this into a proper unit test.

> Hm, the current result seems to be of correct brightness so perhaps,
> that is not it. 

Worth noting that the overall brightness is controlled by just the L0
(ambient) value. The others all integrate to zero and just 'add shape'
to the signal. So it's possible to get the ambient value correct and the
others wrong. If they are too low in general the lighting will be too
directionless. If they are too high you exaggerate the shape (and
ringing).

Btw, if it does turn out to be ringing, the easiest way to reduce this
is to simply scale down the L1 and L2 terms :). 

> When integrating across a cubemap, I use these
> coefficients:

Off the top of my head, these look ok - the cosine term is the rational
on the right hand side. I note they are identical to the Ramamoorthi
paper: http://graphics.stanford.edu/papers/envmap/. 

Did you learn about SH through a different paper to this? If so I'd
recommend reading the Ramamoorthi paper in some detail. For one, I just
noticed it happens to have some numerical SH values in it for Paul
Debevec's light probes, which you can grab online.

Cheers,
Sam

-----Original Message-----
From: Alen Ladavac [mailto:[email protected]] 
Sent: 28 April 2009 13:25
To: Sam Martin; Fabian Giesen
Cc: Game Development Algorithms
Subject: Re: [Algorithms] Undershooting in spherical harmonics generated
bycubemap convolution

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


------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list