Description of the bug
Upgrading postprocessing from 6.39.1 → 6.39.4 makes GodRaysEffect stop compositing its light source entirely. The sun disc that the effect renders is simply absent from the final image; everything else in the scene renders normally.
The light source mesh itself is fine — with the effect removed, the mesh renders. It is the effect's compositing of it that produces nothing.
I have not bisected 6.39.2 vs 6.39.3 (see Scope of testing below), but the plausible candidate is the 6.39.3 change — "EffectComposer: fix depth buffer format mismatch when depth-aware passes are added after the composer has already rendered" (#745) — since that is the release that reworks how depth textures are allocated and handed to passes. GodRaysEffect's own render path is byte-identical between 6.39.1 and 6.39.4 (diffed build/index.js), so the change is beneath it, not in it.
To be clear: that depth fix looks correct on its own terms. In our app it also removed a glBlitFramebuffer: Read and write depth stencil attachments cannot be the same image warning that 6.39.1 emits continuously. We'd like to take it — the missing sun is what blocks us.
To reproduce
An <EffectComposer> containing <GodRays sun={mesh} /> (via @react-three/postprocessing@3.0.4), with a camera-tracked sphere as the light source:
<GodRays sun={sunMesh} samples={100} density={0.97} decay={0.95}
weight={1.1} exposure={0.88} clampMax={1} blur />Canvas is created with gl={{ antialias: false, alpha: false, depth: true, stencil: false }}. Other effects in the same composer: N8AO, HueSaturation, BrightnessContrast, Bloom, SMAA, ToneMapping.
On 6.39.1 the sun disc renders. On 6.39.4 it does not. No console error accompanies the disappearance.
Expected behavior
GodRaysEffect composites its light source as it did in 6.39.1.
Evidence
Measured on gated screenshots rather than by eye — blue channel sampled at y=4, x=95..165 (the disc is warm, so its blue is lower than the surrounding sky). Identical values across two independent scenes:
6.39.1, GodRays ON 213,214,215,195,196,197,198,198,199,200,200,201,223,224,224 deep dip → disc present
6.39.4, GodRays ON 214,215,215,216,217,217,218,219,220,220,221,222,223,224,225 NO dip → disc absent
6.39.4, GodRays OFF 214,215,215,213,212,212,213,213,214,216,217,219,223,224,225 shallow → bare mesh only
The third row is the ablation: disabling the effect (nothing else changed) brings the mesh back. That is what localises the fault to the effect's compositing rather than to the mesh, its material, or scene setup.
Ruled out — the light source's material. Our material violates the documented contract (meshBasicMaterial defaults to depthWrite: true, transparent: false, whereas the JSDoc says "Must not write depth and has to be flagged as transparent"). We fixed that, and separately tried depthTest/depthWrite false. Both produced byte-identical output to the unfixed version — same fifteen sample values, both scenes. So the contract violation is real and worth us fixing, but it is not this bug.
Library versions used
postprocessing 6.39.1 (working) → 6.39.4 (broken); 6.39.4 is current latestthree 0.172.0@react-three/fiber 9.5.0, @react-three/postprocessing 3.0.4, react 19.2.8- HeadlessChrome 151 (
--use-angle=swiftshader), macOS arm64. Also reproduces on Chrome 147.
Scope of testing
Honest about what I did and didn't do: I tested 6.39.1 and 6.39.4 only — the intermediate versions are inferred from the changelog, not measured. Each test cycle here is a ~33-minute deterministic screenshot capture, which is why I stopped at the boundary rather than bisecting.
Happy to bisect 6.39.2/6.39.3 or put together a minimal standalone reproduction if either would help — just say which is more useful.
Description of the bug
Upgrading
postprocessingfrom 6.39.1 → 6.39.4 makesGodRaysEffectstop compositing its light source entirely. The sun disc that the effect renders is simply absent from the final image; everything else in the scene renders normally.The light source mesh itself is fine — with the effect removed, the mesh renders. It is the effect's compositing of it that produces nothing.
I have not bisected 6.39.2 vs 6.39.3 (see Scope of testing below), but the plausible candidate is the 6.39.3 change — "EffectComposer: fix depth buffer format mismatch when depth-aware passes are added after the composer has already rendered" (#745) — since that is the release that reworks how depth textures are allocated and handed to passes.
GodRaysEffect's own render path is byte-identical between 6.39.1 and 6.39.4 (diffedbuild/index.js), so the change is beneath it, not in it.To be clear: that depth fix looks correct on its own terms. In our app it also removed a
glBlitFramebuffer: Read and write depth stencil attachments cannot be the same imagewarning that 6.39.1 emits continuously. We'd like to take it — the missing sun is what blocks us.To reproduce
An
<EffectComposer>containing<GodRays sun={mesh} />(via@react-three/postprocessing@3.0.4), with a camera-tracked sphere as the light source:Canvas is created with
gl={{ antialias: false, alpha: false, depth: true, stencil: false }}. Other effects in the same composer:N8AO,HueSaturation,BrightnessContrast,Bloom,SMAA,ToneMapping.On 6.39.1 the sun disc renders. On 6.39.4 it does not. No console error accompanies the disappearance.
Expected behavior
GodRaysEffectcomposites its light source as it did in 6.39.1.Evidence
Measured on gated screenshots rather than by eye — blue channel sampled at
y=4,x=95..165(the disc is warm, so its blue is lower than the surrounding sky). Identical values across two independent scenes:The third row is the ablation: disabling the effect (nothing else changed) brings the mesh back. That is what localises the fault to the effect's compositing rather than to the mesh, its material, or scene setup.
Ruled out — the light source's material. Our material violates the documented contract (
meshBasicMaterialdefaults todepthWrite: true,transparent: false, whereas the JSDoc says "Must not write depth and has to be flagged as transparent"). We fixed that, and separately trieddepthTest/depthWritefalse. Both produced byte-identical output to the unfixed version — same fifteen sample values, both scenes. So the contract violation is real and worth us fixing, but it is not this bug.Library versions used
postprocessing6.39.1 (working) → 6.39.4 (broken); 6.39.4 is currentlatestthree0.172.0@react-three/fiber9.5.0,@react-three/postprocessing3.0.4,react19.2.8--use-angle=swiftshader), macOS arm64. Also reproduces on Chrome 147.Scope of testing
Honest about what I did and didn't do: I tested 6.39.1 and 6.39.4 only — the intermediate versions are inferred from the changelog, not measured. Each test cycle here is a ~33-minute deterministic screenshot capture, which is why I stopped at the boundary rather than bisecting.
Happy to bisect 6.39.2/6.39.3 or put together a minimal standalone reproduction if either would help — just say which is more useful.