Some HDRI environments are fully black in r181.0 and r181.1

[nkallen]

Description

There appears to be an issue with some specific HDRIs where they appear fully black. Attached is one such HDRI. The issue is not in r180 I'm fairly certain. It was introduced in r181 and persists into r181.1

I saw this issue which is maybe related but does not appear to be fixed.

#32225

Reproduction steps

1. The jsfiddle reproduces this behavior. I'm a bit confused by it so let me explain what the jsfiddle is doing.

It has 3 different HDRIs. It setInterval updates the environment every 3 seconds, alternating between the environments. You can see two spheres with different material properties. Depending on the environment, one of the two spheres is black. It shouldn't be black. The reason I use two spheres is one of them has a very low roughness and one has a high roughness. The problem seems to affect high-roughness materials mostly.

Not only that, if you change the order that the HDRIs are loaded, for example if you do

const urls = [url3, url2, url1];

rather than

const urls = [url1, url2, url3];

The results are slightly different, implying there is a side-effect somewhere.

I don't think this is a bug in my code. Are you guys able to take a look? Thanks!!!

Live example

• jsfiddle-latest-release WebGLRenderer

Screenshots

No response

Version

r181.1

Device

No response

Browser

No response

OS

No response

[nkallen]

aerodynamics_workshop_2k.zip

[nkallen]

From the user who reported this. There appears to be a slight difference in how it's rendered on windows versus Mac. On Mac it's fully black, whereas on windows it's very dark.

[nkallen]

As mentioned regarding the fiddle, the order the environments are loaded seems to have an effect on rendering.

[Mugen87]

I have tracked down the root cause and the regression is introduced with #32114. The last build before this PR was merged works:

Before (https://github.com/mrdoob/three.js/tree/b8167d7e97b5a7b086476192c5fd7889bb20c5a0): https://jsfiddle.net/kuec4m93/
After (https://github.com/mrdoob/three.js/tree/e1388ac56c6a13a97d4fd1268b75b80c227245e2): https://jsfiddle.net/kuec4m93/1/

[Mugen87]

Um, it is strange that individually loading the environment maps works as expected. Maybe the new implementation is caching something that should not be reused when switching the maps.

@nkallen It seems these environment maps have different resolutions? Is that true? Would it be possible if you resize the maps to the same size and see if the issue persists?

@mrdoob Maybe it's this bit:

three.js/src/extras/PMREMGenerator.js

Lines 522 to 528 in 2df1da2

	if ( this._ggxMaterial === null ) {
	const width = 3 * Math.max( this._cubeSize, 16 );
	const height = 4 * this._cubeSize;
	this._ggxMaterial = _getGGXShader( this._lodMax, width, height );
	}

The GGX material is created once with a fixed this._cubeSize. It seems the code does not account for the possibility that the size might change depending on the processed environment map.

[nkallen]

It seems these environment maps have different resolutions? Is that true? Would it be possible if you resize the maps to the same size and see if the issue persists?

That could be - these are user generated (or downloaded) content. That would explain why just a few of these seem problematic -- they have unusual resolutions. It's a bit late here at the moment but tomorrow morning I can run imagemagick and get these all to the same size. But it seems like you already found the problem with _cubeSize I'm guessing

[mrdoob]

Yes, I've been noticing this too... I'll investigate now.

[mrdoob]

I've published 0.181.2 with the fix: https://jsfiddle.net/amd75hw9/