const renderer = new WebGPURenderer({antialias:true,forceWebGL:true})
const postProcessing = new PostProcessing(this.renderer);
const scenePass = pass(this.scene, this.camera);
postProcessing .outputNode = scenePass;
postProcessing .render()
The old WebGL renderer, with the transparent background code set as follows, is effective. But the web GPU renderer is invalid
const alpha = 0;
renderer.setClearColor(‘0xfffff’, alpha);
renderer.clear();
finalComposer.render();
new WebGPURenderer({antialias:true,forceWebGL:true,alpha: true})
How to make the background of both the main scene and the small window transparent when using post-processing??
alpha is set to true by default in WebGPURenderer so doing post processing with a transparent background works without further changes: https://jsfiddle.net/y5bqkv6w/
Do you mind updating the fiddle to clarify your issue?
three.js dev template - module - JSFiddle - Code Playground
This version does not require login
Wait, have you filed the following issue at GitHub?
If so, I’ve mentioned at GitHub the root cause is related to inconsistent clear operations.
Yes, is there any way to temporarily modify the method used in the Three.js source code locally? In addition, regarding whether to consider sharing and collaborating on online templates in the future using the codesandbox.io I shared earlier, it has a lot of better features, such as the ability to create new files on the left side, open a browser consistent debugging console below, better format code, and so on. JSFiddle cannot create new files on the left side. When there is a lot of code to share, it can only be written in one file, which makes it difficult to read.
You can download three.module.js locally and modify it to your hearts content.
(or just pull the whole package and edit the files you want…) and if you fix something, you’re then all set to make a PR.
r.e. codepen/et al… there is a lot of churn in those web sandboxes, and committing to one or another may require some substantial maintenance effort, which is energy better spent on maintaining the core library and reviewing PRs etc.
However, if you develop some useful solutions that address some of your pain points with the library, be sure to share them here so we can all benefit from your insights!
There is now a PR with a fix:
I downloaded the latest development branch code of Three.js and ran it locally. After fixing it with you, the background color under the glow background of WebGL and WebGPU is correct, which solves the PR I raised on GitHub. However, I tried the transparency issue on the forum and it did not solve it. I think you may have misunderstood the problem I raised in the community, or I may have raised a new PR on GitHub? When setting the div background color to blue, turning on post-processing glow, and setting clear alpha=0, the entire scene background should be blue
I think… with the postprocessing library, you are at the mercy of what the passes themselves do to alpha…
So my guess is the bloom pass has to use alpha to blend the output of the bloom convolution back with the original framebuffer… thus wiping out the alpha.
Additionally… the bloom itself won’t have an alpha associated with it, so if you do somehow manage to save/restore the alpha before/after the composer renders, the bloom won’t be visible outside the original outline of the objects in the buffer.
You might be able to modify the bloom pass to write the brightness of the bloom buffer to alpha during the composite with the original framebuffer?
It all sounds fiddly… but… if you can solve it… it might be worth a PR to bloompass.
or maybe im wrong and this isn’t the issue 
This has nothing to do with Bloom. Using channels such as outline and fxaa can also cause this issue
Ok. What I said still holds.
If a post processing pass has to composite with the framebuffer, it has to output its own alpha value… (thereby destroying whatever alpha you wrote into the framebuffer).
But… you may be able to copy it off using some kind of hand written Pass, and then re-composite it as a final step in the post processing pipeline.
However… anything outside of that original alpha mask won’t render, including composer post process effects that may have rendered onto alpha!=1 regions.
they explicity set
renderer.setClearColor( 0x000000, 0.0 );
at init…
and then:
renderer.setClearColor( 0x222222, 1 );
renderer.clearDepth(); // important!
when rendering the overlay.
So… exactly what you would expect.
I may not have expressed myself clearly. What I expect is that both the small and large windows are transparent
Right. That demo explicity sets the background alpha to 1 for the small window. If you set it to 0, you would get both transparent.
You didn’t use the WebGPU renderer, and I’m only discussing the situation with WebGPU
