Hi there! I’ve been digging around for too long, help me out!
The main problem: textures are presenting high contrast and saturated colors, visible on the images attached. Notice darker areas and yellowish tint.
I am:
- setting
renderer.outputEncoding = THREE.sRGBEncoding;
- using
MTLLoader;
- not seeing any difference on changing
toneMapping and its exposure (which is strange, because some time ago I played a little with it);
- not successful on getting it right manually tweaking values on the .mtl file;
- using only
#ffffff lights.
.mtl specs:
Kd 0.50 0.50 0.50
Ka 0.50 0.50 0.50
Ks 0.25 0.25 0.25
Ns 1.00
Source code:
Scene.js
Model.js
My mind is tired so I hope I am just missing something simple… Thanks!
What version of three.js are you using? outputEncoding was replaced with ColorSpace, if you’re using the latest version of three try using texture.colorSpace = THREE.SRGBColorSpace
2 Likes
As @Lawrence3DPK mentions you’ll need .colorSpace not .encoding in recent versions, but OBJLoader / MTLLoader should be getting that correct by default, so I don’t think you should need to change them, at least in recent three.js versions.
not seeing any difference on changing toneMapping and its exposure (which is strange, because some time ago I played a little with it);
… that’s very surprising to me, and seems like a problem. The effect of .toneMappingExposure = 2 should be very visible, if tone mapping is enabled. 
These lines…
this.renderer.outputEncoding = THREE.sRGBEncoding;
this.renderer.outputColorSpace = THREE.LinearSRGBColorSpace;
… are probably a mistake, outputEncoding is from old three.js versions and outputColorSpace is from newer versions, and you’re assigning two different color spaces. Assuming a recent three.js version I would just stick to the default value, which is .outputColorspace = THREE.SRGBColorSpace.
If that’s not helping, a demo might be useful!
3 Likes
Yes, I’ve inspected the source code of MTLLoader and saw that it handles everything with ColorManagement.toWorkingColorSpace( new Color().fromArray( value ), SRGBColorSpace ), which is a recent commit by the way.
Indeed I was not careful on my side while refactoring this legacy code, thanks. Although, sticking to the default .outputColorspace = THREE.SRGBColorSpace doesn’t seem to modify anything.
What is annoying me is the fact that the most obvious and exaggerated changes (like the toneMapping) are not working. Something is off. What elements and attributes you recommend me to debug? Is the post processing pipeline deviating configs kinda like it does with the renderer antialias? Is this related to some tricky PhongMaterial behavior? 
Thank you for your attention
1 Like
Oh sorry, I’d missed the post-processing. That’s very likely the issue, as any output encoding (color space or tone mapping) does require a final pass in a post-processing pipeline. Probably you need to add THREE.OutputPass as shown here.
Typically it’s last, although it’s OK to put other passes later if they operate on an image (like a vignette) and not on scene light transport quantities (like a bloom pass), since the tone mapping step essentially turns that ‘data’ into an image or picture intended for a particular medium (your device screen).
3 Likes
