So im having an issue when i click next scene then previous scene it doesnt seem to clearing data correctly and gets laggier and laggier the more i click next scene and back to the old one. This is the code i have. gallant-sound-zuxcd - CodeSandbox
if (
node.material instanceof THREE.MeshFaceMaterial ||
node.material instanceof THREE.MultiMaterial
) {
This code can not be used with a latest version of three.js. MeshFaceMaterial and MultiMaterial has been deprecated. You also miss potentially set texture properties. Try it with the code from:
So i tried this solution. It stops previous shader/scene from being loaded again also just made everything super lagggy.
ok working on a lil bit it works but still doesnt stop gpu usage slowly increasing by going through all the shaders updated code sandbox gallant-sound-zuxcd - CodeSandbox
the issue I think is GPU memory isn’t clearing.
nvrm not gpu memory that is clearing its just the actual gpu utilization just keeps going up.
@Cai_Martin Hello. Neat demo concept!
I recommend you focus on cleaning up your code. It has unused variables, you cleanup code outside the clearThree method and should instead put all cleanup code in the same method, class names don’t match file names, some calls that don’t make sense (like passing a function into cancelAnimationFrame) or calling renderer.clear in the clearThree method which doesn’t clean up memory; this indicates you didn’t read documentation and are making guesses as to how things work, which will not take you very far.
Clean up, make sure you know how APIs work, then you’ll have an easier time writing the code properly.
I started to clean up the code here, and you can take over (see some comments):
At the moment codesandbox is giving me 503 errors, so I can’t test it out yet.
imo using react and three like that is shooting yourself in the foot, i see so many curious or scary things in that code (timeouts …), it just screams race condition. especially with classes where you don’t have a concept to properly define side effects like hooks could. it seems fragile, to say the least.
that 220 line box would be maybe 50 or less in react-three-fiber, with clean management and disposal. just like you don’t worry about the dom disposing of things with react-dom, which manages nodes for you.
don’t have many examples for audio-analyser unfortunately, only these two:
simple: r3f audio analyser - CodeSandbox
more involved: Audio analyser - CodeSandbox
these are already using React.Suspense, which is Reacts way to deal with async ops, like loading a track, or waiting for a promise, etc. you don’t ever need timeouts, you get fallback handling for free, and you can orchestrate things like component B acting upon async component A once its loaded.