Skip to content

fix(ChromaticAberration): coerce offset prop to Vector2#349

Open
yourlcfr wants to merge 1 commit into
pmndrs:masterfrom
yourlcfr:fix/chromatic-aberration-offset-coercion
Open

fix(ChromaticAberration): coerce offset prop to Vector2#349
yourlcfr wants to merge 1 commit into
pmndrs:masterfrom
yourlcfr:fix/chromatic-aberration-offset-coercion

Conversation

@yourlcfr

Copy link
Copy Markdown

Fixes #348.

Routes offset through the existing useVector2 helper before it reaches the effect constructor, mirroring what Glitch already does. When offset isn't passed, the effect's own default Vector2(0.001, 0.0005) is left untouched.

  • Thin forwardRef wrapper around the existing wrapEffect component, so blendFunction/opacity handling is unchanged
  • Two regression tests using the same virtual-root harness as EffectComposer.test.tsx: tuple coercion (fails on master), default preservation
  • vitest 3 passed, eslint clean, yarn build clean

The v3 rewrite reduced ChromaticAberration to a bare wrapEffect call, so an
offset passed as a number or [x, y] tuple (which the prop types accept) is
handed to ChromaticAberrationEffect's constructor as-is and stored directly
into its Uniform. The effect then exposes a plain array, and the documented
imperative pattern ref.current.offset.set(x, y) throws
"offset.set is not a function".

Route the prop through the existing useVector2 helper, mirroring Glitch.
When no offset is passed, the effect's own default is left untouched.

v2 had this coercion (pmndrs#224); it was lost in the v3 rewrite.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ChromaticAberration: tuple offset bypasses Vector2 coercion, offset.set() throws

1 participant