ThreeJS Disposing an Object

The disposal of unwanted library entities is a crucial component of improving performance and avoiding memory leaks in your programme. When you create a three.js type instance, you set aside a specified amount of memory. Three.js, on the other hand, builds WebGL related things like buffers and shader programmes for specific objects like geometries and materials, which are required for rendering. It's vital to note that these objects aren't automatically released. In order to liberate such resources, the programme must instead use a particular API. This document gives a quick overview of how to use this API and what objects are useful in this situation.

Geometries

A geometry is typically used to represent vertex information in the form of a set of characteristics. For each attribute, three.js produces an object of type WebGLBuffer internally. These entities are only deleted if you call BufferGeometry.dispose(). Execute the procedure to liberate all relevant resources whenever a geometry becomes obsolete in your application.

Materials

A material is what determines how an object is presented. three.js constructs a shader programme for rendering using information from a material specification. Shader programmes can only be removed if the corresponding material is no longer in use. Three.js aims to reuse existing shader programmes whenever possible for speed reasons. As a result, a shader programme is only removed when all associated materials have been discarded. You can indicate the disposal of a material by executing Material. Dispose().

Textures

The texture of a material is unaffected by its disposal. Because a single texture might be utilised by many materials at the same time, they are treated independently. Three.js automatically creates a WebGLTexture instance whenever you create a Texture instance. This object, like buffers, can only be removed by invoking Texture.dispose ().

Miscellaneous

Other instances directory classes, like as controls and post processing passes, include dispose() methods for removing internal event listeners and render targets. In general, it's a good idea to examine a class's API or documentation for disposal (). If it's present, you should make use of it when cleaning up.

Let’s good at some commonly asked questions

Why can't three.js dispose objects automatically?

The community has raised this subject several times, so it's critical to address it. The truth is that three.js has no idea how long user-created things like geometries or materials will last or what their scope will be. This is the application's duty. Even though a material isn't being utilised for rendering right now, it can be required in the following frame. So, if the application thinks that a particular object can be erased, it must inform the engine by invoking the dispose() method.

Does removing a mesh from the scene also dispose its geometry and material?

No, you must dispose of the geometry and material specifically using dispose (). Keep in mind that 3D objects like meshes can share geometry and materials.

What happens when you call dispose() on a texture but the image is not loaded yet?

Internal texture resources are only allocated after the image has completely loaded. Nothing happens if you dispose of a texture before the image has been loaded. There were no resources assigned, so there is no need to clean up.

Does three.js provide information about the amount of cached objects?

Yes. WebGLRenderer.info, a specific property of the renderer that contains a series of statistics information on the graphics board memory and the rendering process, can be evaluated. It tells you how many textures, geometry, and shader programmes are saved inside, among other things. It's a good idea to debug this property if you discover performance issues in your application so you can quickly find a memory leak.

How should I manage three.js objects in my app? When do I know how to dispose things?

There is no clear suggestion for this in general. When invoking discard() is appropriate, it is greatly dependent on the unique use case. It is critical to emphasise that disposing of artefacts is not always essential. A game with numerous levels is an excellent example of this. When transferring levels, this is an excellent time to dispose of objects.

The app could go over the original scene and remove any materials, geometries, or textures that were no longer needed. It does not create a runtime error if you dispose an object that is still in use, as indicated in the previous section. The worst that can happen is a single frame of performance degradation.