Hello,
I have been trying to look out for a bug with cesium itself.
Coordinates for testing are 50.56730720768898,7.281888512241843
Or you can also search for this : Buttermarkt 14, 53545 Linz am Rhein, Germany
Looks like, its due to LOD for a specific square being shown and dont update when we are at this place.
I have tried gmaps3d it looks like its only issue with cesium not rendering properly.
Thank you!
This seems to be another case of what is tracked in Wrong tiles selected for refinement in certain areas · Issue #12683 · CesiumGS/cesium · GitHub : In some areas of the Google Photorealistic 3D Tiles, the wrong level of detail seems to be selected.
Here is a short screencap of translating the view (not zooming!) in a very specfiic area there:
The sandcastle that captures this location (the effect will only be visible when the viewer size matches that of the screencap):
Right now, the assumption seems to be that this ~“is a data issue”, and not a bug in CesiumJS. (It’s hard to be 100% sure about that, but the symptoms suggest that it is a data issue: The tile selection of CesiumJS works “everywhere”, except for very few, very specific, very small areas…)
Thanks, for quick response.
But I dont think its related to tiles data.
I have two other renderers in compare gmaps3d and three js and my guess is both uses same data and seems to render it fine.
Can you pls check here example by three js
Pls also check recordings ( public access, not restricted ) of same place in gmaps3d recently released and also three js renderer in above drive folder.
This is very important to us.
Can you help us here? Thanks
As I mentioned: “the assumption seems to be that this ~“is a data issue””. But given the direct comparison between the CesiumJS and the ThreeJS version, it’s clear that this is not the case. Left shows the ThreeJS version, with an “errorTarget” of 100, and right shows the default CesiumJS rendering.
The point here is only that this seems to be the same tile, but in CesiumJS, it should select a much finer tile (the proper LOD can be seen in the upper left of the CesiumJS part), and with the default “errorTarget” of 20, ThreeJS does display the correct LOD (so the tiles are there).
There is no quick or easy solution for that - given how rarely this seems to occur, how hard it is to debug something like this with tile names like CgIYAQ/files/AJVsH2yI5ryWYCBB7RB3K7SX1l53_0yu3HdERt67r18WFNUWGZ4bk4IUBtSCixVhnFEA4Cic8PrQn2KQHvOm-n_RXq5S0dUmvwJSgWs4WfRX1XpL6FS-6XSgf9uu81i8fB7szRzq_EgR3S7NL6ibFHi0R7G3QnP2U81Xf1MEUxCKdF8vn95YAy3fcvXeKUjfiQ.glb 
, and how complex the CesiumJS tile selection is.
In this particular area, one can “force” the higher LOD to be loaded with
tileset.maximumScreenSpaceError = 2;
but that will generally increase the memory consumption significantly, may still not work in all cases, and is therefore not a viable solution. I’ll “bump” the issue, but there is not much more that I can do right now…
