Skip to content

Conversation

@anischelly26
Copy link

This PR improves the documentation of the Texture.colorSpace property by explaining when to use SRGBColorSpace vs LinearSRGBColorSpace, and why it's important for visual accuracy.

@github-actions
Copy link

📦 Bundle size

Full ESM build, minified and gzipped.

Before After Diff
WebGL 336.49
78.38
336.49
78.38
+0 B
+0 B
WebGPU 542.05
150.13
497.43
137.89
-44.62 kB
-12.24 kB
WebGPU Nodes 541.51
150.03
496.9
137.78
-44.62 kB
-12.24 kB

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

Before After Diff
WebGL 465.42
112.22
465.42
112.22
+0 B
+0 B
WebGPU 614.89
166.17
567.23
153.16
-47.66 kB
-13.02 kB
WebGPU Nodes 569.88
155.58
522.22
142.55
-47.66 kB
-13.04 kB

@Mugen87
Copy link
Collaborator

Mugen87 commented Apr 11, 2025

Your PR modifies a lot of unrelated files. Please setup a fresh PR with a correct diff.

@donmccurdy
Copy link
Collaborator

donmccurdy commented Apr 15, 2025

A couple comments on the proposed text —

... The default is [page:Textures THREE.NoColorSpace].

This is true, but it might be worth mentioning that different texture loaders may have different defaults than the THREE.Texture constructor. For example, EXRLoader will default to THREE.LinearSRGBColorSpace.

If your texture contains color information (like a diffuse map or albedo), it's highly recommended to use [page:Textures THREE.SRGBColorSpace] so that correct gamma correction is applied during rendering.

It might be best to frame this in terms of what the texture is likely to be rather than what you "should" use. It's fine to create diffuse maps in Linear-sRGB or Display P3 or Rec. 2020, as long as they're marked as such. But if you are unsure, it's likely that your diffuse color maps are sRGB.

If the texture contains non-color data (like normal maps, roughness, or metalness), you should use [page:Textures THREE.LinearSRGBColorSpace] or leave it at the default.

I would suggest THREE.NoColorSpace for non-color data. Technically LinearSRGBColorSpace will also give the same results today, but will cause issues in wide-gamut or HDR rendering in the future. Semantically the important thing is that the texture isn't representing color, and shouldn't be converted between color spaces as if it were.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants