Hello
After upgrading to revision 164 (from 132) I got some expected issues related to lighting and colours that I could fix.
But after setting the outputColorSpace to SRGBColorSpace as recommended, the rendering quality of the materials changed. The triangles of the geometry are now visible and not smoothed as expected. And if I change the outputColorSpace to LinearSRGBColorSpace (which is NOT recommended) the triangles go away.
This is the rendering with r132 (GOOD)
This is the rendering with r164 (BAD)
And this is r164 with renderer.outputColorSpace = THREE.LinearSRGBColorSpace (no defects but BAD COLOR!)
The model and the texture are identical. Lights have been changed a bit but everything else has not changed. Any idea on what can cause this issue and how to fix it?
That’s a strange result! In general the color space change tends to produce less harsh lighting, such that people sometimes need to add a bit more contrast in afterward, so I’m surprised your app went the opposite way. The visible triangles are unexpected too.
- Can you see the same result on another device and/or browser?
- Is it possible to share a demo before and after?
- Are you using post-processing (EffectComposer) anywhere, and, are you using any tone mapping, and if so which one?
2 Likes
Thanks a lot for the suggestions, that was helpful and I could find the solution.
The problem was that I was setting the color space for the normalMap, metalnessMap and roughnessMap to SRGBColorSpace.
By using NoColorSpace the issue disappeared. The color map should remain SRGBColorSpace.
2 Likes
One note @drcmda
Is it possible that the color space gets changed/forced automatically to SRGBColorSpace when a texture previously created gets applied to an existing material in React Three Fiber? Wondering if this may happen because the NoColorSpace is a falsy value (empty string) so it could be turned into a default somewhere in Three.
I don’t have a proper test to prove this but this happens in my app so I need to force it every time in the update function of the material.
three.js defaults new textures to NoColorSpace, R3F defaults to SRGBColorSpace. I’m not sure at what point in the texture lifecycle that happens exactly in R3F, but the behavior will change in upcoming R3F v9 and match the three.js defaults (see [v9] fix!: don't automatically set texture colorSpace, colorMap fallback by CodyJasonBennett · Pull Request #3163 · pmndrs/react-three-fiber · GitHub).
In either case — it is probably a good best practice to assign each texture a color space explicitly, thinking about whether it is “color” or “data”. If data, always use NoColorSpace. If color, use SRGBColorSpace for PNG and JPG textures, or LinearSRGBColorSpace for HDR and EXR textures, unless you are very sure your textures were authored differently.
2 Likes
Credit goes to me right? I knew what it was at first glance? I’m unemployed, poor, and was once banned from here, would really appreciate some validation <3
I’m also super curious to see this normal map, the mesh itself looks pretty high res (the filleted edges for example) yet the normal map seems like it was possibly baked?
2 Likes
I lived through the era when “linear workflow” was introduced for 3d applications and GI.
It was extremely confusing to say the least.
Yeah thanks mate:) The normal map is nothing special, just an image with a single color.
The material was originally ported from Adobe Substance. That is where the idea of using those plain color maps came from. I think the same effect can be achieved tweaking Three StandardMaterial settings though. That’s just the way AS obtains the glossy look of the acetate material.
1 Like
