Our app utilizes THREE.js to showcase 3D body meshes. We have a special object named MeshViewer that manages the rendering process; within the initialize method, we establish
this.renderer = new THREE.WebGLRenderer({ antialias: true, preserveDrawingBuffer: true })
We developed a script to verify that this.renderer is not deallocated.
<script>
var count = 0;
function loop () {
if (count >= 25) {
return;
}
else {
count++;
var viewer = new MeshViewer(
'mesh_viewer',
's3_assets/textured_mean_scape_female.obj',
[]
);
viewer.cleanup();
setTimeout(function () {
loop();
}, 500);
}
}
loop();
</script>
In this scenario, 'mesh_viewer' represents the id of the HTML element where we aim to insert the viewer. Our cleanup procedure assigns
this.renderer = null
The cleanup operation functions as expected to prevent an error related to exceeding WebGL context limits when it is executed. The intriguing issue arises when attempting to understand why calling viewer.cleanup just before the setTimeout loop causes failure, while placing cleanup outside and prior to setTimeout ensures success. This dilemma may lean more towards JavaScript intricacies rather than being solely tied to THREE.js or WebGL concepts.