disposeTree: shared textures, and a render target
Every printed number is renderer.info after the step. The depth texture of the target counts as a texture. The one texture left at the end is three.js's own lookup table for physical materials.
three.js uploads geometries, textures and shaders to the GPU and never frees them by itself. dispose() frees them, but only the one object you call it on. A configurator that makes a texture per click leaks until the tab dies.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 4 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write swapMap(material, newTexture) that never leaks, and does not free a texture that is the same as the new one.
You remove a mesh with scene.remove(mesh) and renderer.info.memory.textures does not change. Why, and what do you add?
Explain it without notes
A configurator's memory grows by 340 KB at every colour click. Find the cause and give two fixes.
Why must you dispose a material's textures separately?
Console
Nothing logged yet.Expected console output
3 meshes, 2 shared textures geometries 3 | textures 3 | programs 1
+ a render target drawn into geometries 3 | textures 5 | programs 2
target.dispose() geometries 3 | textures 3 | programs 2
one material.dispose() geometries 3 | textures 3 | programs 2
disposeTree freed 2 distinct textures
disposeTree(body) geometries 0 | textures 1 | programs 0