Residual textures & geometries created for ObjectLoader-originated envMap

Questions
,
1

Hi,

I’m using ObjectLoader to load a JSON Scene that contains an envMap texture. My application loads and unloads content regularly, sometimes involving large textures and geometries, and I want to be able to track these clearly using WebGLRenderer.info.memory.

Whenever I load a JSON scene containing envMaps, the totals never return to 0, even with my comprehensive efforts to dispose of every geometry and maps of every type.

I have two examples of JSON scene; this is what is left over in each case after disposing of the scene:

  • The JSON scene with a single envMap results in 1 texture and 10 geometries being left over
  • The JSON scene with two envMaps results in 1 texture and 11 geometries being left over

If I remove the environment maps in these scenes, there are 0 textures and 0 geometries left over.

I was looking at source code, and wondered if WebGLCubeMaps and WebGLCubeUVMaps might be the place where such resources are created.

Another forum post here explains that Scene backgrounds’ resources are created internally and aren’t an issue. I’m not sure if the process will be the same in my case, i.e. in the case of envMaps in parsed external scene files - can anyone clarify this?

The thing that I’m most concerned about is: if this is expected behaviour, how can I keep track of the number of textures and geometries in the provided renderer counts, in terms of what proportion of these counts belong to the ‘nothing to worry about’ totals used by the environment map system? As I mentioned above, depending on which part of my application I execute, I can have 1+10, or 1+11. The best I can do here is to monitor my texture and geometry usage by subtracting 1 and 11 respectively, but only once I know I’ve executed a part of my application that will result in the first appearance of these residual numbers.

I hope that I’m simply missing something or doing something wrong; any help would be appreciated.

2

Subtracting 1 from textures count and 10 (or 11) from geometries count is not a good general solution. If you do not know the origin of these geometries, in a future release of Three.js these number could be different.

If you are sufficiently inquisitive, you can try these steps:

  • (optional step) simplify the scene as much as it is possible – reduce number and complexity of objects, simplify materials, get rid of lights, shadow, all helpers, etc. If at some point the problem disappears, then this is a clue
  • recreate the scene with code – if the problem disappears, then something in the loader is responsible, otherwise the loader is innocent
  • if the problem is in the loader, modify its code to make some private elements visible from outside (like the list of textures – yes, the loader creates its own secret array of textures), then check wheather some of these elements is indisposable
  • if the problem is in the core, you can modify the consturctor of buffer geometry to record all created geometries and then check which one is not disposed