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
{{ message }}
Repository navigation
Graceful fallback when renderbufferStorageMultisample is unsupported #749
Instead of skipping multisampling, it throws and crashes the whole app. Repro'd via @react-three/postprocessing + N8AO on Android emulator: multisampling > 0 crashes on first frame, multisampling={0} works fine. Root cause is in EffectComposer, not the wrapper or N8AO. Note that wrapper sets a non-zero default on its own, so users can hit this without asking for MSAA.
multisampling's setter already clamps samples to gl.getParameter(gl.MAX_SAMPLES). Extend that to also check if renderbufferStorageMultisample actually works, not just that it exists (on expo-gl it exists as a stub that throws when called), and fall back to samples = 0 if not.
Describe alternatives you've considered
Leave as is and document it, or handle it in wrappers instead. Raising it here since this is the one place that fixes it for every consumer at once.
Additional context
More a proposal than a bug report, not sure it's worth the complexity since it seems specific to partial WebGL2 implementations like React Native.
This sort of check would actually make more sense in three because postprocessing v6 can't reliably check if custom passes/effects create render targets with samples > 0. However, I doubt they would add a workaround for this specific case since this failure is more or less self-inflicted by expo.gl.
I'll add a fallback in postprocessing, but in v6 it will only apply to the main multisampling setting in EffectPass. In v7, all render targets are managed centrally, so it should be possible to add a broader check there.
Activity
vanruesc commentedon Jul 31, 2026
Interesting, I guess it won't hurt to add a check for this.
vanruesc commentedon Aug 16, 2026
This sort of check would actually make more sense in
threebecausepostprocessingv6 can't reliably check if custom passes/effects create render targets withsamples> 0. However, I doubt they would add a workaround for this specific case since this failure is more or less self-inflicted byexpo.gl.I'll add a fallback in
postprocessing, but in v6 it will only apply to the mainmultisamplingsetting inEffectPass. In v7, all render targets are managed centrally, so it should be possible to add a broader check there.Add multisampling fallback
vanruesc commentedon Sep 9, 2026
Fixed in v6.39.5