Document caching behavior of loaders

Questions
1

I’d like to better understand the lifecycle of loaded textures, the current documentation is not clear, or at least does not go deep enough to answer my question: how long do loaded textures stay in memory?

The project I am working on is a large game with hundreds of models, textures, and other resources. This game dynamically loads content as you move around the world, and stores that data in a cache (using lru-cache). Resources that haven’t been accessed in a while get unloaded from the cache. This is important because my game world is huge and can’t all fit in memory at once.

However, it seems that loaders (and in particular LoadingManager) do their own caching, separate from what I am doing. This is a problem if LoadingManager is holding on to data that I have unloaded from my own caches - eventually memory is going to get full.

So my first request is to get a more detailed explanation of how long loaders hold on to resources once a resource is first loaded. Bonus points for suggesting a viable approach for integrating the loader lifecycle with my own caching logic.

2

I wouldn’t think the three.js loaders are holding anything in memory if THREE.Cache.enabled = false, which is false by default. If that’s not the case it would be news to me. KTX2Loader does hold a WeakMap referencing texture data, but that shouldn’t be causing a memory leak.

3

OK that’s useful to know. I didn’t know about the caching flag.

Part of my confusion is this sentence in the documentation for LoadingManager: “Handles and keeps track of loaded and pending data.” It doesn’t really define what “keep track of” means in this context.

Also, it would be helpful if the documentation for LoadingManager included a hyperlink to the Cache docs.