Error when upgrading to 1.27

We recently upgraded to Cesium 1.27, and when we did, we started getting an intermittent error on load:

DeveloperError: readyImagery is not actually ready!

The comment in the code says:

// Our “ready” texture isn’t actually ready. This should never happen.

Does anyone have any ideas of what we could be doing to cause this and why it would be an intermittent error?

(I assume it has something to do with our map imagery and timing on loading … but, I’m not sure what we’re doing wrong in that regard)


I’m not sure of any recent changes that would cause that error. Did you try clearing your cache/cookies? Sometimes that leads to weird side effects when switching between version of Cesium.

Otherwise, do you have a link you could share, or a Sandcastle example that would allow me to reproduce the error?



Yes, we did clear the cache and cookies. Hmm … I don’t think that I can share our app with you because of proprietary imagery that we have purchased. And we’ve found that if we disable our custom imagery, the problem goes away. It appears that something about loading the custom imagery triggers the problem.

The issue that I’m seeing is that, inside of addDrawCommandsForTile, on line 152661:

tileImagery.useWebMercatorT is false

imagery.textureWebMercator appears to be a valid Texture object

imagery.texture is undefined

Because “useWebMercatorT” is false, it uses the undefined imagery.texture instead of the defined imagery.textureWebMercator.

I’m not sure whether the issue is that imagery.texture is undefined or that useWebMercatorT is false. And I’m not sure what could get me in that state. ;o)

There are some missing tiles in our custom imagery (the imagery just covers a small portion of the globe), for which we get errors like:

An error occurred in “WebMapTileServiceImageryProvider”: Failed to obtain image tile X: 1 Y: 1 Level: 1.

That wouldn’t cause an issue, would it? (it didn’t before we upgraded from 1.24 to 1.27)

Hi Eric,

The problem was almost certainly introduced in #4339. As the comment says, it’s not supposed to be possible, and it’s not clear to me why it’s happening in your case. I suspect you’re right that it has something to do with your tile failures. I’ll take a look. If you can help me reproduce it that’d be a huge help.



Thank you, Kevin! I’m happy to help in any way that I can … although, I’m not quite sure how I can, given what I mentioned before about our software having those 3rd party proprietary pieces. Maybe one thing to try would be to take a valid set of custom imagery and delete some of the folders out of every level to ensure that you get 404 errors in the console? It would be interesting to see if that was able to reproduce the error.

Thanks again for your help.

It seems like our custom imagery is missing a lot of the tiles folders. We’re using the scheme below to load the tiles, but the number of actual folders is no where close to the number of folders in the NaturalEarthII set. I noticed as the TileMatrix folder value increases the number of TileRow folders increases. Our TileMatrix 4 folder only has a two folders, 6, and 7. The NatrualEarthII TileMatrix 4 folder has from 0…31. Does this sound like a problem? What should we expect to see?


Kevin, I don’t suppose that you’ve been able to reproduce the error, have you?

We’ve realized that the 3rd party software that generated our image tiles created a layers.json file that claims it has image tiles that it doesn’t … so, that’s definitely a bug on their end. Interestingly though, this wasn’t an issue prior to #4339. So, maybe there is a way to fail gracefully in the face of missing textures?

I can confirm that this started happening to me with 1.27 as well. My solution was to fix the references to non-existent tiles server-side. I can reproduce the error by shutting down one of my tile servers and leaving the other operational. The first time a tile gets “missed,” Cesium crashes.

1.26 did not suffer from this issue.

Kevin, do you think we should write up an issue on GitHub for this?

Here’s the code that terrapixel provided to load the custom imagery:

    var layers = cesiumInst.scene.imageryLayers;

    layers.addImageryProvider( new Cesium.WebMapTileServiceImageryProvider( {

        "url": 'http://<serverip>:<port>/<path>/tiles/<country>/default/smerc/{TileMatrix}/{TileRow}/{TileCol}.jop',

        "layer": "smerc",

        "style": "default",

        "format": "image/x-jpegorpng",

        "tileMatrixSetID": "smerc",

        "maximumLevel": 15 // we actually have two different levels in this one set, some of the has a max level or 15 and the other is 19

    } ) );  

I see that tileMatrixSetID is no longer an option. Is there anything else that we should be looking at? tilingScheme? Should the tiles with the different levels be loaded into different layers?


Hi guys,

Sorry, but I’m not able to reproduce this. I tried deleting tiles out of a tileset, and I also tried pulling my network cable and then browsing around, especially near the edge of Web Mercator imagery. But no luck. If someone can reproduce with a public tileset in Sandcastle, that would be a huge help.

Also, please try out this branch:

It explicitly avoids using a parent imagery tile if that tile hasn’t been reprojected and this terrain tile needs it to be. I can’t really explain why that would happen (I don’t think it can) but if this branch does fix your problem it will be useful information.


Testing now! I’ll let you know asap.

So far, I have not been able to reproduce the problem. I’ll keep testing through the morning, and post again after lunch.


I was never able to reproduce the bug with the branch from above. I beat on our application fairly well, so I’m almost positive I would have seen the error if it hadn’t been fixed.
Will that fix get merged into v28?

Well, it could, sure… but I’m still a little concerned that I can’t explain why it is necessary. Did you try switching back to master to confirm that you can still reproduce the problem there?

I have not. We’re right in the middle of a big release. I’ll see what I can do tomorrow.


I just confirmed that v28 is still crashing with the same error. I’m going to try to cherry-pick the change from your branch above to see if that fixes the issue.


The change from definitely fixes our issue with the missing tile errors. Can you let us know if you decide to merge this in? We can also try to set up a demo for you, but I really don’t know if that is something we can do. It’s my understanding that some of our imagery was free, but that has been merged with some imagery that we’ve paid for. Part of me wonders if that merging of different imagery with different levels of detail is part of the problem.


Hi Scott,

It would be very helpful to see the problem myself. I imagine it would be ok for you to share your imagery with me in order to debug a problem, even if you’ve licensed it from someone and can’t generally redistribute it. You can email me directly: