Texel values at upper and bottom poles of InfiniteAreaLight leak to other directions #63

mmp opened this Issue Mar 31, 2016 · 2 comments


None yet

2 participants

mmp commented Mar 31, 2016

If the InfiniteAreaLight constructor is modified to create a low-res environment map with only the top scanline emitting like this:

          resolution.x = resolution.y = 10;
          for (int y = 0; y < resolution.y; ++y) {
            for (int x = 0; x < resolution.x; ++x) {
              if (y == 0)
                texels[y * resolution.x + x] = 1000000.;
                texels[y * resolution.x + x] = 0.;

Then if a small test like this is performed:

    for (Float y = 0; y < 1.f; y += .0249f) {
      for (Float x = 0; x < 1.f; x += .125f) {
        fprintf(stderr, "(%f, %f) = %f\n", x, y,
                Lmap->Lookup(Point2f(x, y)).y());

Then for lots of y values close to 1, the lookup returns a non-zero result:

(0.625000, 0.996000) = 494165.437500

For high-res environment maps, this issue is hidden by the fact that the sinTheta value that the environment map luminance is multiplied by when creating the sampling PDF is very small. But this is still bad.

The root issue is that we want the MIPMap to use REPEAT (as it does now) for out-of-bounds s coordinates, but to do a mirror and flip combination for out of bounds t. Unfortunately, MIPMap only supports one wrap mode. The right fix is probably to rewrite InfiniteAreaLight to not use MIPMap at all, since we don't need most of its functionality anyway.

Also, we should add a unit test for this when it's fixed.

mmp commented Mar 31, 2016

(Figured this out when thinking about issue #62)


To emulate CLAMP_TO_EDGE for v for the texture lookup after sampling in InfiniteAreaLight::Sample_Li and InfiniteAreaLight::Sample_Le you can just clamp v to [0.5/height, 1.0-0.5/height].

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment