Hi.
I am rendering a scene that has lot of trees. The leaves of trees use alpha cutoff. But the funny thing is the color of the edges of leaves seems could be affected by the background color of the canvas.
When the background color is red:
When the background color is white:
But the scene seems fine with gltf-viewer.
How do you create your instance of WebGLRenderer?
I initiate the instance of WebGLRenderer with “alpha” and “antialias” are set to “true”.
Try it without setting the alpha parameter.
It works with “alpha” is set to “false”, but the canvas’ background cannot be customized. I’m fine with the result though. Is there a way to keep the canvas’ background style without getting this funny effect?
Consider to use Scene.background for defining a background for your scene. You can set a color, define a texture or even use a cube map. This approach is used in many official example of three.js.
I noticed that. I’m still curious about what cause the funny effect. 
Is there something to do with the material or shader that the model is using?
What happens if you set the blending property of the tree’s material to THREE.NoBlending? The effect is produced due to blending so disabling it for the respective materials should be a valid solution.
Setting blending to THREE.NoBlending doesn’t seem to work. I created a shader that implement “alpha cutoff” using THREE.ShaderMaterial. And if I don’t repalce the fragment color’s alpha with 1.0, the problem will show up. I haven’t create an example online yet. But I’ll do it later or just post the entire file of the example if needed.
OK. Here’s two examples I created. With funny effect and without funny effect. There’s difference on the line 42 in javascript section.
Yes, it seems that the browser composes the background color with objects that have an alpha value lower than one. Even if the object is in front of an opaque one. This can be avoided when the material of the front object is transparent although the visual result is different compared to not applying { alpha: true } to the renderer.
I have tested your fiddle with all Chrome, Firefox and Safari on macOS and they produce the same visual result. Because of this, I would say it’s the intended behavior.