How to avoid memory leaks caused by NodeMaterial

Questions
,
1

image2023-7-24_17-6-38
image2023-7-24_17-6-382335×751 70.9 KB

Through the memory analysis tool of the chrome browser, I found that NodeMaterial repeatedly calls the isReadyForSubMesh method in the rendering loop, causing an unknown memory leak. I was wondering if any of you have encountered this problem. It would be better if a solution can be provided.

1 Like
2

Hello @hazardtriigger , how are you doing?

Thanks for pointing that out! Adding @RaananW for visibility. Maybe we can file a bug for this?

3

is this the node material editor, or a babylon scene using a node material?

4

a babylon scene using node materials

5

Could you reproduce that on the playground? using the same material you are testing with (if possible)?

we HATE memory leaks. so we will take care of that asap :slight_smile: just want to be able to reproduce this correctly.

6

This is what we found during the test of my work project. I need some time to make a demo and put it on the playground. Please give me some time to prepare the demo. Our working group also needs to confirm whether the problem is incorrect use of NodeMaterial or a problem with NodeMaterial itself. We tested and found that the memory leak was in NodeMaterial, so we raised the question.

1 Like
7

We found that when NodeMaterial is deserialized, if convertToGammaSpace and convertToLinearSpace are set to undefined, it will cause a memory leak when the prepareDefines function is called.

_deserialize(serializationObject, scene, rootUrl) {
        var _a;
        super._deserialize(serializationObject, scene, rootUrl);
        this.convertToGammaSpace = serializationObject.convertToGammaSpace;
        this.convertToLinearSpace = serializationObject.convertToLinearSpace;
        this.useLogarithmicDepth = (_a = serializationObject.useLogarithmicDepth) !== null && _a !== void 0 ? _a : false;
}

public prepareDefines(mesh: AbstractMesh, nodeMaterial: NodeMaterial, defines: NodeMaterialDefines) {
        defines.setValue(this._linearDefineName, this.convertToLinearSpace, true);
        defines.setValue(this._gammaDefineName, this.convertToGammaSpace, true);
}

I’m not sure if this is the root cause, but in my work project I added the default values ​​of convertToGammaSpace and convertToLinearSpace to BABYLON.FragmentOutputBlock and the memory leak disappeared. I hope you all can come together to check and discuss.

1 Like
8

I am not seeing the leak in your example, a repro would be amazing ?

1 Like
9

The performance may be different in different scenarios. I used the memory analysis tool to locate such a problem in my work project, and after making corresponding modifications, it no longer leaked. So I just put forward my problem and solution. Whether there is really a leak needs to be discussed further.

10

Unhandled error objects can accumulate and cause a leak

11

Yup and I tried with/without the settings with the memory tab and I do not seem to be able to repro :frowning:

@hazardtriigger do not hesitate to ping us back if you have a tiny repro we can use

12

This is a project for our company and it has a huge structure. I am not the original staff member of this project, it will be a bit difficult to extract relevant codes to form a small demo. I’ll keep working on this and post a playground.

2 Likes