Removing all primitives

This seems like it should be something extremely straight forward but I don't think I've ever been able to get it to work correctly. Trying to remove all primitives using the removeAll() function always results in the following error message:

DeveloperError: This object was destroyed, i.e., destroy() was called. Error at new t (http://bgb/js/lib/Cesium/Cesium.js:378:6242) at o (http://bgb/js/lib/Cesium/Cesium.js:379:4905) at lt.destroy (http://bgb/js/lib/Cesium/Cesium.js:393:12373) at a.removeAll (http://bgb/js/lib/Cesium/Cesium.js:410:14862) at <anonymous>:2:15 at Object.InjectedScript._evaluateOn (<anonymous>:668:39) at Object.InjectedScript._evaluateAndWrap (<anonymous>:607:52) at Object.InjectedScript.evaluate (<anonymous>:519:21)

and then the globe locks up and the page has to be refreshed. Am I missing something? Looking in the SandCastle, I see examples where primitives.removeAll() is called and it seems to work normally.


For "primitives.removeAll()" to work, you should have declared a variable
called primitives.

While you are removing do the following

var a = primitives.removeAll();
console.log('Is my Primitives removed',a);

Now after loading the page press CTRL+SHIFT+I at your browser and see the
ouput in the console of the browser.

I do that already. I have a large utility class that I have created call CesiumHelper that provides alot of convenience functions and such. When that class initializes, it initializes the globe and then sets up variables (class attributes in this instance) for the viewer, scene, ellipsoid, and primitives.

It initializes the globe as this.obj then does..

this.viewer = this.obj;
this.scene = this.obj.scene;
this.ellipsoid = this.scene.globe.ellipsoid
this.primitives = this.scene.primitives;

When I call removeAll, I'm doing this.primitives.removeAll();

Is it possible that there are primitives in the collection that were already destroyed? By default, the collection will try to destroy them:


I wouldn't think so unless Cesium itself had already destroyed them. At the point that I'm testing this, I just load a few things on the globe and attempt a removeAll() and get the error. Looking at that function definition and thinking about your reply though.. do you mean that, if I create a PolylineCollection and then add 5 lines to it, that if I call removeAll() that it could remove and destroy the Polyline's before the collection and that then the PolylineCollection would attempt to delete them as well? Or I misunderstanding this?

Perhaps, short term until I can figure this out I should just make a custom removeAll() that destroys things in a specific order..

removeAll() will destroy the polyline collection, which will destroy its polylines.

Instead of a custom removeAll(), you could set primitives.destroyPrimitives to false, but then you have to destroy them manually.

If you think there is a bug, submit an issue with a stripped down test case. We are working on Cesium 1.0 so we won’t get to it for a bit though.


I think I may have found the problem and, reason being is that I didn't understand how some aspects of this functioned before. It makes sense looking at it now but I wasn't thinking of a texture atlas as being one of the items that would be destroyed in the process. When a billboard collection is removed, it's texture atlas is also destroyed. Unaware that this happened, I was sharing a texture atlas between several billboard collections. So, when I attempted a remove all, it was destroying a shared resource essentially. It's weird though that, calling remove all doesn't fail after the first item is removed. Nothing was ever removed.

Long story, short.. it was an issue of an item being destroyed already.

Thanks for the help Patrick

BillboardCollection has a destroyTextureAtlas property which you can set to false if you want to share a texture atlas. You’ll then be responsible for destroying the shared texture atlas in your own code when cleaning up.

removeAll works by iterating the primitives, destroying each one, then clearing the collection afterwards, which is why you saw the behavior you mention.