You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
If you initialize an EffectComposer with a RenderTarget with a depthTexture, because you want to use depth information in your Passes, as soon as you have more than 2 passes in the pipeline and any one of them try to write to the depth buffer you'll get an error.
On Chrome you get GL_INVALID_OPERATION: Feedback loop formed between Framebuffer and active Texture.
On Firefox you get WebGL warning: drawArraysInstanced: Texture level 0 would be read by TEXTURE_2D unit 1, but written by framebuffer attachment DEPTH_ATTACHMENT, which would be illegal feedback.
This happens because EffectComposer will clone the RenderTarget to create the secondary RenderTarget, but this clone will not clone the depthTexture, only the texture. So now both the read and write targets will share the same depth texture.
As soon as a render passes try to use and write the depthTexture the code will trigger the error.
To Reproduce
You can open this fiddle https://jsfiddle.net/zhmoekwa/
And you will se a black screen.
If you uncomment line 147 to manually clone the depthTexture after the EffectComposer is created now the code works
Code
As the code is quite complex because requires an effect composer + a custom Pass please check the fiddle for the code
The expected behaviour is that if I create a EffectComposer on a target with a depthTexture then I can use read and write depth information in the EffectComposer Passes.
** Possible Solutions**
I think it could make sense to update the WebglRenderTarget clone method to clone the depthTexture if present like is currently doing for the color texture.
Or at least the EffectComposer should properly clone the depthTexture if present in the construction arguments.
Platform:
Device: Desktop
OS: Windows
Browser: Chrome, Firefox, Edge
Three.js version: [dev, r135]
The text was updated successfully, but these errors were encountered:
I ran into this problem too. I fix it temporary by modifying EffectComposer.
After this.renderTarget2 = renderTarget.clone();
Add this.renderTarget2.depthTexture = renderTarget.depthTexture.clone();
Describe the bug
If you initialize an EffectComposer with a RenderTarget with a depthTexture, because you want to use depth information in your Passes, as soon as you have more than 2 passes in the pipeline and any one of them try to write to the depth buffer you'll get an error.
On Chrome you get GL_INVALID_OPERATION: Feedback loop formed between Framebuffer and active Texture.
On Firefox you get WebGL warning: drawArraysInstanced: Texture level 0 would be read by TEXTURE_2D unit 1, but written by framebuffer attachment DEPTH_ATTACHMENT, which would be illegal feedback.
This happens because EffectComposer will clone the RenderTarget to create the secondary RenderTarget, but this clone will not clone the depthTexture, only the texture. So now both the read and write targets will share the same depth texture.
As soon as a render passes try to use and write the depthTexture the code will trigger the error.
To Reproduce
You can open this fiddle
https://jsfiddle.net/zhmoekwa/
And you will se a black screen.
If you uncomment line 147 to manually clone the depthTexture after the EffectComposer is created now the code works
Code
As the code is quite complex because requires an effect composer + a custom Pass please check the fiddle for the code
Live example
https://jsfiddle.net/zhmoekwa/
Expected behavior
The expected behaviour is that if I create a EffectComposer on a target with a depthTexture then I can use read and write depth information in the EffectComposer Passes.
** Possible Solutions**
I think it could make sense to update the WebglRenderTarget clone method to clone the depthTexture if present like is currently doing for the color texture.
Or at least the EffectComposer should properly clone the depthTexture if present in the construction arguments.
Platform:
The text was updated successfully, but these errors were encountered: