There are a few things coming together here, and some of them may warrant a deeper investigation. For now, a quick summary of points that may be relevant.
I tried to capture the three tilesets. (It’s a GIF, limited to 256 colors - that does not make sense, but the point is that it’s easier to visually compare the final (rendered) state directly)
From what I see, there are subtle differences, but I’d have a hard time attributing any concept of “quality” to them (i.e. I couldn’t say which one is “the best one”).
In your sandcastle, you did set
const tilesetOptions = { maximumScreenSpaceError: 1.5 };
This is pretty low compared to the default (16). It may be appropriate, depending on the structure of the data.
This brings up some questions about the tilesets that may be relevant here. It looks like the 1.1 tilesets have been created with Cesium ion. But which tool has been used for creating the 1.0 tileset?
The 1.0 and 1.1 ones are structurally very different, so it’s hard to make any comparisons here.
For example, the 1.0 one defines a geometric error of 2330 for the tileset, and then geometric errors of (4 / pow(2, level)) for the other tiles. (I.e. 4.0, 2.0, 1.0, 0.5, …).
The 1.1 one defines a geometric error of 1529 for the tileset, and then 44 for the root tile of an implicit tileset (i.e. the errors will be 44, 22, 10, 5…)
In theory, one way to “align” both could be to use different maximumScreenSpaceError values for these tilesets. (It should be a factor of 10, assuming that it’s linear…). But this is only one of the differences.
Other aspects are impossible to sensibly compare. For example, I looked at one texture in the 1.0 data set, and it had a size of 1024x1024. A texture in the 1.1 data set had a size of 1536x1546 (!). But these might have been at different levels of detail (It would take more time to systematically analyze this)
One important detail: When I’m looking at the “not ktx2 compressed” tileset, the viewer eventually prints
The tiles needed to meet maximumScreenSpaceError would use more memory than allocated for this tileset.
The tileset will be rendered with a larger screen space error (see memoryAdjustedScreenSpaceError).
Consider using larger values for cacheBytes and maximumCacheOverflowBytes.
to the console. This basically means that it tries to load to much data (too many textures) to fit into memory. And it will then fall back to using a lower level of detail.
So in theory, it might be that this lower level of detail then uses lower-resolution textures, which may (visually) appear “more washed-out”, which could (depending on your perspective and expectation) also be called “less noisy”…
Maybe all that was too “low-level”. At least, I hope it’s not distracting…
