Destroyed primitive collection still referenced in frustumCommandLists, and could not be collected by GC

I created a Cesium.PrimitiveCollection() object and added hundreds of pointPrimitiveCollections in it, each of them with a few thousands of pointPrimitive.

I destroyed pointPrimitive but the resource was still occupying a certain amount of memory. By using the snapshot of chrome devtools, I was able to find that it was referenced in frustumCommands

@Brahms

First, welcome to the community! I looked through the PointPrimitive documentation and did not see any destructors. Thus, one suggestion would be to set the PointPrimitive objects that you wish to “destroy” as undefined. Let me know if this works for you.

In the meantime, more information about your use case would help me better assist you. Is memory usage a primary concern for your application? What is the objective you are trying to accomplish by adding hundreds of pointPrimitiveCollections objects? I am looking forward to hearing from you!

-Sam

Dear Sam,

I am trying to display a dataset of millions of points, since I didn’t find out how to set the style of points added by 3dtiles and I wanted to customize the way chunked hierarchical points are loaded. I designed a new format of pointcloud, which compressed the binay file and coded with other information for decision making on whether one certain chunk should be loaded when given a certain viewport.

In my compressed binary file, one points with four properties occupied 6 bytes, I guess it might be much larger when it is converted to a Cesium.PointPrimitive object, however, if there exists no such memory leak, its memory usage should still be acceptable.

By splitting this pointcloud into hundreds, I could control the number of points being displayed by set the show property of PointPrimitiveCollection object.

Just now I happened to find the root of this problem, which lies in that one chunk might be added multiple times in async tasks before it is ready.

Thanks for you enthusiastic assistance!

@Brahms

I am glad to hear that you found the problem! It sounds like you are working on an interesting project. Keep us posted on the progress of your project - we are always looking for amazing community work to showcase.

-Sam

Is it possible to find out the objects that are only being referenced by Cesium objects, including scene, commands and etc, while they are not able to be found elsewhere. Then, given that all user introduced objects are governed in some user-defined structs, it might be much easier to manage the heap.

Currently I am only a humble user of your marvellous lib, and is of little knowledge about what is going under the hood. Is it possible? What should I know if I try to implement it? I will try to work on this if I got the time and know how to do it.

I could imagine that it much be difficult to perform a thorough check, which may well spend some time, like in chrome snapshot. Could it be, like, a few pre-defined objects are considered as root, and perform a garbage collection from them partially, while internal edges of Cesium lib is not counted? It sounds like a graph problem.

1 Like

@Brahms

To the best of my knowledge, there is no simple way to determine which objects are only being referenced by Cesium objects.

I came across this Cesium community forum post yesterday afternoon. The post discusses freeing memory after unloading 3D Tiles. It seems like @marcel.wendler is also considering memory-related constraints when using 3D Tiles. I thought this may be of interest to you.

Here is another memory-related thread that you may find of interest.

We are happy to have you as part of our community! Feel free to ask/answer as many questions as you wish.

-Sam

Thanks

1 Like