There are some guesses involved in the following. Analyzing the details of multiple data sets can be time consuming. But I did have a short look, and will try to summarize some aspects that may explain what you are seeing.
Just to confirm (and show) the behavior that you are (probably) referring to: For the data set that is generated with DJI TERRA, the initial representation looks washed-out and coarse, and does not show many details. Only when zooming in, the details appear. In contrast to that, the data set that was generated with another tool, it immediately shows a high detail (and only little additional detail when zooming in) :
Looking more closely at the tileset JSON files, one can see the following:
(I’m omitting stuff like the bounding volumes and transforms here)
For the data set that was generated with DJI TERRA, the relevant part of the root tileset.json looks like this:
{
"geometricError": 451.971435546875,
"root": {
"children": [
{
"content": {
"uri": "Block/tileset.json"
},
"geometricError": 348.6705017089844,
"refine": "REPLACE"
}
],
"geometricError": 451.971435546875,
"refine": "REPLACE"
}
}
It just refers to a Block.tileset.json which looks like this:
{
"geometricError": 348.6705017089844,
"root": {
"content": {
"uri": "Block_L14_1.b3dm"
},
"geometricError": 5.55034065246582
}
}
What’s happening now is the following: CesiumJS will …
- load the root
tileset.json, and see that it has a high error geometric error of 451
- try to reduce that error, by loading the next level of detail - namely, the
Block/tileset.json. This still has an error of 348.
- try to reduce that error, by loading the next level of detail. Namely, the tile with the content
Block_L14_1.b3dm. This has a geometric error of only 5.55
- Here, CesiumJS will say “OK, that’s a pretty low error”, and stop refining the data
The Block_L14_1.b3dm file has a size of 12 KB (Kilobytes!!!), and … when it is rendered, it looks like this:
Comparing that to the tileset that was generated with Pix4D:
{
"geometricError": 293.72975158691406,
"root": {
"content": {
"uri": "Osong_80m-cesium_mesh_0.b3dm"
},
"geometricError": 6.509479341772257
}
}
Similar to the process above, CesiumJS will…
- load the root
tileset.json, and see that it has a high error geometric error of 293
- try to reduce that error, by loading the next level of detail. Namely, the tile with the content
Osong_80m-cesium_mesh_0.b3dm. This has a geometric error of only 6.5
- Here, CesiumJS will say “OK, that’s a pretty low error”, and stop refining the data
The Osong_80m-cesium_mesh_0.b3dm has a size of 6.5 MB (Megabytes!), and looks like this:
The tl;dr of all this technical gibberish could be:
CesiumJS has to assume that the data that is shown in these screenshots has roughly the same visual quality - because the tiles have roughly the same geometricError value. So both data representations are shown at the same time, even though they obviously do not have the same visual quality.
But to emphasize that:
The output from DJI TERRA is not ‘wrong’!
(Except for the fact that the glTF has validation errors. This should be fixed by DJI TERRA, and if you can, you should file a bug report for that! But it is unrelated to the issue that you see here…)
The problem is only that different creation tools have different … attitudes … and make different decisions about how to structure the data, and what levels of quality they want to deliver. There are good, valid reasons to structure the data like DJI TERRA did: The client only has to download 12 KB (!) of data, and will immediately see an approximation of the model. For the Pix4D data, the client will have to download 6.5MB until the first data will become visible.
There is no “right” or “wrong” here. These are just trade-offs.
Maybe a solution:
You can tweak the behavior of CesiumJS, to accomodate for different geometricError values. Namely, by setting different maximumScreenSpaceError values for the tilesets. Skipping some details (pun somewhat intended 
), you can set a maximumScreenSpaceError for the DJI TERRA tileset that is lower than the default value. The default value is 16. So when you create that tileset with
const tileset = await Cesium.Cesium3DTileset.fromUrl("./dji/tileset.json", {
maximumScreenSpaceError: 2.0
});
then it should load more details faster. (You might even consider reducing the value, to 1.0 or even lower, until it matches the behavior that you’d expect).
