Three.js PMREMGenerator has incorrect texture filtering

Question

I have a scene in Three (using AFrame) that requires environment mapping for lighting. Using a standard HDR cubemap, I get the following results:

Scene with HDR Cubemap

This is correct as far as blurring based on roughness goes, since I have mipmaps being generated and the minFilter set to LinearMipmapLinearFilter. The issue with this approach is that ambient lighting isn't being applied - the light in the scene, a directional light, is the only thing providing any lighting information to the scene. Unfortunately, this results in entirely black shadows, no matter how bright the HDRI.

However, if I use the PMREMGenerator from Three in addition to the above, the ambient lighting issue is solved. Unfortunately, this is what happens as a result:

Scene with PMREM map

As shown here, the texture filtering is now out of whack. According to comments left in the PMREMGen script itself.

This class generates a Prefiltered, Mipmapped Radiance Environment Map (PMREM) from a cubeMap environment texture. This allows different levels of blur to be quickly accessed based on material roughness. It is packed into a special CubeUV format that allows us to perform custom interpolation so that we can support nonlinear formats such as RGBE. Unlike a traditional mipmap chain, it only goes down even more filtered 'mips' at the same LOD_MIN resolution, associated with higher roughness levels. In this way we maintain resolution to smoothly interpolate diffuse lighting while limiting sampling computation.

...which leads me to believe the output should be smoothed, like in my first example.

Here's my code for the first example:

const ctl = new HDRCubeTextureLoader();
ctl.setPath(hdrPath);
ctl.setDataType(THREE.UnsignedByteType);

const hdrUrl = [
  `${src}/px.hdr`,
  `${src}/nx.hdr`,
  `${src}/py.hdr`,
  `${src}/ny.hdr`,
  `${src}/pz.hdr`,
  `${src}/nz.hdr`
];
const hdrSky = ctl.load(hdrUrl, tex => this.skies[src] = hdrSky );

// Then later...

obj.material.envMap = this.skies[this.skySources[index]];
obj.material.needsUpdate = true;

Here's my code for the second example:

const ctl = new HDRCubeTextureLoader();
ctl.setPath(hdrPath);
ctl.setDataType(THREE.UnsignedByteType);

const hdrUrl = [
  `${src}/px.hdr`,
  `${src}/nx.hdr`,
  `${src}/py.hdr`,
  `${src}/ny.hdr`,
  `${src}/pz.hdr`,
  `${src}/nz.hdr`
];

const pmremGen = new PMREMGenerator(this.el.sceneEl.renderer);
pmremGen.compileCubemapShader();

const hdrSky = ctl.load(hdrUrl, tex => {
    const hdrRenderTarget = pmremGen.fromCubemap(hdrSky);
    this.skies[src] = hdrRenderTarget.texture;
});

// Then later...

obj.material.envMap = this.skies[this.skySources[index]];
obj.material.needsUpdate = true;

I seem to have hit a wall in regard to the filtering. Even when I explicitly change the filtering type and turn on mipmap generation inside of PMREMGenerator.js, the results appear to be the same. Here's an official example that uses the PMREMGenerator without any issue: https://threejs.org/examples/webgl_materials_envmaps_hdr.html

As a closing remark I will note that we're using Three.js r111 (and there are reasons we can't switch it out fully), so I brought in the current version of the PMREMGenerator from the latest version of Three as of this writing (r122 - later version needed as the r111 one is written completely differently). Thus, I wouldn't be surprised if this was all being caused by some conflict between versions.

EDIT: Just put the resulting envmap as a standard map on some planes, and much to my surprise none of the blurred LODS even show up. Here's what mine look like:

Broken LODS

And here's what it should resemble (don't mind the torus knot):

Correct LODS

EDIT: I've found a workaround for now (essentially, not using PMREMGenerator), but will leave this up in case a solution is discovered.

can you upload it on a glitch? I couldn't replicate it with the Threejs sample hdrs (I've tried here) — Piotr Adam Milewski
Sadly this project is far too large to upload to glitch (it is using Mozilla Hubs: github.com/mozilla/hubs). I suspect the issue has to do with a variety of mis-matched Three versions across several scripts is the cause. Replicating the issue fully would probably require replicating the entire environment (which I realize isn't particularly great for requesting help online - but I did anyway in case I was missing something obvious). For now, I'm solving this by simply not using the PMREMGenerator and applying my cubemaps directly. — Ethan Michalicek

Marquizzo Marquizzo · Accepted Answer · 2020-11-19T23:02:35

I believe the problem is with the argument you're using in fromCubemap(). Right now your code isn't using the tex cubetexture variable that's passed to the loaded callback. Try this:

const hdrSky = ctl.load(hdrUrl, tex => {
    // use tex instead of hdrSky
    const hdrRenderTarget = pmremGen.fromCubemap(tex);
    this.skies[src] = hdrRenderTarget.texture;
});

Three.js PMREMGenerator has incorrect texture filtering

1 Answers