Repository navigation
GodRaysEffect stops compositing its light source in 6.39.4 (works in 6.39.1) #750
Description
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/[email protected]), 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
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- 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.
Activity
vanruesc commentedon Aug 13, 2026
Hey, thanks for the report!
I can't reproduce this exact issue on my machine - the god rays demo renders as expected with
threer172. However, I am seeing gl errors with that version:This error disappears when using r174 and higher which points to a change regarding depth texture cloning: mrdoob/three.js#30585. The recent changes in e19bfa3 seem to trigger that bug in older versions of
three.@wowlegend can you upgrade to r174 to verify if this fixes the issue on your end?
docs(decisions): three r174 kills the GL-error storm — and is still n…
Fix gl error when using r172
atirna commentedon Aug 16, 2026
I traced the version interaction a little further.
e19bfa3clones the input depth texture for the output and stable targets. In three r172,DepthTexture.copy()inheritsTexture.copy()and the clones share the sameSource/image; r174 changes that in three.js#30585. That matches the feedback error and leaves r172 inside this package's declared peer range.I'd like to prepare a focused
EffectComposerchange that creates independently configured depth textures instead of relying onclone()for that path, with a regression check for the r172 contract. Is keeping r172 working the right scope, or should the supported minimum move to r174?vanruesc commentedon Aug 16, 2026
👉 can you upgrade to r174 to verify if this fixes the issue on your end?
No need. See 078a6d1.
vanruesc commentedon Sep 9, 2026
Should be fixed in v6.39.5
deps: postprocessing 6.39.5 exact -- the sun is back, measured, and t…
fix(ci): knip red on my own probe, and the GL ledger cannot answer th…
wowlegend commentedon Sep 22, 2026
Confirming the fix on three r172 — you asked me to verify and I never did, so here is the measurement.
You asked "can you upgrade to r174 to verify if this fixes the issue on your end?" and the thread moved on before that was answered. It is answered now, and on the version you originally asked about rather than the upgrade.
6.39.5 clears it on r172. Zero
glBlitFramebuffererrors.postprocessingthree@react-three/postprocessing@react-three/fiberANGLE (Apple, ANGLE Metal Renderer: Apple M3 Max)MAX_SAMPLEShalfRes) → GodRays → HueSaturation → BrightnessContrast → Bloom → SMAA → ToneMapping → Noise → VignetteMethod: production build, real GPU (not SwiftShader),
gl.getError()drained per frame rather than scraped from the console — the console undercounts by construction here, since Chrome mutes the context after ~256 errors and the storm exceeds that.I also ran a controlled pair, because we had changed
multisamplingon our side and I did not want to credit your fix for something of ours:<EffectComposer multisampling>0Identical either way, so the MSAA path is not involved and
078a6d1is doing the work.For the before side: on
postprocessing6.39.1 our own notes record the production console carrying the error in two alternating forms per frame, ~256 per load — and that number is a FLOOR rather than a count, because it is where Chrome stops reporting ("too many errors, no more errors will be reported to the console for this context"). I did not re-measure 6.39.1 with the per-framegetError()method, so I can compare "hundreds, ceiling-limited" against "zero over 1672 frames" but not two numbers gathered the same way.One note that may be useful to others landing here, since it is a different cause with the same message: N8python/n8ao#53 reports the same
Read and write depth stencil attachments cannot be the same imagearising from N8AO'shalfResMRT sharing a depth-stencil texture with the composer'sinputBuffer, and reports it unaffected by upgrades throughpostprocessing6.39.1 andthree0.184. We runhalfResand see zero on 6.39.5, so that path appears to be covered too — but it is a distinct mechanism and I have not isolated it, so treat that as an observation rather than a claim about their issue.Thanks for the quick turnaround on this one.
fix(docs): correct two claims of mine that measurement disproved — th…