GLTFLoader: Specify color space of inputs

[donmccurdy]

• Related: Roadmap for supporting wide-gamut color workflows #26479

In order to support wide-gamut working color spaces, loaders should declare the colorspace of source data when constructing THREE.Color instances, rather than (a) explicitly converting it to LinearSRGBColorSpace, or (b) implicitly assuming the working color space matches the input.

In GLTFLoader, that means...

// before
color.fromArray( lightDef.color );


// after
color.setRGB( ...lightDef.color, LinearSRGBColorSpace );

Conversion of vertex colors is slightly more work (consider that morph targets contain deltas against the base vertex color) so I've simply logged a warning to alert us to that situation, if it comes up.

No user-facing differences are expected as a result of this PR; it takes effect only if/when we allow changing the working color space.

[gkjohnson]

It looks like converting color attributes was lost in the new roadmap in #26479. We should plan to cover this case in the long term, right?

[donmccurdy]

Yes, I do intend that to be part of step 2.4, just not ready to make those changes here yet.

[donmccurdy]

Or did you mean just handling sRGB vs Linear sRGB vertex colors in existing workflows, without this wide gamut work? Are we missing something there, if so?

[gkjohnson]

I see - I think I expect there to be more to this color vertex attribute issue than just updating the loaders. I think item 3.3 we added in #23614 captured what I imagine being needed more completely. For example if users are dynamically generating vertex colors for geometry they need a way to ensure it's converted to the working color space. Though I guess that's convenience more than anything at this point since users can use the Color instance convert before constructing the vertex data array 🤔

Either way I think this is a good PR!

[donmccurdy]

Ah yeah. This is kind of verbose and unintuitive today:

const _color = new THREE.Color();
const color = geometry.attributes.color;
for (let i = 0; i < color.count; i++) {
  _color.setRGB(color.getX(i), color.getY(i), color.getZ(i), inputColorSpace);
  color.setXYZ(i, ..._color);
}

I don't know if I like the idea of a color-specific BufferAttribute subclass, but a cleaner way to do this would be nice.

[wlinna]

Unfortunately, it seems like this PR broke GLTFLoader. Let's take this for an example

			if ( Array.isArray( metallicRoughness.baseColorFactor ) ) {

				const array = metallicRoughness.baseColorFactor;

				materialParams.color.setRGB( ...array, LinearSRGBColorSpace);
				
				materialParams.opacity = array[ 3 ];

			}

Now if array has four elements, the fourth one (opacity) will be passed as an argument for colorSpace parameter, and LinearSRGBColorSpace will be ignored.

[Mugen87]

Good catch! Would you like to fix this with a PR?

[wlinna]

I suppose I could do it later today

[wlinna]

Here's the PR

#26691