RGBELoader: Clamp prior to converting to half float

[WestLangley]

Fixes #22435.

In lieu of #22444. (It is the calling app's responsibility to decide how to clamp large values.)

In this PR, the clamping is per-channel independently. Clamping to prevent a hue shift is also reasonable if users complain. But ACES Filmic shifts hue anyway, so for now, I think this is OK.

Below: Linear tone mapping and exposure set to 0.01. You can see how bright the sun is compared to the rest of the sky.

[mrdoob]

@Mugen87 I should merge this one instead of #22444, right?

[WestLangley]

I think a warning in #22444 instead of a clamp would be a good idea. That way, we will not be obfuscating the problem.

[Mugen87]

I personally favored #22444. Now, I just want to see this issue fixed. I don't have a strong opinion anymore whether we clamp in the loader or in toHalfFloat() . Merge whatever you think it's best.

[mrdoob]

I think a warning in #22444 instead of a clamp would be a good idea. That way, we will not be obfuscating the problem.

That makes sense to me actually. A warning in toHalfFloat() would help any "users" of that function.

[mrdoob]

@WestLangley What do you think the warning message should be?

[WestLangley]

Maybe

console.warn( 'THREE.DataUtils.toHalfFloat(): value exceeds 65504.' );

three.js does not typically validate data, however. I was thinking a warning would be useful in alerting us to other possible problems. But that was just a thought...

[Mugen87]

How about: b85fa19

[mrdoob]

How about: b85fa19

That looks good to me 👍

[mrdoob]

Thanks!

[Mugen87]

Since you have merged both PRs, the clamping is now implemented two times. One should be sufficient, no 😇 ?

[mrdoob]

Hmm, up to you.

I agree with @WestLangley that toHalfFloat() should warn the developer.
Whether it also clamps it or not I don't mind, but I think the clamp makes more sense in RGBELoader.

[Mugen87]

Whatever! At least we have one more closed issue 🎉 .

[mrdoob]

No more UFOs! 😁