Examples: Specify color space when loading texture #31571
Conversation
| //texture.generateMipmaps = false; | ||
| //texture.minFilter = LinearFilter; | ||
| //texture.magFilter = LinearFilter; | ||
| texture.colorSpace = THREE.LinearSRGBColorSpace; |
There was a problem hiding this comment.
Could we define LinearSRGBColorSpace as the default color space in HDR loaders instead?
There was a problem hiding this comment.
All three loaders in this PR return linear-sRGB as the default.
I filed this PR because I think only KTX2Loader currently honors the color space defined in the file.
Since three.js generally expects users to set the color space, I thought maintaining a consistent pattern for users to copy would be advisable.
There was a problem hiding this comment.
I've mentioned this multiple times in the past but I personally am not a fan to setting default values again since it makes the code verbose. The idea is to keep the code simple and compact and users should rely on proper default values.
If one color space is by far the most used in textures returned by the loaders, I think there is no reason the define the color space again.
There was a problem hiding this comment.
Wait, so in this case we're setting this color space redundantly?
There was a problem hiding this comment.
Indeed, that's what the PR does.
three.js/examples/jsm/loaders/EXRLoader.js
Line 2405 in 7a1f975
three.js/examples/jsm/loaders/RGBELoader.js
Line 464 in 7a1f975
There was a problem hiding this comment.
The user should not be expected to comprehend the source code to know that it is necessary to set a correct color space.
Or, for that matter, to know that a loader, such as EXRLoader, does not honor the color space, even if it is defined in the file.
Or to know that the loader is guessing.
The other examples of this type define a color space upon loading. I think that is a good thing, because it is a pattern users copy.
There was a problem hiding this comment.
Personally — I do think it's a good habit to explicitly assign color space when loading individual textures. For most formats (excluding KTX2) we don't have reliable metadata, so the loaders can't do more than guess with a reasonable default. For EXR things might improve eventually, see AcademySoftwareFoundation/openexr#1783.
Another example, when loading individual textures in R3F with TextureLoader, the default is sRGB. In three.js the default is NoColorSpace.1 Not all users are subject to the same defaults.
1 I prefer our choice, because at least when you forget to assign THREE.SRGBColorSpace to a color texture, it is visible as a problem in color, rather than a problem in occlusion or normals or metalness that may be much less obvious to diagnose.
There was a problem hiding this comment.
FYI, that information about R3F is recently incorrect, and now defers to three.js defaults. We agree with Don here and made this change with v9. Both R3F and the three.js editor will assign sRGB if otherwise unset only if they see a texture applied to a known list of material fields (IMO it is confusing this isn't managed by three, as this can be done conservatively). It is valid usage to use something other than sRGB for color textures, as users may include P3-authored textures in the future (or another wide gamut color space like Rec 2020). That makes it impossible to guess the correct option and only possible to guess an incorrect option if the context is known.
As the title says.