Upgrading from r129 to r133 has introduced an issue for me where three.js is assuming mipmaps exist for a dds/compressed cubetexture. This texture object has no mipmaps but rather an array of images. Those images do contain mipmaps but the base texture object does not. r129 works fine. Am I missing something here?
Uncomment line# 56 to show the problem.
I’ve filed a PR to fix this issue:
To clarify, you have used MeshStandardMaterial not correctly in your fiddle so far. It is required to preprocess the envmap via PMREMGenerator. Since r131 the engine does this automatically which makes an error in PMREMGenerator visible. However, it is also present in earlier versions than r131.
Great! Thank you for posting a PR.
To be perfectly honest I have no clue what PMREMGenerator is or how to use one in the context of using an envMap with a material. Is there documentation on this workflow or could some kind user edit the example fiddle to show how this is supposed to be done now?
When you upgrade, it’s not necessary to work with this class in your fiddle anymore.
Short version: PMREMGenerator preprocessed environment maps so they can be correctly used in context of PBR. Without PMREMGenerator, environment maps with MeshStandardMaterial or MeshPhysicalMaterial are considered to be physically incorrect.
Oh ok, got it. Thank you.
I just use StandardMaterial since it supports roughness/metalness maps. I have no concern over physically correct envmaps.