GSAP + React-Three-Fiber ?

[iDVB]

Is anyone else using GSAP and React-Three-Fiber do queue up more complex animations?

We have it working in most scenerio's save for one that is causing a bit of a challenge.

We have a animation similar to in this example https://codesandbox.io/embed/r3f-sparks-sbf2i that uses the UnrealBloomPass where we are animating the strength.

We read in the R3F's do's/don't that its not great to animate rapid values in JSX but instead to use a ref. We are doing this but the UnrealBloomPass seems to recreate the object anytime you resize the browser, but its NOT causing our ref to change, so our animations are running on the old object.

Anyone have this sort of thing happen and know of a work around?

[drcmda]

i made a mistake in that sandbox, it's wrong, the aspect isn't supposed to change. it should be:

const aspect = useMemo(() => new THREE.Vector2(512, 512), [])

args are literally constructor arguments: <foo args={[123]} /> equals new Foo(123) so it has to re-construct the object if args are changed. the effect resolution can remain static, that is totally fine.

as for your ref, that indicates a bug in your code, the ref changes, but for some reason you're stuck in a closure. but either way, the above fix will make it run.

generally i would recommend react-spring (see https://codesandbox.io/s/r3f-react-spring-basic-demo-8ckyf?from-embed) and lerping for animation. GSAP is fine, but it clashes with the declarative react approach.

[drcmda]

useEffect has a memo clause in the end, it's probably ,[]) or ,[ref]) which means it won't pick up the change, you're inside a closure. the ref is and must always stay the same, that's the point of it. but ref.current can change. useEffect(() => ..., [ref.current]) would allow it to pick up the change. but making the aspect fixed is better, it doesn't need to change with the browser window - in fact, it's common that it doesn't. i think i must have picked this up in a bad bloom example since im a beginner myself - but i asked in the three forum and they told me it should be fixed. i think you can also give it undefined

[iDVB]

Yes, the ref is used in this memo clause of our useEffect. And it’s in this useEffect that we are using GSAP to setup a mutating animation to the ref.current.strength. However, when the UnrealPass creates a new ref.current, the memo doesn’t pick up the change and so our animation can’t recalculate with the new object.

I short word on why gsap. Some of our animations can be extremely, elaborate in orchestration. I know of react-spring and lerp animations but haven’t seen any that orchestrate 6-7 tweens in a timeline that animate on a bezier motionPath and can each have their own repeat, easing etc.

So while we are well aware of the challenges of using it with declarative react, it’s really the only rational alternative we know of. Would love to see otherwise if these are things react-spring or other can also do easily.

[drcmda]

if you like put it into a codesandbox real quick and i can have a look

[drcmda]

ps heres an example, you can see that even though the effect is re-instanciated, useEffect can catch it if it's doing the memo clause correctly: https://codesandbox.io/s/r3f-instanced-colors-5o0qu?file=/src/Effects.js:1049-1205

  const bloom = useRef()
  const previous = usePrevious(bloom.current)
  useEffect(() => {
    console.log(bloom.current === previous)
  }, [bloom.current])

how gsap is involved in working on the wrong ref.current, that i dont know

[iDVB]

Thanks @drcmda I think we have a solve that is adapted a bit better to our use case.
We've setup an ref'd object literal (bloomConfig) that we are mutating with GSAP.
Then we just use that ref (that never re-creates, so the animation never recreates) in the Effect.js's useFrame to....

    bloomRef.current.strength = bloomConfig.current.strength;