Using basis texture in react three fiber

I wanna use basis texture in my react three fiber app but it throwing an error. Here is demo of my code, I tried both native three js loader and r3f useLoader approach but both are throwing an error

function Plane() {
  const gl = useThree((state) =>
  const texture = useLoader(BasisTextureLoader, 'file.basis', (loader) => {
  return (
      <meshBasicMaterial map={texture} />

the problem was that A. you didn’t include the transcoder and B. the loader is a little weird and you can’t omit ‘/’ in certain places. you can absolutely use useEffect and do it like in plain threejs as you did in your box, i would recommend useLoader though because now you have suspense integration.

1 Like

Thank you so much :slight_smile:

G’day Paul, is the Universal Basis loader the reason why that simple sandbox has a remarkably large js heap as seen in this screenshot?

I’m finding that in one of my projects that uses Basis, I’m also seeing a very large memory footprint that gets bigger and bigger the more the user engages with the page - note that this isn’t the case when using three.js’ standard TextureLoader and only happens with Basis. Stats are like: 13mb per page with TextureLoader vs 110mb that keeps growing with BasisLoader.

Just curious if this is a bug, GC issue or if it’s something to do with how the codesandbox is importing the transcoder? Cheers :slight_smile:

Saw something like this recently (Compressed textures using more memory than uncompressed textures? - #5 by donmccurdy) where the basis transcoder was reloaded many times, and also appears to be using R3F… in case it’s relevant!

1 Like

Hey Don, yeah looks to be the case but unsure if there’s a solution there? What would be causing the transcoder to be loaded multiple times in the sandbox?

I don’t really know how React and useLoader work enough to answer that, but this could happen if more than one BasisTextureLoader instance gets constructed. There’s a similar known issue for DRACOLoader on iOS; in the abstract it shouldn’t matter whether you construct multiple loader instances but in practice it currently does… I would like to fix that, sharing a WorkerPool instance regardless of how many loaders there are, at some point.

useLoader just calls new THREE.Loader().load(url, set)

i dont see it load the transcoder multiple times, looks like codesandbox redirects

as for heap snapshots in dev mode and codesandbox, i don’t know how relevant they are. csb does a lot of stuff in the background, i think they patch code as well to avoid infinite loops. react dev mode also has extra code for debug and profiling.

1 Like

I think I should try same scenario with native three js and react three fiber and compare the results, that might help us to know where the issue is probably. And if issue arises in both approaches then I’m the one who is doing it in a wrong way.

Curious to see how you get on, let us know please :slight_smile: